[Python-3000] Reconsider repr(0.1) == '0.10000000000000001'

[Noam Raphael]

Ok, I wrote a patch! http://bugs.python.org/issue1580

Now you have:

>>> 1.1
1.1

It works! And it passes the test suite! I added a test which takes a
list of about a 1000 floating point numbers which were designed to
check binary to decimal conversion.

It turns out that Tcl implemented this algorithm for tcl8.5 (which is
currently in beta stage). See
http://www.tcl.tk/cgi-bin/tct/tip/132.html for the TIP (that's how
they call a PEP...) I took the formatting function (which is quite
simple) from them. For the main algorithm, which converts a double to
the shortest list of digits needed to recreate it, I used the code by
Robert G. Burger (the author of the article) since it is stand-alone.
The original code can be found here:
http://www.cs.indiana.edu/~burger/fp/index.html

The patch is against current py3k svn.

Have a good day,
Noam


2007/12/9, Noam Raphael <noamraph at gmail.com>:
> Hello,
>
> I would like to re-raise the issue of float repr() -- making repr(1.1)
> == '1.1' instead of '1.1000000000000001'.
>
> My use case is data manipulation in the interactive shell - an
> extremely powerful tool which, it seems, not so many people use. Many
> times I have float data. I think that you'll agree with me that, for
> example:
>
> >>> height['Alice']
> 1.67
>
> Is much easier to understand than
>
> >>> height['Alice']
> 1.6699999999999999
>
> Not to mention
>
> >>> height
> {'David': 1.81, 'Alice': 1.67, 'Bob': 1.76, 'Barbara': 1.65}
>
> Versus:
>
> >>> height
> {'Bob': 1.76, 'Barbara': 1.6499999999999999, 'Alice':
> 1.6699999999999999, 'David': 1.8100000000000001}
>
>
> I think that the reason for the long representation is that it uses a
> simple algorithm that makes "eval(repr(f)) == f" always true. However,
> why not use another, a bit more complex, algorithm, which will still
> preserve "eval(repr(f)) == f", but which will shorten the result when
> it can?
>
> You see, it's not even that the current algorithm is exact - for
> example, the actual, stored, representation of 1.67 is, on my
> computer, 1.1010101110000101000111101011100001010001111010111. The
> exact decimal representation of that number is
> 1.6699999999999999289457264239899814128875732421875. I agree that
> "1.6699999999999999" is better, but isn't "1.67" the best?
>
> Have a good day,
> Noam
>