[posted & mailed]
[Christian Tismer]
> as a side effect, I happened to observe the following rounding bug.
> It happens in Stackless Python, which is built against the
> pre-unicode CVS branch.
>
> Is this changed for 1.6, or might it be my bug?
It's a 1.6 thing, and is not a bug.
> D:\python\spc>python
> Python 1.5.42+ (#0, Mar 29 2000, 20:23:26) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> round(3.1415926585, 4)
> 3.1415999999999999
> >>> ^Z
The best possible IEEE-754 double approximation to 3.1416 is (exactly)
3.141599999999999948130380289512686431407928466796875
so the output you got is correctly rounded to 17 significant digits. IOW,
it's a feature.
1.6 boosted the number of decimal digits repr(float) produces so that
eval(repr(x)) == x
for every finite float on every platform with an IEEE-754-conforming libc.
It was actually rare for that equality to hold pre-1.6. repr() cannot
produce fewer digits than this without allowing the equality to fail in some
cases.
The 1.6 str() still produces the *illusion* that the result is 3.1416 (as
repr() also did pre-1.6).
IMO it would be better if Python stopped using repr() (at least by default)
for formatting expressions at the interactive prompt (for much more on this,
see DejaNews).
the-two-things-you-can-do-about-it-are-nothing-and-love-it<wink>-ly
y'rs - tim
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