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

Stefan Krah stefan at bytereef.org
Fri Feb 17 14:03:10 CET 2012


Victor Stinner <victor.stinner at gmail.com> wrote:
> 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. 

I think this should be discussed in a separate thread. It's getting
slightly difficult to follow all the issues raised here.


> decimal and cdecimal (_decimal) have the same performance issue,
> don't expect them to become the standard float type.

Well, _decimal in tight loops is about 2 times slower than float.

There are areas where _decimal is actually faster than float, e.g
in the cdecimal repository printing and formatting seems to be
significantly faster:

$ cat format.py 
import time
from decimal import Decimal

d = Decimal("7.928137192")
f = 7.928137192

out = open("/dev/null", "w")

start = time.time()
for i in range(1000000):
    out.write("%s\n" % d)
end = time.time()
print("Decimal: ", end-start)

start = time.time()
for i in range(1000000):
    out.write("%s\n" % f)
end = time.time()
print("float: ", end-start)


start = time.time()
for i in range(1000000):
    out.write("{:020,.30}\n".format(d))
end = time.time()
print("Decimal: ", end-start)

start = time.time()
for i in range(1000000):
    out.write("{:020,.30}\n".format(f))
end = time.time()
print("float: ", end-start)


$ ./python format.py 
Decimal:  0.8835508823394775
float:  1.3872010707855225
Decimal:  2.1346139907836914
float:  3.154278039932251


So it would make sense to profile the exact application in order to
determine the suitability of _decimal for timestamps.


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

Apart from the rarity of these systems, decimal.py is arbitrary precision.
If I restricted _decimal to DECIMAL64, I could probably speed it up further.


All that said, personally I wouldn't have problems with a chunked representation
that includes nanoseconds, thus avoiding the decimal/float discusion entirely.
I'm also a happy user of:

http://cr.yp.to/libtai/tai64.html#tai64n



Stefan Krah




More information about the Python-Dev mailing list