[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
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

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)


(= infinity-single infinity-single)


(= infinity-single infinity-double)


(> infinity-single infinity-double)


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

I've written a paper somewhere about extending rationals

 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]