[issue1182] Paticular decimal mod operation wrongly output NaN.
Facundo Batista added the comment: Decimal was backported to Py2.5, commited in r59859. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Changes by Facundo Batista: -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Mark Dickinson added the comment: Unfortunately, I think this backport still breaks hash: bernoulli:~/python_source/release25-maint dickinsm$ ./python.exe Python 2.5.2a0 (release25-maint:59859M, Jan 8 2008, 11:54:53) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin Type help, copyright, credits or license for more information. from decimal import * x = Decimal(1.634E100) hash(x) == hash(int(x)) False Do we really want to go from a slow-but-working Decimal.__hash__ in Python 2.5.1 to a fast-but- broken hash in Python 2.5.2? I can fix this (it's a 1-line change), and reinstate the extra hash tests, if you like. Or I can post a patch if you prefer. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Facundo Batista added the comment: Fix it, please. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Mark Dickinson added the comment: hash fixed in revision 59863. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Raymond Hettinger added the comment: If this something missing from Colishaw's test suite, you should submit the result to him so they can include it in the next update. -- nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Mark Dickinson added the comment: I don't think anything's missing from Cowlishaw's test-suite. An old, buggy test (nrmx218) was both renamed (to redx218) and fixed by Cowlishaw. I think Facundo ended up with both tests---so naturally the old, broken test failed. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Facundo Batista added the comment: Mmm... I thought this would be a clean backport... but no. If we just copy the files to 2.5, we get two failures running the tests. - test_hash_method (DecimalUsabilityTest): This is because of the changes we made to the hash builtin in the trunk, and we should avoid this test if version 2.6. - test_normalize: Exception Clamped raised on line nrmx218. I don't have a clue why this one fails. Mark, could you please take a look at it? Thank you! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Mark Dickinson added the comment: You need to remove the old files in decimaltestdata before copying the new ones across: nrmx218 is an old, and buggy, testcase; at some point Mike Cowlishaw renamed normalize.decTest to reduce.decTest. He also renamed the operation from normalize to reduce, but since this name change hasn't made it into the most recent version of the specification it's stayed as normalize in the Python source for now. So it looks like you ended up with an old version of normalize.decTest in addition to all the new decTest files. Note that redx218 in reduce.decTest is identical to nrmx218, except that it specifies that Clamped *should* be raised. For the hash method, I think it's safe to leave the old Python 2.5 __hash__ exactly as it is, but backport everything else. This means that hash will still be slow for large Decimals in Python 2.5 (i.e., we won't be able to backport the fix for issue 1770416 in Python 2.5), but at least it'll be correct. If we backport the new __hash__ without also backporting the corresponding core change to the long __hash__ then we'll be left with a buggy __hash__. The new tests for __hash__ are still valid, and I think they shouldn't be skipped in the backported version. And I definitely don't want to suggest backporting the long.__hash__ change---that just seems to be asking for trouble. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Mark Dickinson added the comment: P.S. I've just noticed that both versions of __hash__ are buggy: the hash value of a Decimal depends on the current context. I'll open a new bug report. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Mark Dickinson added the comment: There's a bug on line 1341 of decimal.py. That line currently reads: otherside = otherside._rescale(exp, context=context) It should read: otherside = otherside._rescale(exp, context=context, watchexp=0) -- nosy: +marketdickinson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Mark Dickinson added the comment: I should have said that the bug I mentioned above is just one of a number of bugs (mostly in division, addition and square root) that have been corrected in the trunk. Some of these fixes should probably be backported. But the decimal module has also had significant new functionality added since Python 2.5, which is going to make sorting out which pieces to backport tricky. Actually, I guess it's possible to argue that the entire new decimal.py module should be backported for inclusion in Python 2.5.2: the new functionality was added to comply with the IBM Decimal Arithmetic specification, and the comments in the decimal module explicitly say that non-compliance with an update specification should be regarded as a bug. So almost all the changes are bugfixes, in some sense... Facundo, what do you think? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Hirokazu Yamamoto added the comment: I tracked down, and I noticed following code was invoked. Lib/decimal.py (release-maint25 Decimal#_rescale) 1912: if watchexp and digits context.prec: 1913: return context._raise_error(InvalidOperation, 'Rescale prec') from decimal import * d = Decimal(23.08589694291355371979265447) print d % Decimal(2.302585092994045640179914546844) # NaN print Decimal(0.060046012973097317993509001560)._rescale(-30) # error Length of decimal seems to be important, so I changed length and it seemed working. print d % Decimal(2.302585092994045640179914547) # 0.060046012973097317993509000 Maybe is this intended behavior? Still I feel 2.6's behavior is less suprising though... __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1182] Paticular decimal mod operation wrongly output NaN.
Changes by Georg Brandl: -- assignee: - facundobatista nosy: +facundobatista __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1182 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
