Incorrect Floating Point comparisons with NaN

The Wikipedia article on NaN states:

n# = Sqr(-1)
Print n
If n = 0 Then Print "oops"
If Not(n <> n) Then Print "oops"

I find this useful!

Please explain how you find this incorrect behaviour useful and I will explain how to find the correct behaviour useful.

n# = Sqr(-1)
Print n
If n = 0 Then Print "oops"
If n = n+1 Then Print "YAY"

EDIT:<offtopic>That's an ambiguous test because n=n+1 also returns true for positive and negative infinity and very large (+ or -) values of n.</offtopic>

If Blitz3D's floating point support was correct, you could still test for NaN - and with the standard test of n<>n as described by my Wikipedia quote above.

If n# = 1.0/ZERO print "n = infinity"
If n# = -1.0/ZERO print "n = -infinity"
If n# = sqr(-1) print "n = NaN"

Have to use a zero variable because Blitz will stop you if you just try to divide by 0. You can't use a constant because it will detect that as well.

You may put NaN in a constant though.

EDIT: sswift's NaN test is broken and will return true for any value of n#.

Yes, it is possible to test for NaN, Infinity, and -Infinity (albiet you'll need better tests than sswift's if you want to distinguish between them) with Blitz's current (incorrect) implementation of floats. It would also be possible to test for these special values with a correct implementation!

Let's keep this on topic please. The issue at hand is whether or not Blitz's NaN handling is correct and whether or not that constitutes a bug.

And what if the "correct behavior" degrades the peformance of every floating point comparison in your program?

I don't see any C programmers complaining that their language is inefficient.

Yeah but this is Blitz3D and not a 30 years high optimized C compiler :-)

My point was that if the most famously efficient programming language in the world can afford to get floats right mandatorily without annoying the nerdiest of the optimizing hacker nerds, it's probably not much (if any) of a performance hit to do it properly. I suspect this was a mistake as opposed to a design decision.

yeah, not a big deal. they return true nomatter what. I guess it won't be that hard to make them return flase nomatter what, when compared with valid numbers. I think that's the standard and it will also prevent problems in code. Not an urgent one IMHO.