[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Should the floating-point constants really be constants?
- To: common-lisp@SU-AI.ARPA
- Subject: Should the floating-point constants really be constants?
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Fri, 18 Apr 86 17:30 EST
- In-reply-to: The message of 16 Apr 86 15:51 EST from hpfclp!paul@hplabs.ARPA
Date: Wed, 16 Apr 86 12:51:09 pst
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
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.)