Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > learnpython.org - an online interactive Python tutorial

Reply
Thread Tools

learnpython.org - an online interactive Python tutorial

 
 
Chris Angelico
Guest
Posts: n/a
 
      04-24-2011
On Sun, Apr 24, 2011 at 6:13 PM, Steven D'Aprano
<(E-Mail Removed)> wrote:
> suppose an implementation might choose to trade off memory for time,
> skipping string -> bignum conversations at the cost of doubling the
> memory requirements. But even if I grant you bignums, you have to do the
> same for floats. Re-implementing the entire floating point library is not
> a trivial task, especially if you want to support arbitrary precision
> floats.


Or just arbitrary precision decimal strings, which aren't "floats" at
all. But to be honest, I've never looked at any implementation of REXX
(and the open source implementations do seem to be inferior to IBM's
OS/2 implementation, I think - haven't done any empirical testing
though), so I can't say how it's done. But it seems to my small
understanding that it'd be simpler to just work with the base 10
string than to convert it to base 256 or base 2**32 or something, just
because you skip the conversions. Obviously this makes REXX a poor
choice for heavy HEAVY computation, but it's potentially faster for
things that involve a little computation and a lot of string
manipulation (which is where REXX does well).

Chris Angelico
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-24-2011
On Sat, 23 Apr 2011 22:10:47 -0500, harrismh777 wrote:

> I've been giving this some more thought. From the keyboard, all I am
> able to enter are character strings (not numbers). Presumably these are
> UTF-8 strings in python3. If I enter the character string 57 then
> python converts my character string input and returns an reference to
> object 57.


That depends on where you enter it. If you enter it in between a pair of
quotation marks, no conversion is done.

But I'll grant you that there are many places where the user/programmer
communicates to the Python interpreter, and can generally only do so via
characters or bytes. But that's hardly unique to numbers -- a dict is a
rich compound data structure, but you can only create dicts by entering
them as characters too. That's what we call syntax.

But the point is, once you have entered such a dict into the Python
virtual machine:

d = {'spam': lambda x: x**2 + 3*x - 5, 42: ['a', 'b', 23, object(), []],
17: (35, 19, True), 'x': {'cheese': 'cheddar'},
'y': {'animal': 'aardvark'}, 'z': None}

Python no longer needs to convert it or its components back and forth
between a string and the in-memory data structure. Converting to or from
strings tend to be used in only a very few places:

* compiling from source code, including eval and exec;
* the interactive interpreter;
* some, but not all, serialization formats (e.g. JSON and YAML);
* printing the object repr;
* explicitly converting to string;

which is a big win for both speed and memory. You'll note that every
single one of those is a special case of Input/Output.


[...]
> My idea for consistency is this: since the interpreter converts int
> to float, and float to imaginary (when needed), then it does (at least
> in a limited way) type promoting.


You are conflating lexing/parsing/compiling code with executing code.
Just because you need to have a plumber install your water pipes when
building a house, doesn't make it either practical or desirable to call a
plumber in every time you want to turn a tap on.

I will grant that there are situations where a more implicit type
conversion may be useful, or at least convenient. Perl does what you
want, promoting strings to ints (and visa versa?) depending on what you
try to do with them. Hypertalk, part of Apple's long defunct but not
forgotten Hypercard, was deliberately designed to help non-programmers
program. And I've sometimes experimented with config file formats that do
similar things. So it's not that I think that weak typing in the REXX/
Hypertalk/Perl sense is always wrong, only that it's wrong for Python.

On the other hand, both Flash and Javascript also do weak typing, and the
results in practice can be confusing and fraught with problems:

http://nedbatchelder.com/blog/200708..._problems.html

And I think this quote from Peter Wone is amusing:

"Weak typing such as is used in COM Variants was an early attempt to
solve this problem, but it is fraught with peril and frankly causes more
trouble than it's worth. Even Visual Basic programmers, who will put up
with all sorts of rubbish, correctly pegged this as a bad idea and
backronymed Microsoft's ETC (Extended Type Conversion) to Evil Type Cast."

http://stackoverflow.com/questions/5...be-discouraged


It seems to me that weak typing is a Do What I Mean function, and DWIM is
a notoriously bad anti-pattern that causes far more trouble than it is
worth. I'm even a little suspicious of numeric coercions between integer
and float. (But only a little.)



--
Steven
 
Reply With Quote
 
 
 
 
Dave Angel
Guest
Posts: n/a
 
      04-24-2011
On 01/-10/-28163 02:59 PM, harrismh777 wrote:
> Cameron Simpson wrote:
>> | folks are not aware that 'bc' also has arbitrary precision floating
>> | point math and a standard math library.
>>
>> Floating point math? I thought, historically at least, that bc is built
>> on dc (arbitrary precision integer math, reverse polish syntax) and that
>> consequently bc uses fixed point math rather than floating point.

>
> My bad... I don't mean under-the-covers... I mean that the user may
> calculate arbitrary precision floating arithmetic ... bc keeps track of
> the decimal point and displays the number of digits the user specifies;
> arbitrary precision calculator. (loose language, sorry)
>
> On a *nix system, Mac OSx, Linux, run this to get 1000+ digits of PI:
>
> time echo "scale = 1010; 16 * a(1/5) - 4 * a(1/239)" |bc -lq
>
>
>
> scale sets the precision, -lq loads the math library arctan() quiet.
>
>
>


Wouldn't it be shorter to say:

time echo "scale = 1010; 4 * a(1)" |bc -lq

DaveA
 
Reply With Quote
 
jmfauth
Guest
Posts: n/a
 
      04-24-2011
