[Python-Dev] Decimal data type issues (original) (raw)

Tim Peters tim_one at email.msn.com
Wed Apr 14 00:53:57 EDT 2004

[Batista, Facundo]

...

The exponent is an integer, and in the actual implementation exists a maximum value::

DEFAULTMAXEXPONENT = 999999999 DEFAULTMINEXPONENT = -999999999 ABSOLUTEMAXEXP = 999999999 ABSOLUTEMINEXP = -999999999 The issue is that this limit is artificial: As long it's a long, you should be able to make it as big as your memory let you. In the General Decimal Arithmetic Specification says: In the abstract, there is no upper limit on the absolute value of the exponent. In practice there may be some upper limit, Elimit , on the absolute value of the exponent. So, should we impose an artificial limit to the exponent?

I expect everyone's initial reaction will be to say "no limit", but think two or three times about that. Eliminating any restriction on exponent magnitude is the same as saying overflow can never happen. But overflow is usually a valuable safety net in real life, telling you that your algorithm has gone insane. OTOH, there's nothing with physical significance that requires an exponent anywhere near as large as 999999999, and REXX has used that exponent limit for years without problems.

Everyone should also note that a restriction on exponent size isn't also a restriction on the number of significant digits: if the max exponent is restricted to 999999999, you can still have more than 10**999999999 significant digits (as soon as you buy enough disk space and a CPU with unbounded addresses ).

a. toscistring b. toengstring c. fromstring

The (a) and (b) methods are different from str, as this method just doesn't adjust the exponent at all. Regarding the method (c), the only difference with creating the decimal with Decimal(string) is that method (c) honors the context (if the literal contains more digits that the current precision the numbers get rounded, and gets rounded according to the round method specified in context, etc).

(c) also specifies ways to spell special values, like NaNs and infinities. Does Decimal(string)? I don't believe the PEP covered that.

In any case, from_string() should be subsumed by Decimal(string), perhaps with via an optional "use_context" flag argument.

It's quite arguable that str() should be exactly the standard's to_sci_string() (and for those who haven't read the spec, do before you complain about that -- no, you don't always get an exponent under to_sci_string()).

Hash behaviour --------------

Decimals that happen to be exact integers must return the same hash codes as the hash codes of the ints or longs they're equal to. All bets are off wrt hash codes for non-integral Decimals (e.g., hash(Decimal('1.5')) may or may not be the same as hash(1.5)); promising more than that is simply impractical.

BTW, hash(Decimal('1.0')) must be the same as hash(Decimal('1.00')) must be the same as hash(Decimal('0.001e3')) despite that they have different internal representations.

...

Should the following be true?::

hash(Decimal(25)) == hash(25)

Yes.

hash(Decimal.fromfloat(25.35) == hash(25.35)

Not defined.

hash(Decimal('-33.8')) == hash(-33.8)

Not defined.

More information about the Python-Dev mailing list