[Python-Dev] Backport new float repr to Python 2.7?

[Raymond Hettinger]

[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