Title: Paticular decimal mod operation wrongly output NaN.
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: facundobatista Nosy List: facundobatista, mark.dickinson, ocean-city, rhettinger
Priority: normal Keywords:

Created on 2007-09-20 16:26 by ocean-city, last changed 2008-01-08 23:17 by mark.dickinson. This issue is now closed.

Messages (13)
msg56056 - (view) Author: Hirokazu Yamamoto (ocean-city) * (Python committer) 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) * (Python committer) Date: 2007-09-23 18:47
I tracked down, and I noticed following code was invoked.

Lib/ (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") #

Maybe is this intended behavior? Still I feel 2.6's behavior is less
suprising though...
msg56114 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2007-09-24 14:51
There's a bug on line 1341 of  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) * (Python committer) 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
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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2008-01-08 16:21
Decimal was backported to Py2.5, commited in r59859.
msg59555 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) 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))

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) * (Python committer) Date: 2008-01-08 20:49
Fix it, please.
msg59565 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-08 21:47
hash fixed in revision 59863.
msg59569 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) 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) * (Python committer) 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.
Date User Action Args
2008-01-08 23:17:21mark.dickinsonsetmessages: + msg59573
2008-01-08 22:54:07rhettingersetnosy: + rhettinger
messages: + msg59569
2008-01-08 21:47:50mark.dickinsonsetmessages: + msg59565
2008-01-08 20:49:27facundobatistasetmessages: + msg59556
2008-01-08 20:17:31mark.dickinsonsetmessages: + msg59555
2008-01-08 16:22:33facundobatistasetstatus: open -> closed
resolution: fixed
2008-01-08 16:21:35facundobatistasetmessages: + msg59541
2008-01-07 20:58:32mark.dickinsonsetmessages: + msg59489
2008-01-07 20:52:45mark.dickinsonsetmessages: + msg59488
2008-01-07 15:49:20facundobatistasetmessages: + msg59457
2007-09-24 16:16:23mark.dickinsonsetmessages: + msg56115
2007-09-24 14:51:04mark.dickinsonsetnosy: + mark.dickinson
messages: + msg56114
2007-09-23 18:47:50ocean-citysetmessages: + msg56097
2007-09-20 16:41:20georg.brandlsetassignee: facundobatista
nosy: + facundobatista
2007-09-20 16:26:58ocean-citycreate