Should the floating-point constants really be constants?

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Wed, 16 Apr 86 12:51:09 pst
    From: hpfclp!paul@hplabs.ARPA

    Question:  Should the floating point  constants on pgs.  231-232 of CLtL
    really be constants?

    Here is an example.  Take the constant double-float-epsilon.  Suppose it
    is derived on a system in which  doubles are IEEE 64 bit format,  and in
    which the rounding precision is round to double.  Fine.

    Now  suppose we want to use an  MC68881,  and we want to use the default
    rounding  precision  (round to extended)  because it is faster and gives
    "better" results.

    The problem is that  double-float-epsilon,  a constant is now incorrect;
    i.e.  it will not satisfy the criteria on pg 232.  Basically  the reason
    is that when  using  the  extended  precision  mode of the 881, a double
    round error  takes  place  (rounding  the  extended  precison  result to
    extended  precision  and  then  rounding  that  to  a  double).  In  the
    software, however, only one rounding takes place.

Doesn't this only show that this particular method of implementing floating
point has a bug in it?  You can either live with the bug or not use this
method of implementing floating point, whichever you judge is best.

    Hence,  any  code  compiled  on a system  in which  the  floating  point
    constants  are  folded  in-line  will fail on 881  systems  because  the
    constants no longer satisfy whatever their criteria was.

    This problem  could  manifest  itself in other  instances - for example,
    optional floating point  accelerators in which the numeric format and/or
    range is different from the host system's.  How will that be handled?

This I think is a different issue, and a more interesting one.  Let me
rephrase what I think you are saying: Suppose I have two Lisp systems that are
so close to each other that compiled code from one can be loaded into the
other.  The only difference between them is that they use different
floating-point formats.  Should the Common Lisp language be changed to allow
me to call these two Lisp systems one Lisp system that from time to time
changes its floating-point format, by changing these constants to variables?

My reaction is that I'm uncomfortable with changing the definition of the
language to provide such a specialized feature (compiled code portability
between two similar implementations).  Perhaps there is another solution that
doesn't involve changing the language.  One obvious candidate is this: if you
have two different floating-point formats, don't call them by the same name.
Perhaps you can call one of them double and the other one long.  If the total
number of formats is more than four, introduce some more floating-point types
(the manual pp.33-5 appears to allow this.)