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 nlmath.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 ) crash with NaN

 Posts: 429
 Joined: Tue Nov 11, 2003 2:11 am
 Location: Brisbane, Australia
this problem exists on Win32 but is fine on Linux/BSD where floating point functions on NaN return NaN.
In the upcoming 7.4.0 rc1 the Win32 version will behave the same way: All floating point operations on NaN return NaN. This is BTW also the same way Java is doing this. They have been very careful to offer a standard 'math' behaviour across platforms. The manual will also be changed accordingly.
NaN in an 'integer' context will still be treated like 0.
(+ 1 (sqrt 1)) => 0
(add 1 (sqrt 1)) => NaN
Lutz
In the upcoming 7.4.0 rc1 the Win32 version will behave the same way: All floating point operations on NaN return NaN. This is BTW also the same way Java is doing this. They have been very careful to offer a standard 'math' behaviour across platforms. The manual will also be changed accordingly.
NaN in an 'integer' context will still be treated like 0.
(+ 1 (sqrt 1)) => 0
(add 1 (sqrt 1)) => NaN
Lutz

 Posts: 429
 Joined: Tue Nov 11, 2003 2:11 am
 Location: Brisbane, Australia