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.09673216 0+02]
>>> for a in x:
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.09673216 0+02]
>>> for a in x:
andrew.macke...@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:
> 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.09673216 0+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'
> 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)?
