Message93500
Hmm. The problem here is that the specification says nothing at all
about what should happen if the integer result does *not* fit in the
available precision, so in this case we went with the decNumber
behaviour.
Rather than rounding, I'd say that a more useful result in this case
would be to signal InvalidOperation, on the basis that an inexact result
from logb is likely to invalidate most uses of it.
Maybe we should ask Mike Cowlishaw what the intended behaviour here is?
IEEE 754-2008 (section 5.3.3) requires that languages define a
'logBFormat' type that's always big enough to hold the logB result. If
the result is a Decimal, one way to ensure this would be to place
constraints on the allowable values emax and emin for a given precision. |
|
Date |
User |
Action |
Args |
2009-10-03 16:10:36 | mark.dickinson | set | recipients:
+ mark.dickinson, skrah |
2009-10-03 16:10:36 | mark.dickinson | set | messageid: <1254586236.1.0.285686197207.issue7048@psf.upfronthosting.co.za> |
2009-10-03 16:10:34 | mark.dickinson | link | issue7048 messages |
2009-10-03 16:10:34 | mark.dickinson | create | |
|