| msg56056 - (view) |
Author: Hirokazu Yamamoto (ocean-city) *  |
Date: 2007-09-20 16:26 |
| Following code illegally print "NaN" on Python2.5. from decimal import * d1 = Decimal("23.08589694291355371979265447") d2 = Decimal("2.302585092994045640179914546844") print d1 % d2 Python2.6(trunk) print 0.06004601297309731799350900156 |
|
|
| msg56097 - (view) |
Author: Hirokazu Yamamoto (ocean-city) * |
Date: 2007-09-23 18:47 |
| 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... |
|
|
| msg56114 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2007-09-24 14:51 |
| 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) |
|
|
| msg56115 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2007-09-24 16:16 |
| 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? |
|
|
| msg59457 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2008-01-07 15:49 |
| 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! |
|
|
| msg59488 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-01-07 20:52 |
| 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. |
|
|
| msg59489 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-01-07 20:58 |
| 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. |
|
|
| msg59541 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2008-01-08 16:21 |
| Decimal was backported to Py2.5, commited in r59859. |
|
|
| msg59555 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-01-08 20:17 |
| 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. |
|
|
| msg59556 - (view) |
Author: Facundo Batista (facundobatista) * |
Date: 2008-01-08 20:49 |
| Fix it, please. |
|
|
| msg59565 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-01-08 21:47 |
| hash fixed in revision 59863. |
|
|
| msg59569 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2008-01-08 22:54 |
| 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. |
|
|
| msg59573 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-01-08 23:17 |
| 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. |
|
|