Mark Dickinson <dicki...@gmail.com> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7048> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
