Float to String "%.7e" - diff between Python-2.6 and Python-2.7

[andrew....@3ds.com]

When formatting a float using the exponential format, the rounding is different in Python-2.6 and Python-2.7. See example below.
Is this intentional?

Is there any way of forcing the Python-2.6 behavior (for compatibility reasons when testing)?

>c:\python26\python
r:\asiData\abaObjects\lib>c:\python26\python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [2.096732130e+02,2.096732140e+02,2.096732150e+02,2.096732151e+02,2.096732160+02]
>>> for a in x:
... print ' %.9e %.7e'%(a,a)
...
2.096732130e+02 2.0967321e+02
2.096732140e+02 2.0967321e+02
2.096732150e+02 2.0967322e+02 <<<<<<<<
2.096732151e+02 2.0967322e+02
4.096732160e+00 4.0967322e+00
>>> for a in x:
... print '%.9e %.7e'%(-a,-a)
...
-2.096732130e+02 -2.0967321e+02
-2.096732140e+02 -2.0967321e+02
-2.096732150e+02 -2.0967322e+02 <<<<<<<<
-2.096732151e+02 -2.0967322e+02
-4.096732160e+00 -4.0967322e+00
>>> ^Z

>c:\python27\python
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [2.096732130e+02,2.096732140e+02,2.096732150e+02,2.096732151e+02,2.096732160+02]
>>> for a in x:
... print ' %.9e %.7e'%(a,a)
...
2.096732130e+02 2.0967321e+02
2.096732140e+02 2.0967321e+02
2.096732150e+02 2.0967321e+02 <<<<<<<<
2.096732151e+02 2.0967322e+02
4.096732160e+00 4.0967322e+00
>>> for a in x:
... print '%.9e %.7e'%(-a,-a)
...
-2.096732130e+02 -2.0967321e+02
-2.096732140e+02 -2.0967321e+02
-2.096732150e+02 -2.0967321e+02 <<<<<<<<
-2.096732151e+02 -2.0967322e+02
-4.096732160e+00 -4.0967322e+00
>>> ^Z

>
Andrew MacKeith

[Duncan Booth]

andrew....@3ds.com wrote:

> When formatting a float using the exponential format, the rounding is
> different in Python-2.6 and Python-2.7. See example below. Is this
> intentional?
>
> Is there any way of forcing the Python-2.6 behavior (for compatibility
> reasons when testing)?
>

It isn't Python 2.6 behaviour, it looks more like a bug in your particular
version of 2.6. This one matches what you are seeing on 2.7:

[dbooth@localhost ~]$ /opt/local/bin/python2.6
Python 2.6.7 (r267:88850, Jan 5 2012, 16:18:48)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-51)] on linux2

Type "help", "copyright", "credits" or "license" for more information.
>>> x = [2.096732130e+02,2.096732140e+02,2.096732150e+02,2.096732151e+
02,2.096732160+02]

>>> for a in x:
... print ' %.9e %.7e'%(a,a)
...
2.096732130e+02 2.0967321e+02
2.096732140e+02 2.0967321e+02
2.096732150e+02 2.0967321e+02
2.096732151e+02 2.0967322e+02
4.096732160e+00 4.0967322e+00

Note that the rounding shown here is correct; the actual value is slightly
less than 5 in the last place:

[dbooth@localhost ~]$ /opt/local/bin/python2.6 -c "print('%.20e'%
2.096732150e+02,'%.7e'%2.096732150e+02)"
('2.09673214999999999009e+02', '2.0967321e+02')

What do you get printing the value on 2.6 with a '%.20e' format? I seem to
remember that 2.7 rewrote float parsing because previously it was buggy.

--
Duncan Booth http://kupuguy.blogspot.com

[Dave Angel]

On 10/30/2012 10:47 AM, andrew....@3ds.com wrote:
> When formatting a float using the exponential format, the rounding is different in Python-2.6 and Python-2.7. See example below.
> Is this intentional?
>
> Is there any way of forcing the Python-2.6 behavior (for compatibility reasons when testing)?
>
>> c:\python26\python
> r:\asiData\abaObjects\lib>c:\python26\python
> Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> x = [2.096732130e+02,2.096732140e+02,2.096732150e+02,2.096732151e+02,2.096732160+02]
>>>> for a in x:
> ... print ' %.9e %.7e'%(a,a)
> ...
> 2.096732130e+02 2.0967321e+02
> 2.096732140e+02 2.0967321e+02
> 2.096732150e+02 2.0967322e+02 <<<<<<<<
> 2.096732151e+02 2.0967322e+02
> 4.096732160e+00 4.0967322e+00
>

Looks to me that the indicated value was rounded wrong in 2.6, so
apparently that was fixed in 2.7

The actual binary fp value stored for 2.096732150 e+02 is slightly
smaller than the decimal string specified, so it'll round towards
1.0967321 when you specify 7 digits.

I don't know of any way to re-introduce the earlier version. But you
could fix them both by using Decimal, where there's no quantization
error. Or if this is a fake example, adapt by just validating that the
results are 'close'

--

DaveA

[Mark Dickinson]

<andrew.mackeith <at> 3ds.com> writes:

> When formatting a float using the exponential format, the rounding is
> different in Python-2.6 and Python-2.7. See example below. Is this
> intentional?

Yes, in a sense. Python <= 2.6 uses the OS-provided functionality (e.g., the C
library's strtod, dtoa and sprintf functions) to do float-to-string and
string-to-float conversions, and hence behaves differently from platform to
platform. In particular, it's common for near halfway cases (like the one
you're looking at here) and tiny numbers to give different results on different
platforms. Python >= 2.7 has its own built-in code for performing
float-to-string and string-to-float conversions, so those conversions are
platform- independent and always correctly rounded. (Nitpick: it's still
theoretically possible for Python 2.7 to use the OS code if it can't determine
the floating-point format, or if it can't find a way to ensure the proper FPU
settings, but I don't know of any current platforms where that's the case.)

> Is there any way of forcing the Python-2.6 behavior (for compatibility
> reasons when testing)?

Not easily, no.

--
Mark