[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.)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4