[Mark Dickinson]
> - string to float *and* float to string conversions are both guaranteed
> correctly rounded in 3.x: David Gay's code implements the conversion
> in both directions, and having correctly rounded string -> float
> conversions is essential to ensure that eval(repr(x)) recovers x exactly.
IMO, that is so important that it should be considered a bug fix.
Recently, I lost a lot of time in a discussion about a piece of mathematical
code returning a wrong answer. The problem wasn't the Python code;
instead, it was the str to float conversion (that we inherit from libc) giving
the wrong answer. The code worked correctly under Py3.1 but not
Py2.6.
IDLE 2.6.2
>>> float('-30000000000000000477086733292797541405082425691835844169343982673243516316511143182440409957570445312.00000000000000000009000000000000000258695827614150149965556917147323765827915398318737061345018446445465087890625')
-2.9999999999999999e+100
Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> float('-30000000000000000477086733292797541405082425691835844169343982673243516316511143182440409957570445312.00000000000000000009000000000000000258695827614150149965556917147323765827915398318737061345018446445465087890625')
-3.0000000000000002e+100
> - the repr of round(x, n) really does have at most n digits after the
> point, giving the semi-illusion that x really has been rounded exactly,
> and eliminating one of the most common user complaints about the
> round function.
This is also an important improvement and makes round() do what
people expect.
> - side effects like finding that float(x) rounds correctly for
> Decimal instances x.
This is also important because other decimal calculations can
often be done exactly and it's a bummer to have an accurate
result thrown off by an incorrect rounding to float.
> - the float <-> string conversions are under our control, so any bugs
> found can be fixed in the Python source. There's no shortage of
> conversion bugs in the wild, and certainly bugs have been observed in
> OS X, Linux and Windows. (The ones I found in OS X 10.5 have
> been fixed in OS X 10.6, though.)
Nice win.
> Thoughts?
+1
I've worked with the 3.1 float reprs for a while and have been delighted.
It was a great improvement.
Raymond
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