My icc (7.1) bugs in comparison of NaN. But Pike has it's own support of NaN, doesn't it?
Is there any simple way of turning on that support, so I can write a configure test to turn off using a native NaN if it doesn't work?
Pike does not have its own implementations of the basic floating point operations (addition, multiplication, comparison, etc), so the C environment must provide such implementations with correct handling of NaN. For comparison, Pike can use the functions isless() instead of < if it exists. For equality, there actually seems to be some extra code that looks for NaN, but it looks broken:
case T_FLOAT: if (PIKE_ISNAN(a->u.float_number) != PIKE_ISNAN(b->u.float_number)) { return 0; } return a->u.float_number == b->u.float_number;
That should be ||, not !=. An even better solution would be to use isunordered() if it exists. I'll update the code.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-01-12 12:48: Subject: icc & nan
My icc (7.1) bugs in comparison of NaN. But Pike has it's own support of NaN, doesn't it?
Is there any simple way of turning on that support, so I can write a configure test to turn off using a native NaN if it doesn't work?
/ Mirar
Ah. So there isn't any object representation of NaN lurking around somewhere, or something like that?
Hm, that code snippet ought only to be used if the C implementation is buggy...
/ Mirar
Previous text:
2004-01-12 13:13: Subject: icc & nan
Pike does not have its own implementations of the basic floating point operations (addition, multiplication, comparison, etc), so the C environment must provide such implementations with correct handling of NaN. For comparison, Pike can use the functions isless() instead of < if it exists. For equality, there actually seems to be some extra code that looks for NaN, but it looks broken:
case T_FLOAT: if (PIKE_ISNAN(a->u.float_number) != PIKE_ISNAN(b->u.float_number)) { return 0; } return a->u.float_number == b->u.float_number;
That should be ||, not !=. An even better solution would be to use isunordered() if it exists. I'll update the code.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Nope.
Ideally, yes. Although I suspect it wouldn't have much impact on performance when push comes to shove.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-01-12 13:22: Subject: icc & nan
Ah. So there isn't any object representation of NaN lurking around somewhere, or something like that?
Hm, that code snippet ought only to be used if the C implementation is buggy...
/ Mirar
It seems rather tricky to construct NaN on a general basis for such a configure test though...
/ Mirar
Previous text:
2004-01-12 13:28: Subject: icc & nan
Nope.
Ideally, yes. Although I suspect it wouldn't have much impact on performance when push comes to shove.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Mirar ＠ Pike developers forum