[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: Mike Cowlishaw has confirmed that the tests scbx164, scbx165 (in version 2.59 of the tests) are implementation-specific, so test_decimal is doing the right thing in skipping them. So I think this issue can be closed. I don't think it's worth removing the restriction on the 2nd scaleb argument: while I still think it's arbitrary and unnecessary, keeping it allows us to say that we're in full compliance with the specification. -- resolution: - fixed status: open - closed ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: There's a restriction on the second argument to scaleb in the spec, namely that scaleb should be in the range -2*(Emax + precision) to 2*(Emax + precision) inclusive. This restriction seems entirely arbitrary and unnecessary to me. My guess is that it's there to ease implementation in low-level languages, but it makes little sense for the Python implementation. Here's a patch that removes this restriction on scaleb in the Python implementation, and skips the corresponding tests. -- Added file: http://bugs.python.org/file15411/scaleb.patch ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Changes by Mark Dickinson dicki...@gmail.com: -- priority: high - normal ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: logb fix applied to release26-maint in r75804. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: Updated release26-maint to new test-suite in r75806. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: I just want to note another problem with logb: it doesn't use the correct context when processing NaNs. This needs a test and a fix. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: Sorry; ignore that last. I was confused by the fact that the _check_nans call came before the 'if context is None' test. But _check_nans deals correctly with a context of None, so logb is fine. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: I've updated to the newest version of the test-suite in r75285 through r75287. As before, r75285 needs to be backported to the 2.6 maintenance branch once its unfrozen. I'm currently skipping those two scaleb tests, until we work out what should be going on here. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: (Stefan emailed Mike Cowlishaw about this: thanks, Stefan!) Mike's initial response suggests that we *should* be rounding the result here. That is, decNumber and decimal.py are both in error, and Stefan's interpretation is correct. -- assignee: - mark.dickinson components: +Library (Lib) priority: - high stage: - test needed type: - behavior versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: Attaching additional testcases from Mike Cowlishaw. -- Added file: http://bugs.python.org/file15067/logb_additional.decTest ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Mike's response makes sense to me. If the precision is 2, the result should round to that precision. The documents showing the theory behind the decimal spec indicate that in general mathematical operations are exact, only the results get rounded. Also IIRC, the use of InvalidOperation is limited to the mathematical part, not the rounding step. -- nosy: +rhettinger ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: Patch to update to the most recent official set of tests. With this patch, logb and scaleb fail. -- keywords: +patch Added file: http://bugs.python.org/file15070/decimal_testcases.patch ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: Patch to fix logb. -- Added file: http://bugs.python.org/file15071/logb.patch ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: I don't understand the new scaleb testcases (from Mike). They look like this: precision: 34 maxExponent: 9 minExponent: -9 -- integer overflow in 3.61 or earlier scbx164 scaleb 1E-9 -12 - NaN Invalid_operation -- out of range scbx165 scaleb -1E-9 +12 - NaN Invalid_operation The specification says that the second operand should be in the range +/-2*(Emax+precision) inclusive, which in this case it is. So clearly there are additional situations in which Invalid_operation should be signalled. It's not clear to me what those conditions are. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: The IEEE 754-2008 description of scaleB makes a lot more sense, IMO: scaleB(x, N) is simply x*10**N (assuming that B=10 and N is integral), rounded in the usual way. The restriction in the specification seems arbitrary and questionable. Presumably it's intended to aid implementation in low-level languages. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Mark Dickinson dicki...@gmail.com added the comment: Applied the fix for logb in r75275 (trunk), r75276 (py3k) and r75277 (release31-maint). r75275 still needs to be merged to the release26-maint branch once it's unfrozen. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
Stefan Krah stefan-use...@bytereef.org added the comment: precision: 34 maxExponent: 9 minExponent: -9 -- integer overflow in 3.61 or earlier scbx164 scaleb 1E-9 -12 - NaN Invalid_operation -- out of range scbx165 scaleb -1E-9 +12 - NaN Invalid_operation I would say that this is implementation specific, as a workaround for the overflow. This isn't in the spec at the moment. -- ___ 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
[issue7048] decimal.py: logb: round the result if it is greater than prec
New submission from Stefan Krah stefan-use...@bytereef.org:
from decimal import *
c = getcontext()
c.prec = 2
c.logb(Decimal(1E123456))
Decimal('123456')
This result agrees with the result of decNumber, but the spec says:
All results are exact unless an integer result does not fit in the
available precision.
My interpretation is that the result should be 1.2E+5.
--
messages: 93492
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: logb: round the result if it is greater than prec
___
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
[issue7048] decimal.py: logb: round the result if it is greater than prec
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
