RE: [Gcl-devel] Re: [Maxima] float to bfloat

[Stavros Macrakis]

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

Existing Lisp code may expect 1/0 and 1/0.0 to give errors, not to
silently return values.  It may explicitly catch those errors to do the
right thing, or it may allow them to be propagated, signalling that its
result is not valid.  Current code also silently returns float-infinity
for (expt 9.9 9999), though 9.9e9999 gives a floating overflow error.

I don't think it's necessary to have constants NaN, Inf, etc.  User code
can easily enough define such constants, e.g.

  (defconstant double-floating-infinity (expt 9.9d0 9999))
  (defconstant double-floating-nan (sin double-floating-infinity))

After all, Common Lisp doesn't have standard constants for pi, sqrt(2),
etc., does it?  I am not sure what you mean by 'rules regarding
expressions' -- the machine's IEEE float implementation takes care of
all that.  With the above definitions, you have:

  (= DFnan DFnan) => nil
  (> Dfinf 0) => t
  (/ 1 inf) => 0.0

though you also have

  (/ 1.0 0.0) => Zero divisor error

which I don't think you can turn off in GCL 2.5.0.

To fully integrate NaN/Inf/... into GCL, it would be nice to have
standard input/output formats and make sure that all floating primitives
do something useful with them.  I believe that integer-encode-float
works with NaN/Inf, giving an unambiguous return value.  Constructing a
NaN cannot of course be done in the usual way of constructing a float,
namely (* sign mantissa (expt 2.0 exponent)).