ANN: Decimal.py 0.0.0
Tim Peters
tim.one at home.com
Sat May 19 22:48:21 EDT 2001
[Tim]
> I'll add that I encouraged Aahz to implement a sequence-based
> prototype in Python, so that if this pans out, the algorithms can
> be migrated easily to C for speed (functions slinging tuples of
> small ints in Python will be easy to recast as C functions slinging
> pointer-to-small-int+length pairs).
[Steve Williams]
> Speed is not the issue. You don't use decimal arithmetic for
> eigenvalues or raytracing.
Tell you what: use my FixedPoint.py class for all your daily "speed doesn't
matter" numeric work, *then* tell me it doesn't matter:
ftp://ftp.python.org/pub/python/contrib-09-Dec-1999/
DataStructures/FixedPoint.py
> I did a study of decimal arithmetic in COBOL programs back in the
> dark ages and found that, mostly, decimal arithmetic is a negligible
> part of the commercial processing load.
That's why we're settling for a base-10 representation, plus that in
commercial work, the speed of string<->internal conversions is very important
indeed (you didn't say exactly which operations "decimal arithmetic" covered
in your view, but conversions are part of it in mine).
> One seldom inverts a matrix in a payroll program.
Sure, although the importance of apps combining massive databases with major
number-crunching has skyrocketed since "the dark ages".
> Decimal arithmetic is not about speed, it's about doing the right thing.
> [etc]
So long as it's too slow to use for anything else, that seems tautological.
But argue about it with IBM; Aahz is implementing their proposal:
http://www2.hursley.ibm.com/decimal/
The FAQ entry "Surely software emulation of decimal arithmetic is fast
enough?" whines about C speed for this stuff. You haven't suffered until
you've worked with it at Python speed <wink>. If this is successful, it will
be a candidate for replacing binary floating-point as the default floating
type in Python.
speed-doesn't-matter-if-you're-not-in-the-race-ly y'rs - tim
More information about the Python-list
mailing list