RE: [Python-Dev] Decimal data type issues
#- > DEFAULT_MAX_EXPONENT = 999999999 #- > DEFAULT_MIN_EXPONENT = -999999999 #- > ABSOLUTE_MAX_EXP = 999999999 #- > ABSOLUTE_MIN_EXP = -999999999
I can think of at least one real use for exponents outside this range: probabilities. E.g., if I'm using probabilistic models to estimate P(author|text), I end up multiplying together a large number of very low probabilities, and the total probability could easily get this small. Of course, people usually use tricks to avoid underflow: taking logs, and if necessary performing periodic re-normalization (which means that you don't have probabilities anymore, just some sort of likelihood measures). But it might be nice to not have to do those tricks. I'm +1 for following the lead set by Long, and not adding unnecessary limits. -Edward
#- > DEFAULT_MAX_EXPONENT = 999999999 #- > DEFAULT_MIN_EXPONENT = -999999999 #- > ABSOLUTE_MAX_EXP = 999999999 #- > ABSOLUTE_MIN_EXP = -999999999
[Edward Loper]
I can think of at least one real use for exponents outside this range: probabilities. E.g., if I'm using probabilistic models to estimate P(author|text), I end up multiplying together a large number of very low probabilities, and the total probability could easily get this small.
No, it couldn't -- and if you worked hard to contrive an example, a probability in the end smaller than the probability that the universe will spontaneously decide to run time backwards for a century is accurately enough represented by 0 (which your example will underflow to).
Tim Peters wrote:
I can think of at least one real use for exponents outside this range: probabilities. E.g., if I'm using probabilistic models to estimate P(author|text), I end up multiplying together a large number of very low probabilities, and the total probability could easily get this small.
No, it couldn't -- and if you worked hard to contrive an example, a probability in the end smaller than the probability that the universe will spontaneously decide to run time backwards for a century is accurately enough represented by 0 (which your example will underflow to).
As long as the limits are soft (and can be changed), I won't object too strenuously, because someone who wanted extremely large/small numbers could use them. But... - I do believe that there will be use cases for exponents outside this range. Just because there's no physical quantities that are reasonably measured with these numbers, doesn't mean that there won't be abstract quantities that are reasonably measured with huge numbers. - I don't believe that signaling an error when a number goes outside this range will help catch any errors. What type of error are we expecting to catch here? If this is such a problem, then why doesn't long also have a max/min? Basically, I don't see much loss from adding the constraints, but I also see very little gain. -Edward
Edward Loper wrote:
As long as the limits are soft (and can be changed), I won't object too strenuously, because someone who wanted extremely large/small numbers could use them. But...
- I do believe that there will be use cases for exponents outside this range. Just because there's no physical quantities that are reasonably measured with these numbers, doesn't mean that there won't be abstract quantities that are reasonably measured with huge numbers.
There's no reason that if these use cases become common enough to care about, that a future version of Python couldn't increase or eliminate the limits. It's a lot easier to remove limits (e.g. the int/long unification) than to add them. I'm +0 on having the limits there initially, even if they complicate the implementation somewhat. I'm highly unlikely to ever encounter them, just as I've never produced a long large enough to cause problems. Tim Delaney
[Edward Loper]
... - I do believe that there will be use cases for exponents outside this range. Just because there's no physical quantities that are reasonably measured with these numbers, doesn't mean that there won't be abstract quantities that are reasonably measured with huge numbers.
You don't have a real use case, Edward (if you did, you would have given it by now <wink>). YAGNI. Note that GNU GMP's arbitrary-precision float types also have bounds on exponent magnitude (but not on precision) -- this is conventional.
- I don't believe that signaling an error when a number goes outside this range will help catch any errors. What type of error are we expecting to catch here?
Overflow, and possibly underflow. Typical when a correct iterative algorithm is fed an input outside its radius of convergence, or an incorrect iterative algorithm is fed anything.
If this is such a problem, then why doesn't long also have a max/min?
For the same reason Decimal doesn't have a bound on precision: exact calculations can require any number of digits. Exponents kick in when the calculation becomes approximate (when precision is exceeded).
participants (4)
-
Edward Loper -
Tim Delaney -
Tim Peters -
Tim Peters