[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: checking for Not a Number?
- From: "Joe Smith" <unknown_kev_cat@...>
- Date: Fri, 29 Dec 2006 18:10:42 -0500
"Glenn Maynard" <email@example.com> wrote in message
Correct. I'm quite confident the documentation was intending to explain the
other case, which seems highly illogical
to those unfamiar with it, including developers who mainly work on other
On Thu, Dec 28, 2006 at 08:05:53PM -0500, Joe Smith wrote:
No. What they are warning is that
may fail, even for !isnan(y)
Lets say y is a 10-byte extended precision double in the FPU.
For some reason, the compiler decides that 'x' should be storred in
So x is set to a 8-byte representation of y, created by truncation. The
extra 2 bytes of precision means that
x and y do not compare equally.
We all know the issues with the x86 high-resolution FPU registers;
we don't need an introduction. :) That's not what it says, though:
For example, you can find that a floating point value which is not a
NaN is not equal to itself.
This is saying that assert(x==x) may fail for non-NaN, and seems to be
specifically saying that the "x!=x" test for NaN-ness may not always
work. As far as I know, this is simply incorrect, and this documentation
I'm still not sure that this code is correct:
else if (ttisnumber(key) && nvalue(key) != nvalue(key))
luaG_runerror(L, "table index is NaN");
If nvalue(key) was stored in a varible, which was compaired to itself, then
I would agree that it
would be required to do the right thing.