[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp@SU-AI.ARPA
- 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.
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.
What to do? I see 2 viable solutions:
1). Put the 881 in the same rounding precision as the software.
2). Make the floating point constants variables. This has some
precedence; look at float-base, float-digits, and float-precision.
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?
Ft. Collins, Colorado