This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients mark.dickinson, skrah
Date 2009-10-03.16:10:34
SpamBayes Score 7.17211e-08
Marked as misclassified No
Message-id <1254586236.1.0.285686197207.issue7048@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-10-03 16:10:36mark.dickinsonsetrecipients: + mark.dickinson, skrah
2009-10-03 16:10:36mark.dickinsonsetmessageid: <1254586236.1.0.285686197207.issue7048@psf.upfronthosting.co.za>
2009-10-03 16:10:34mark.dickinsonlinkissue7048 messages
2009-10-03 16:10:34mark.dickinsoncreate