ANN: Decimal.py 0.0.0

[Tim Peters]

[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