[Python-Dev] Decimal data type issues

[Tim Peters]

[Batista, Facundo]

...

> The exponent is an integer, and in the actual implementation exists a
> maximum value::
>
> DEFAULT_MAX_EXPONENT = 999999999
> DEFAULT_MIN_EXPONENT = -999999999
> ABSOLUTE_MAX_EXP = 999999999
> ABSOLUTE_MIN_EXP = -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, E_limit , 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 <wink>).


> a. to_sci_string
> b. to_eng_string
> c. from_string
> 
> 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.from_float(25.35) == hash(25.35)

Not defined.

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

Not defined.