#113 nltk changes behaviour of Decimal class

[Anonymous]

Observed using Python 2.5.1 on Mac OS X and NLTK 0.9.4:

<code>
>>> from decimal import Decimal
>>> Decimal('0.1') > 0.3
False
>>> import nltk
>>> Decimal('0.1') > 0.3
True
</code>

Something about the Decimal class's comparison operators is very weird anyway, but nltk changing this behaviour is even more strange...

Regards
Martin Kleppmann
<nltk@kleppmann.de>

[Edward Loper]

Logged In: YES
user_id=195958
Originator: NO

Apparently, you're only allowed to use comparison operators to compare Decimal objects to (i) other Decimal objects; (ii) integers; (iii) longs. Here, you're comparing it to a float, which isn't allowed, as evidenced by the following:

>>> Decimal('.1').__cmp__(1)
-1
>>> Decimal('.1').__cmp__(.3)
NotImplemented

Since Decimal's __cmp__ method returns NotImplemented, python falls back on using .3's __cmp__ method. Unfortunately, when you compare a float to some random object, the results are pretty much arbitrary, and are not guaranteed to be consistent.

The idea here is that ".3" is an imprecise number -- in fact, the number that prints as ".3" is actually stored by the computer as a slightly different number:

>>> repr(.3)
'0.29999999999999999'

So Decimal won't let you mix floats & Decimal objects. Unfortunately, you don't get a nice error message; instead, you just get an arbitrary result.

But nltk's not really playing much of a role here (other than tweaking the system to change that arbitrary result -- my guess would be that the result depends on the pointer address of the Decimal class, or of some other object like that).