[Python-Dev] Decimal data type issues

Michael Chermside mcherm at mcherm.com
Thu Apr 15 09:32:23 EDT 2004


Andrew P. Lentvorski writes:
> As for the value of the default limits, I would actually choose both a
> default precision and exponent limit which would be within the range
> represented by a double precision floating point number.

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.

On the other hand, your argument seems to be that it will make it easy
to convert between floats and Decimals. I disagree... if there were
simple easy ways to convert between floats and Decimals (like a
Decimal constructor that took a float) then people who didn't know
better would use them and then start running into all sorts of errors
due to floating point imprecision -- the very thing that Decimal is
supposed to save us from. That's why we EXPLICITLY chose to make it
possible but somewhat awkward to convert to/from floats.

You can't hide the difficulties inherent in (binary) floating point
by just sweeping them under the rug. And Decimal can't make it easier
and better (at some cost of performance and additional complexity) if
you attempt to tie it to float.

As for the limits themselves, I remain -0 on them. Doesn't pose a
problem for me but why would you bother? Of course, Tim and others
have posted answers to this question, mostly just so people will
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()).

I-never-make-errors-anyway-lly yours,

-- Michael Chermside




More information about the Python-Dev mailing list