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