[Python-bugs-list] [ python-Bugs-513866 ] Float/long comparison anomaly
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 06 Feb 2002 20:52:28 -0800
Bugs item #513866, was opened at 2002-02-06 10:33
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513866&group_id=5470
Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Koenig (arkoenig)
Assigned to: Tim Peters (tim_one)
Summary: Float/long comparison anomaly
Initial Comment:
Comparing a float and a long appears to convert the
long to float and then compare the two floats. This
strategy is a problem because the conversion might
lose precision. As a result, == is not an equivalence
relation and < is not an order relation. For example,
it is possible to create three numbers a, b, and c
such that a==b, b==c, and a!=c.
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2002-02-06 20:52
Message:
Logged In: YES
user_id=31435
Since the coercion to float is documented and intended,
it's not "a bug" (it's functioning as designed), although
you may wish to argue for a different design, in which case
making an incompatible change would first require a PEP and
community debate. Information loss in operations involving
floats comes with the territory, and I don't see a reason
to single this particular case out as especially
surprising. OTOH, I expect it would be especially
surprising to a majority of users if the implicit coercion
in
somefloat == somelong
could lead to a different result than the explicit coercion
in
long(somefloat) == somelong
Note that the "long" type isn't unique here: the same is
true of mixing Python ints with Python floats on boxes
where C longs have more bits of precision than C doubles
(e.g., Linux for IA64, and Crays).
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513866&group_id=5470