code not true?

Kragen Sitaker kragen at dnaco.net
Sat Apr 22 23:07:53 EDT 2000


In article <slrn8g45lj.oa.daniels at localhost.localdomain>,
Alan Daniels <daniels at mindspring.com> wrote:
>On Sat, 22 Apr 2000 14:02:21 GMT, Mark Hammond
><mhammond at skippinet.com.au> wrote:
>
>[snip...]
>>Of all the solutions to this problem, this does strike me as one of
>>the best - simply remove equality testing al together for floating
>>point.
>
>Are you sure of this? It would be awful confusing for a programming
>newbie to do:
>
>x = 5.0
>y = 5.0 # Later on down in the code.
>x == y  # And even further...
>
>And get an exception thrown. All the "why doesn't this work?" messages
>we've seen about floating point have to do with doing manipulation of
>the numbers and *then* having them not work.
>
>For 0.07 * 100 to not be the same as 7.0 is understandable, because
>that's just how floating point works on CPUs today: Not all numbers
>are representable in IEEE format. But to outlaw asking if 7.0 is equal
>to 7.0 definitely goes against the principle of least suprise. And
>learning that floating-point math sometimes leads to slight numerical
>errors is an important lesson that newbie programmers shouldn't be
>shielded from.

Almost the only time I care whether two floating-point numbers are
exactly equal is when one of them is exactly zero.  But if I'm throwing
around floor() and ceil(), I might well want to know whether one of
them is exactly an integer.

The Perl way to handle this would be to have an enableable flag that
prints a warning when two numbers that are almost, but not quite equal,
are compared for equality.
-- 
<kragen at pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)



More information about the Python-list mailing list