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.
Baz
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
