[Python-Dev] Round Bug in Python 1.6?

[Ka-Ping Yee]

Tim Peters wrote:
> The best possible IEEE-754 double approximation to 3.1416 is (exactly)
> 
> 3.141599999999999948130380289512686431407928466796875

Let's call this number 'A' for the sake of discussion.

> so the output you got is correctly rounded to 17 significant digits.  IOW,
> it's a feature.

Clearly there is something very wrong here:

    Python 1.5.2+ (#2, Mar 28 2000, 18:27:50)
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    >>> 3.1416
    3.1415999999999999
    >>>

Now you say that 17 significant digits are required to ensure
that eval(repr(x)) == x, but we surely know that 17 digits are
*not* required when x is A because i *just typed in* 3.1416 and
the best choice of double value was A.

I haven't gone and figured it out, but i'll take your word for
it that 17 digits may be required in *certain* cases to ensure
that eval(repr(x)) == x.  They're just not required in all cases.

It's very jarring to type something in, and have the interpreter
give you back something that looks very different.  It breaks a
fundamental rule of consistency, and that damages the user's
trust in the system or their understanding of the system.  (What
do you do then, start explaining the IEEE double representation
to your CP4E beginner?)

What should really happen is that floats intelligently print in
the shortest and simplest manner possible, i.e. the fewest
number of digits such that the decimal representation will
convert back to the actual value.  Now you may say this is a
pain to implement, but i'm talking about sanity for the user here.

I haven't investigated how to do this best yet.  I'll go off
now and see if i can come up with an algorithm that's not
quite so stupid as

    def smartrepr(x):
        p = 17
        while eval('%%.%df' % (p - 1) % x) == x: p = p - 1
        return '%%.%df' % p % x



-- ?!ng