Steve Haflich wrote:
> From: Camm Maguire <camm at enhanced>
>
> My understanding is that the Common Lisp spec is silent on an
> implementation's treatment of Nan and Inf. If so, and we are
> implicitly free to implement them in a useful way, I'd be happy to do
> so for maxima's benefit. Paul, can we define NaN, and Inf as symbols
> with floating point constant values, and 1/0, -1/0, and 0/0 as
> analogous rationals? What would be useful rules regarding expressions
> involving these symbols, beyond NaN - NaN = NaN et. al. mentioned
> above?
>
>The above may make sense to mathematicians in the context of Macsyma
>but as a Common Lisp implementor I don't believe it is compatible with
>the other real-world constraints on Common Lisp. Mathematically
>consistent treatment of the IEEE exceptional fp values (the Infinities
>and NaNs) in both their generation and detection is hard to reconcile
>with achieving raw platform fp speed.
>
I suspect just the opposite is happening.
The way to make floats run at raw platform speed is to let the hardware
do what it
is supposed to do. Lisp doesn't do this, and consequently is SLOWER.
That is, Lisp
checks before dividing to see if it is dividing by zero. (etc.). The
right way is to catch the exception.
Now there may be other problems, like mixed number types at run time,
but if there is a coercion to NaN or Inf, then the hardware should do
the right thing.
In fact, mathematicians should despair of using the IEEE not-a-numbers
and infs, since
they are not proper members of any sensible algebraic structure (not a
field, certainly).
Rules for such things as cos(NaN) are available in W Kahan's papers on
line at
www.cs.berkeley.edu/~wkahan
This does NOT mean that there is a smooth transition from NaN to
bigfloat or symbols.
>What should be the result of these?
>
> (- infinity-single infinity-single)
>
NaN
>
> (= infinity-single infinity-single)
>
nil
>
> (= infinity-single infinity-double)
>
nil
>
> (> infinity-single infinity-double)
>
nil
>
>
>Re the proposed 1/0 value, do you intend a computational 3/0 to
>normalize to 1/0?
>
Yes. Assuming there is an effort to remove the GCD from numerator and
denominator,
you would get this without even noticing the denominator was 0. You
will need, however,
to be sure to preserve the sign of -1/0, if you decide you want signed
infinity. You may
not, which brings in a few sticky points, since the IEEE system
definitely has signed
infinity. It also has signed zero, which we don't have in CL either...
the signed infinities
really are 1/(signed zeroes)... On the other hand, we allow for limits
to +, -, or complex
infinity.
I've written a paper somewhere about extending rationals
http://www.cs.berkeley.edu/~fateman/papers/extrat.ps
......
> And what about contagion, and especially
>comparisons across types?:
>
> (- infinity-single 1/0)
>
presumably CL will convert to float and do IEEE arithmetic, but if you
wanted to do
this by conversion to rational, then you have (- 1/0 1/0) which comes
out 0/0, the rational
version of NaN, which is correct.
>
> (/ infinity-single 1/0) similarly is (* 0/1 1/0) or NaN
> (= infinity-single 1/0) whatever IEEE says about inf=? inf. probably nil.
>
The one you are trying to come up with is (/ 1 infinity-single )
which is 0.
>
>
>I suppose nearly all serious platforms pretty much support IEEE these
>days, and FPUs have lotsa neat status bits to get the behavior the
>imlpementation wants, but experience moer than a decade ago showed it
>is hard to guarantee that mad-prion routines here and there don't mess
>with these bits and forget to restore them.
>
Lisp systems could provide access to the hardware instead of being the
prion propagator.
Occasionally I have tried to use the underlying hardware and could get
access to it by
using full optimization on arithmetic expressions. Allowing the lisp to
do any error checking
generally means that your result will be wrong on all hardware. There
are good C and Fortran
routines that are careful about bits.
RJF