Dave,
you are perfectly right, and in my original TestCase i used such a carefully crafted epsilon based on matrix dimensions and Float precision.
And the test (norm < epsilon) did also fail...

What you see here is the result of my peregrinations in isolating and tracking the bug.
And since i force the value to 0.0 which has an exact representation in IEEE floating point, there is no problem using equal, this is one of the rare cases where this construct is licit. Beside, if i retry the expression while in the debugger, it does never fail.

If  you load my testcase, you can replace the test = 0.0 with < 1.0e-5, ~= 1 or whatever, i guess it will still fail on the seventh call (sorry, no unix image under my hands to assert what i say).

Nicolas


Dave Hylands:
> Hi Nicolas,
> 
> > And on the seventh call, i always get a stange result (result is 0.0 but will
> > answer false to = 0.0).
> 
> I don't know a whole lot about FFI, but I know that generally accepted
> practice (at least in C which is the language I'm most familiar with)
> is that you NEVER test for equality when using floating point numbers.
> 
> You always use some small epsilon and test that the number you've got
> is within epsilon of the comparison number.
> 
> This is because due to roundoff and other such effects, you can wind
> up with really tiny numbers, like 1 x 10^-53 which is essentially
> zero, but is not equal to zero.
> 
> This might not even be relevant to your discussion, but seeing the
> equality test on 0.0 raised a red flag for me.
> 
> -- 
> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/
> 


________________________________________________________________________
iFRANCE, exprimez-vous !
http://web.ifrance.com