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

[Victor Stinner]

> 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:

 - 1 (time_t): time(), mktime(), localtime(), sleep(), ...
 - 10^-3 (int): poll()
 - 10^-6 (timeval, useconds_t): select(), gettimeofday(), usleep(), ...
 - 10^-9 (timespec): nanosleep(), utimensat(), clock_gettime(), ...

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