Incorrect Floating Point comparisons with NaN

Archives Forums/Blitz3D Bug Reports/Incorrect Floating Point comparisons with NaN

octothorpe

(Posted 2006) [#1]

A NaN does not compare equal to any floating-point number or NaN, even if the latter has an identical representation. One can therefore test whether a variable has a NaN value by comparing it to itself (i.e. if x != x then x is NaN).

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

Damien Sturdy

(Posted 2006) [#2]

I find this useful!

octothorpe

(Posted 2006) [#3]

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

Beaker

(Posted 2006) [#4]

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

octothorpe

(Posted 2006) [#5]

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.

sswift

(Posted 2006) [#6]

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.

octothorpe

(Posted 2006) [#7]

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.

skidracer

(Posted 2006) [#8]

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

octothorpe

(Posted 2006) [#9]

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

Dreamora

(Posted 2006) [#10]

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

octothorpe

(Posted 2006) [#11]

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.

jfk EO-11110

(Posted 2006) [#12]

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.