[Python-Dev] Decimal data type issues

[Tim Peters]

[Facundo Batista, on max exponent]
> But it's still an artificial restriction.  We have no-limit longs,
> should have limited Decimal?

Nobody has a use for unbounded exponents, so it's a silly thing to support
if there are costs.  There are costs, including:

+ As mentioned last time, eliminating bounds on exponents effectively
  means overflow (and underflow) can never happen.  But overflow
  *is* a valuable safety net in real life fp use, like a canary
  in a coal mine, giving danger signs early when a program goes
  insane.  This is of no real interest to you (your real goal is a Money
  type), it's of interest to people who will use Decimal *as* a form
  of floating-point arithmetic (your use cases are more fixed-point).

+ Virtually all implementations of 854 use (and as IBM's standard even
  suggests) "forbidden" exponent values to encode non-finite
  numbers (infinities and NaNs).  A bounded exponent can do this at
  virtually no extra storage cost.  If the exponent is unbounded,
  then additional bits have to be used instead.  This cost remains
  hidden until more time- and space- efficient implementations are
  attempted.

+ Big as it is, the IBM standard is a tiny start at supplying a
  complete numeric facility.  Having no bound on exponent size will
  enormously complicate the implementations of, e.g., decimal sin()
  and cos() (there's then no a priori limit on how many digits of
  pi effectively need to be known in order to perform argument
  reduction).

> And also implies more code and complexity in the module.  But this
> is a side effect and not the primary concern in the decision.

I don't know how it's implemented now.  "The natural way" to check exponent
bounds is in a common routine called at the end of every operation; in that
case, the "more code and complexity" doesn't amount to anything worth
mentioning.

...

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

> You mean something like Decimal(string, use_context=True)?

Yes.

> And when creating from long, for example?

Sure.

> Remember that the spec says that the context affect
> the operations,

Yes.

> not creations (with the exception of from_string).

I don't understand.  The only place the spec uses the word "creation" is in
regard to the creation of context objects.  What do you mean by "creations"?
Context does affect every way of creating a decimal number in the spec; the
only ways to create numbers covered by the spec are via operations (and
from_string isn't a special case here, from_string is just one of the
required operations in the spec, and all operations covered by the spec
respect context).

> #- 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()).

> I'm lost here. Are you saying that str() should have the same behaviour
> that to_sci_string()?

Yes, that str(Decimal) should produce exactly the string the spec specifies
as being the result of its abstract to-sci-string operation.  There's no
requirement to have a method *named* "to_sci_string", the only requirement
is that *some* way to spell to-sci-string's functionality be supplied.  The
meaning of to-sci-string is precisely specified by the standard, and is a
good choice for both str(Decimal) and repr(Decimal).  (It's both
human-readable and exact.)