> 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.
Ping has a point!
> 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
Have a look at what Java does; it seems to be doing this right:
& jpython
JPython 1.1 on java1.2 (JIT: sunwjit)
Copyright (C) 1997-1999 Corporation for National Research Initiatives
>>> import java.lang
>>> x = java.lang.Float(3.1416)
>>> x.toString()
'3.1416'
>>> ^D
&
Could it be as simple as converting x +/- one bit and seeing how many
differing digits there were? (Not that +/- one bit is easy to
calculate...)
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4