[Python-Dev] Decimal data type issues

[Andrew P. Lentvorski, Jr.]

On Thu, 15 Apr 2004, Michael Chermside wrote:

> I strongly object. I have one particular use case for decimal, and I
> consider it to be a very important one.... to store and manipulate
> monetary amounts. Putting a limit as small as that used for floats
> would significantly harm my use case.

I presume that you are objecting to only having a default limit of 15
digits of precision?  I can certainly understand your position.

However, why does having a soft default limit set at this level cause you
an issue?  If you need more, you can move it up.  You have to override the
default precision (currently 8)  anyway.

If you want a default limit much higher than this, then there needs to be
a way for people to determine when they leave the realm of "fast, but
narrower range" and enter the realm of "slow, but much greater range".

What I am trying to establish is a "sensible default" limit which allows
most people to use fast operations, does not limit those people who want
greater range (at the expense of slower operation), does not impose undue
constraints on an optimized version of the module (either software or
later hardware), and provides useful feedback for those who suddenly find
themselves moving from one group to another (either intentionally or
unintentionally).

Part of creating Decimal is to provide a useful module for currency and
other applications which require accurate Decimal arithmetic.

But part of creating Decimal is also to be newbie friendly.  Letting
people know when they pass outside of "sensible" regimes is friendly.

> get overflow errors instead of out-of-memory errors (and possibly
> some vague future advantage to implementers of a "complete
> numerical package" including things like sin() and cos()).

<return sarcasm>
And here I was thinking that someone manipulating financial amounts might
actually need speed on a silly operation known as "division".  My mistake.
</return sarcasm>

-a