(abs ) crash with NaN
Posted: Fri Dec 12, 2003 12:18 am
Giving newlisp 7.3.17
(abs (sqrt -1))
crashes newlisp -
so does
> (setq isnan (sqrt -1))
+NAN
> (NaN? isnan)
true
> (abs isnan)
I note in nl-math.c some code protects DIVIDE from Nan viz
#ifdef __BORLANDC__
if(isnan(number))
{
result = number;
break;
}
#endif
if(number == 0.0)
return(errorProc(ERR_MATH));
result /= number;
break;
but not other functions
so (min (sqrt -1) 2) also "crashes".
I suspect it may relate to uncaught signals or exceptions from the math processor along the lines of the thread "math exception handling" http://www.alh.net/newlisp/phpbb/viewtopic.php?t=102
I've not tested all functions as to susceptibility to NaN problems - you
can probably see from the code which ones are at risk. In leu of catching
the signals etc perhaps more checking for NaN along the lines above used for divide is needed for robustness.
Nigel
(abs (sqrt -1))
crashes newlisp -
so does
> (setq isnan (sqrt -1))
+NAN
> (NaN? isnan)
true
> (abs isnan)
I note in nl-math.c some code protects DIVIDE from Nan viz
#ifdef __BORLANDC__
if(isnan(number))
{
result = number;
break;
}
#endif
if(number == 0.0)
return(errorProc(ERR_MATH));
result /= number;
break;
but not other functions
so (min (sqrt -1) 2) also "crashes".
I suspect it may relate to uncaught signals or exceptions from the math processor along the lines of the thread "math exception handling" http://www.alh.net/newlisp/phpbb/viewtopic.php?t=102
I've not tested all functions as to susceptibility to NaN problems - you
can probably see from the code which ones are at risk. In leu of catching
the signals etc perhaps more checking for NaN along the lines above used for divide is needed for robustness.
Nigel