New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Paticular decimal mod operation wrongly output NaN. #45523
Comments
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 |
I tracked down, and I noticed following code was invoked. Lib/decimal.py (release-maint25 Decimal#_rescale) 1912: if watchexp and digits > context.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 print d % Decimal("2.302585092994045640179914547") # Maybe is this intended behavior? Still I feel 2.6's behavior is less |
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) |
I should have said that the bug I mentioned above is just one of a Actually, I guess it's possible to argue that the entire new decimal.py Facundo, what do you think? |
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.
Mark, could you please take a look at it? Thank you! |
You need to remove the old files in decimaltestdata before copying the Note that redx218 in reduce.decTest is identical to nrmx218, except that For the hash method, I think it's safe to leave the old Python 2.5 And I definitely don't want to suggest backporting the long.__hash__ |
P.S. I've just noticed that both versions of __hash__ are buggy: the |
Decimal was backported to Py2.5, commited in r59859. |
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- I can fix this (it's a 1-line change), and reinstate the extra hash tests, if you like. Or I can |
Fix it, please. |
hash fixed in revision 59863. |
If this something missing from Colishaw's test suite, you should submit |
I don't think anything's missing from Cowlishaw's test-suite. An old, |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: