[Kay Schluehr]
>> This is interesting. If we define
>>
>> def f():
>> print str(1.1)
>>
>> and disassemble the function, we get:
>>
> dis.dis(f)
> 2 0 LOAD_GLOBAL 0 (str)
> 3 LOAD_CONST 1 (1.1000000000000001) # huh?
[Fredrik Lundh]
> huh huh?
>
> >>> str(1.1)
> '1.1'
> >>> repr(1.1)
> '1.1000000000000001'
> >>> "%.10g" % 1.1
> '1.1'
A more interesting one is:
"%.12g" % a_float
because that's closest to what str(a_float) produces in Python.
repr(a_float) is closest to:
"%.17g" % a_float
> >>> "%.20g" % 1.1
> '1.1000000000000001'
> >>> "%.30g" % 1.1
> '1.1000000000000001'
> >>> "%.10f" % 1.1
> '1.1000000000'
> >>> "%.20f" % 1.1
> '1.10000000000000010000'
> >>> "%.30f" % 1.1
> '1.100000000000000100000000000000'
The results of most of those (the ones asking for more than 17
significant digits) vary a lot across platforms. The IEEE-754
standard doesn't wholly define output conversions, and explicitly
allows that a conforming implementation may produce any digits
whatsoever at and after the 18th signficant digit. when converting a
754 double to string. In practice, all implementations I know of that
exploit that produce zeroes at and after the 18th digit -- but they
could produce 1s instead, or 9s, or digits from pi, or repetitions of
the gross national product of Finland in 1967. You're using one of
those there, probably Windows. glibc does conversions "as if to
infinite precision" instead, so here on a Linux box:
>>> "%.20g" % 1.1
'1.1000000000000000888'
>>> "%.30g" % 1.1
'1.10000000000000008881784197001'
>>> "%.50g" % 1.1
'1.1000000000000000888178419700125232338905334472656'
>>> "%.100g" % 1.1
'1.100000000000000088817841970012523233890533447265625'
The last one is in fact the exact decimal representation of the 754
double closest to the decimal 1.1.
> more here: http://docs.python.org/tut/node16.html
Still, there's always more ;-)
--
http://mail.python.org/mailman/listinfo/python-list
