B.Rowlingson at lancaster.ac.uk
Mon Jul 14 12:45:56 CEST 2003
> It is correct, just an instability of the representation of that
> floating point number, because (regularly) floating point numbers cannot
> be represented exactly.
A python developer friend of mine tells me there was a proposal for
python that two floating-point numbers should _never_ return TRUE for
'=='. Even if their binary representations are the same. I can see the
merit in this, as long as its documented.
I'm tempted to think that any argument for float == float always
returning false is almost like saying float == float is an invalid
operation, and hence should be flagged as that at compile/interp time.
Probably easier to do in a strongly-typed language.
Of course the main problem is that us 'old-timers' who grew up
deciding whether to use REAL*4 or REAL*8 understand what is going on
'under the hood' with floating point numbers, but today's computers are
being used by mathematicians and statisticians whose perception of
numbers comes from a different direction to computer people. "0.7 + 0.1
does not equal 0.8? Does 1+1 not equal 2? That's madness!", they cry.
The solution is education: I'm hoping to teach all our postgraduates a
short course on computer history and culture, from binary numbers up to
software engineering, hardware, programming languages etc etc. Floating
point formats are in there somewhere, for sure.
More information about the R-help