ANN: Decimal.py 0.0.0
tim.one at home.com
Sun May 20 04:48:21 CEST 2001
> 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).
> 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:
> 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.
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:
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