array precision

Barry Drake bldrake1 at yahoo.com
Thu Feb 7 16:19:30 CET 2002


Michael Hudson <mwh at python.net> wrote in message news:<ug04da4k1.fsf at python.net>...
> bldrake1 at yahoo.com (Barry Drake) writes:
> 
> > Maybe I'm missing something, but here is what I get:
> 
> Well, I'm missing your point.
> 
> > Python 2.1.1 (#20, Jul 26 2001, 11:38:51) [MSC 32 bit (Intel)] on
> > win32
> > Type "copyright", "credits" or "license" for more information.
> > IDLE 0.8 -- press F1 for help
> > >>> import math
> > >>> n = 10
> > >>> nf = 10.0
> > >>> a = 1.0
> > >>> b = 0.5
> > >>> a/n
>  0.10000000000000001
> > >>> b + a/n
>  0.59999999999999998
> > >>> a/nf
>  0.10000000000000001
> > >>> b + a/nf
>  0.59999999999999998
> > >>> 
> > 
> > Python does double precision floats only (see Python Essential
> > Reference 2nd ed. by David Beazley, p.23).
> 
> But you can have arrays (as in, objects of type array.ArrayType) that
> store C single floats.  Which was Jason's point.
> 
> > Python implements IEEE 754: 17 digits of precision with exponent in
> > -308 to 308.
> 
> Oh No It Doesn't.  Python uses (for the objects of type
> types.FloatType) whatever the C compiler that compiled it called
> "double".  This may be IEEE 754 doubles on the platforms you've used,
> but there's certainly no guarantee of that (e.g. Crays, IBM boxes (I
> think)).
> 
> >          float     double
> > python   64 bits   64 bits
> > C        32 bits   64 bits
> 
> "python double" is meaningless.
> 
> > BTW, you might want to check out the Numeric module in the NumPy
> > distribution at http://numpy.sourceforge.net.
> 
> That lets you store floats or doubles too.
> 
> Cheers,
> M.

Michael,
Your message refers to my first post, which was missing the last line
of the output.  That being the actual point of my message I will
include it here:

Python 2.1.1 (#20, Jul 26 2001, 11:38:51) [MSC 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import math
>>> n = 10
>>> nf = 10.0
>>> a = 1.0
>>> b = 0.5
>>> a/n
0.10000000000000001
>>> b + a/n
0.59999999999999998
>>> a/nf
0.10000000000000001
>>> b + a/nf
0.59999999999999998
>>> b
0.5
>>> 1.0 + (0.6 - (b + a/n))
1.0

This shows that the computer "sees" Jason's output as 0.6 within the
numerical precision of the machine.  Perhaps I was answering the wrong
question, which I understood to be that Jason was seeing ("suposing
that n=10 we get: myArray[0] = 0.600000023 ("something like this")")
different results than he thought he should ("but if i do: myArray[i]
+ (1.0/n) it give's me 0.6").  If I was wrong, I stand corrected.

Also, regarding the double vs float (C types), I was talking about the
default behavior of Python, which I thought Jason was using.  You are
correct, and I learned something new, that NumPy has a variety of
Floatnn types, which is very cool.  They also say in the paragraph
following the discussion of Floatnn that this is an add-on to the
default in Python which is Float64.



More information about the Python-list mailing list