[Python-Dev] Decimal data type issues (original) (raw)
Tim Peters tim_one at email.msn.com
Wed Apr 14 23:13:45 EDT 2004
- Previous message: [Python-Dev] Decimal data type issues
- Next message: [Python-Dev] Decimal data type issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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, fromstring() should be subsumed by #- Decimal(string), perhaps with via an optional "usecontext" flag #- argument.
You mean something like Decimal(string, usecontext=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 fromstring).
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 #- toscistring() (and for those who haven't read the spec, do #- before you complain about that -- no, you don't always get an #- exponent under toscistring()).
I'm lost here. Are you saying that str() should have the same behaviour that toscistring()?
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.)
- Previous message: [Python-Dev] Decimal data type issues
- Next message: [Python-Dev] Decimal data type issues
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]