[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: [Maxima] float to bfloat
From: |
Richard Fateman |
Subject: |
Re: [Gcl-devel] Re: [Maxima] float to bfloat |
Date: |
Mon, 26 Jan 2004 21:44:55 -0800 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
Steve Haflich wrote:
From: Camm Maguire <address@hidden>
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
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, (continued)
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Raymond Toy, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Richard Fateman, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Raymond Toy, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Camm Maguire, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Steve Haflich, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Raymond Toy, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Steve Haflich, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Camm Maguire, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Richard Fateman, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Steve Haflich, 2004/01/26
- Re: [Gcl-devel] Re: [Maxima] float to bfloat,
Richard Fateman <=
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Richard Fateman, 2004/01/27
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Raymond Toy, 2004/01/27
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Camm Maguire, 2004/01/30
- Re: [Gcl-devel] Re: [Maxima] float to bfloat, Raymond Toy, 2004/01/30
- [Gcl-devel] RE: [Maxima] float to bfloat, Stavros Macrakis, 2004/01/23