floating point special values, was: error - system too complex

--- Raymond Toy  wrote:

> Robert Dodier wrote:
> [snip]
> >>By default, in CMUCL, things that would produce NaN or infinity
> >>signal errors. But you can change that so it does return NaN or 
> >>infinity.
> > 
> > Excellent. Maxima should set the appropriate flags to 
> > return NaN and infinity. 
> 
> If there were a vote, I would oppose making this the default.  All
> the times I've generated NaN or infinity have always been because
> of errors in my code, so I'd like to catch the error as soon as 
> possible.
> 
> Sometimes even silent underflow to zero is a problem too.
> 
> Exposing some standard interface to this functionality would be good
> for those who know what they're doing and need it, though.

OK, it looks like this discussion is largely hypothetical, 
since neither Clisp nor GCL, so far as I can tell after
perusing their documentation, has any mechanism for disabling
floating point exceptions.

I might try playing with CMUCL's floating point stuff
to see how comfortable Maxima is with nan and infinity.

> > If Maxima could just step aside and let the cpu figure
> > out the result, that would be an improvement.
> > This applies to floating point comparisons as well
> > as arithmetic results.
> 
> I disagree, obviously. :-)  However, once the user has decided to 
> disable all the FP signals, maxima should handle NaN and infinity 
> gracefully, somehow.
> 
> Comparisons, however, are tricky.  If x is Nan, x == x and x != x are
> both false.  (I think.)  This can cause unexpected behavior, if the
> user forgot about NaN.

Actually nan = nan => false, and nan != nan => true.

I used to do stuff like this a lot (in Octave):

  mean (x (x == x))

where x is a data vector with missing values represented by nan.

For what it's worth,
Robert Dodier

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com