[Python-Dev] C Decimal - is there any interest?

[Mark Dickinson]

On 10/16/07, Fredrik Johansson <fredrik.johansson at gmail.com> wrote:
> There is another alternative, which is to use integers exclusively for
> both representation and arithmetic, and only compute an explicit digit
> tuple or string in special cases. I'm doing this in in mpmath
> (http://code.google.com/p/mpmath/), which is about 10x faster than
> decimal.py at low precision (and of course asymptotically much
> faster). However, a significant part of that improvement may not be
> possible to achieve when the rounding has to be done in decimal
> instead of binary.

This is something that I've also thought about on a number of
occasions.  Rounding would be a major concern here: a simple linear
operation (e.g. rounding a 2n-digit number to n digits) would become
quadratic, or at best subquadratic with fancy division algorithms.
There are also some esoteric functions in the decimal library that
require easy access to decimal digits, for example the logical
operations logical_and, logical_xor, etc., that would be slowed by
this approach.  But it may well be that for normal use this would be
the best way to go for decimal.py.  Perhaps some testing is in
order...

> A more radical proposal would be to change Python's long type to use a
> radix-10**n representation (Python 3000 or beyond?).

Mightn't this produce significant (constant factor) slowdowns for long
performance?  As I understand it, the main problem with a base 10**n
representation is that, for example, extracting the high and low limbs
of the 2-limb result of a 1-limb by 1-limb multiplication requires a
division, whereas for integers stored in binary that division can be
replaced by bit operations.

> An implementation
> of decimal floating-point arithmetic on top of it, whether written in
> C or pure Python (if some utility C functions such as for counting the
> number of digits an integer were available), would be both
> light-weight and efficient at high precision.

Agreed.  But it might be hard to sell a more efficient decimal module
at the expense of slower integer arithmetic in core Python.

Mark