[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review (original) (raw)

Victor Stinner victor.stinner at gmail.com
Fri Feb 17 12:33:51 CET 2012

Maybe it's okay to wait a few years on this, until either 128-bit floats are more common or cDecimal becomes the default floating point type? In the mean time for clock freaks we can have a few specialized APIs that return times in nanoseconds as a (long) integer.

I don't think that the default float type does really matter here. If I understood correctly, the major issue with Decimal is that Decimal is not fully "compatible" with float: Decimal+float raises a TypeError.

Can't we improve the compatibility between Decimal and float, e.g. by allowing Decimal+float? Decimal (base 10) + float (base 2) may loss precision and this issue matters in some use cases. So we still need a way to warn the user on loss of precision. We may add a global flag to allow Decimal+float and turn it on by default. Developers concerns by loss of precision can just turn the flag off at startup. Something like what we did in Python 2: allow str+unicode, and only switch to unicode when unicode was mature enough and well accepted :-)

--

I have some questions about 128-bit float and Decimal.

Currently, there is only one hardware supporting "IEEE 754-2008 the 128-bit base-2": the IBM S/390, which is quite rare (at least on desktop :-)). Should we expect more CPU supporting this type in the (near) future? GCC, ICC and Clang implement this type in software, but there are license issues. At least with GCC which uses MPFR: the library is distributed under the GNU LGPL license, which is not compatible with the Python license. I didn't check Clang and ICC. I don't think that we can use 128-bit float by default before it is commonly available on hardware, because arithmetic in software is usually slower. We do also support platforms with a compiler not supporting 128-bit float, e.g. Windows with Visual Studio 2008.

floating point in base 2 has also an issue with timestamp using 10^k resolution: such timestamp cannot be represented exactly in base 2 because 5 is coprime with 2 (10=2*5). The loss of precision is smaller than 10^-9 (nanosecond) with 128-bit float (for Epoch timestamps), but it would be more "natural" to use the base 10.

System calls and functions of the C standard library use types with 10^k resolution:

decimal and cdecimal (_decimal) have the same performance issue, so I don't expect them to become the standard float type. But Decimal is able to store exactly a timetamp with a resolution of 10^k.

There are also IEEE 754 for floating point types in base 10: decimal floating point (DFP), in 32, 64 and 128 bits. IBM System z9, System z10 and POWER6 CPU support these types in hardware. We may support this format in a specific module, or maybe use it to speedup the Python decimal module. But same issue here, such hardware is also rare, so we cannot use them by default or rely on them.

Victor

More information about the Python-Dev mailing list