On 24 avr, 05:10, harrismh777 <(E-Mail Removed)> wrote:
>
> * * I've been giving this some more thought. From the keyboard, all Iam
> able to enter are character strings (not numbers). Presumably these are
> UTF-8 strings in python3. *If I enter ...



In Python 3, input() returns a unicode, a sequence/table/array of
unicode code point(s). No more, no less.

Similar to Python 2 where raw_input() returns a sequence/table/array
of byte(s). No more, no less.

jmf
 
Reply With Quote
 
harrismh777
Guest
Posts: n/a
 
      04-25-2011
Dave Angel wrote:
>> time echo "scale = 1010; 16 * a(1/5) - 4 * a(1/239)" |bc -lq
>>


> Wouldn't it be shorter to say:
>
> time echo "scale = 1010; 4 * a(1)" |bc -lq


Well, you can check it out by doing the math... (its fun...)

.... you will notice that 'time' is called first, which on *nix systems
clocks the processing, breaking out the system and user times... right?

.... so try these 10,000 comparisons on your *nix system:

time echo "scale = 10010; 16 * a(1/5) - 4 * a(1/239)" |bc -lq

time echo "scale = 10010; 4 * a(1)" |bc -lq

(those will take a few minutes, if your processor is running 2-3Ghz...)

.... then try these 100,000 runs:

time echo "scale = 100010; 16 * a(1/5) - 4 * a(1/239)" |bc -lq

time echo "scale = 100010; 4 * a(1)" |bc -lq

(Those will take some time, probably less than 20 - 30 minutes... )


After your time comparisons, tell me whether you want to use a(1)*4 ??

Leonard Euler came up with the formula I'm using here... and used it
himself for paper 'n pencil arithmetic... because the arctan(n) infinite
series converges much quicker (by orders of magnitude) for values of (n)
< 0. (the smaller the (n) the better)

We can make the entire function run even faster by using smp and
splitting the 'a(1/5)' and 'a(1/239)' across two cores, having the
arctan series' running in parallel. This is important if your 'big num'
is going to be hundreds of thousands or millions of places. On my baby
Beowulf cluster I have played a bit with running this on two separate
systems and then bringing the result together in the end... fun for
playtime... interesting to see how many digits (in how much time) can be
achieved *without* using a super-computer....

You can also try these formula for comparison sake:

PI = 20 * a(1/7) + 8 * a(3/79)
or
PI = 8 * a(1/3) + 4 * a(1/7)
or
PI = 24 * a(1/ + 8 * a(1/57) + 4 * a(1/239)



Happy Easter, and have a slice of pie on me....





kind regards,
m harris



 
Reply With Quote
 
harrismh777
Guest
Posts: n/a
 
      04-25-2011
Steven D'Aprano wrote:
> It seems to me that weak typing is a Do What I Mean function, and DWIM is
> a notoriously bad anti-pattern that causes far more trouble than it is
> worth. I'm even a little suspicious of numeric coercions between integer
> and float. (But only a little.)


I'm wondering about that as well... (a little)... I mean, maybe the way
to be really consistent (especially with the Zen of Python, explicit is
better than implicit) that int --> float --> complex (imaginary) should
not occur either !

I think folks would baulk at that though... big-time.


So, bottom line here... if my students want to get numbers into their
programs in 3.x then the correct way to handle the imput() would be:

n = int(input("enter num > "))


... and then let the interpreter throw an exception if the input
cannot be type cast to int?


kind regards,
m harris


 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      04-25-2011
On 4/25/2011 2:20 AM, harrismh777 wrote:
> Steven D'Aprano wrote:
>> It seems to me that weak typing is a Do What I Mean function, and DWIM is
>> a notoriously bad anti-pattern that causes far more trouble than it is
>> worth. I'm even a little suspicious of numeric coercions between integer
>> and float. (But only a little.)

>
> I'm wondering about that as well... (a little)... I mean, maybe the way
> to be really consistent (especially with the Zen of Python, explicit is
> better than implicit) that int --> float --> complex (imaginary) should
> not occur either !
>
> I think folks would baulk at that though... big-time.


Guido regards the number classes as subtypes of abstract number.
Given a==d, and b==e, he believes that after
c = a op b
f = d op e
then c == f should be true (in so far as possible).
This is why he wanted to change int division.

In other words, he wants Python math to pretty much imitate calculators,
on the basis that this is what most users expect and want.

This goes along with Python's general
polymorphism/genericity/duck-typing philosophy. It is no different from
the fact that one can write generic algorithms that give equivalent
answers for equivalent inputs of ordered collections or indexable sequences.

> So, bottom line here... if my students want to get numbers into their
> programs in 3.x then the correct way to handle the imput() would be:
>
> n = int(input("enter num > "))


Yes.

> ... and then let the interpreter throw an exception if the input cannot
> be type cast to int?


Converted (not cast) to int or float or complex or anything else other
than strl.

--
Terry Jan Reedy

 
Reply With Quote
 
Gregory Ewing
Guest
Posts: n/a
 
      04-26-2011
harrismh777 wrote:
> maybe the way
> to be really consistent (especially with the Zen of Python, explicit is
> better than implicit) that int --> float --> complex (imaginary) should
> not occur either !


Applying parts of the Zen selectively can be dangerous.
Practicality also beats purity. I've used a language
where there was no automatic promotion from ints to
floats, and it was a pain in the backside.

--
Greg
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Trouble with CGI code from Code Example 7.3 of the "Python Interactive CGI Tutorial" epsilon Python 4 08-22-2007 02:41 AM
Interactive/Non-interactive ASPX ? WJ ASP .Net 2 02-26-2005 02:54 AM
non Interactive and Interactive AAH Computer Support 0 01-09-2005 04:09 PM
Interactive and non interactive AAH Computer Support 1 01-09-2005 04:01 PM



Advertisments