Robert Dodier wrote:
> Probably if you stick to a single implementation and avoid
> funny stuff like inf and nan, you won't run into problems.

Hm, inf and nan can be pretty important for certain LAPACK functions.
If the hardware supports fast arithmetic with infs and nans, it helps
them a lot, but some processors trap on infs and nans which makes the
code really slow. Sometimes the LAPACK developers resort to writing
two different versions of the code -- one for misbehaving machines and
one for good machines. I'm not an expert with that stuff but I suspect
that it relates to eigenvalues and generalized eigenvalues -- I can
poke around and ask LAPACK developers at Berkeley if you like.

I can always catch Lisp-signaled floating-point exceptions for cases
like trying to invert a singular matrix. The exceptions aren't as
helpful as if they were thrown by straight Lisp code, because you
probably won't be able to examine the Fortran source, and even if you
could, LAPACK code is very hard to read for the uninitiated. (Or worse
yet, some auto-tuned assembly language xTRMM divides by zero... -- if
the Lisp _doesn't_ signal an exception, I'll have to scan the output
for NaNs / Infs.)

At least Lisp doesn't make the mistake of APL by saying 0.0/0.0 == 1 ;p

> > (I don't think Franz is keen on fixing that stuff because their
> > customers are enterprise / DB types -- scientists would tend to use the
> > open-source Lisps if they use Lisp at all. Just my guess though.)
>
> I have it on good authority (Fateman) that Allegro's behavior wrt
> floating point numerics is motivated by a close reading of the CL spec.

I stand corrected (I should have taken the time to ask Prof.
Fateman last semester when he talked about floating-point in his
computer algebra lectures...)

Many thanks,
mfh