[no subject]

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

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?

Comments?

Paul Beiser
Hewlett-Packard   
Ft. Collins, Colorado
uucp:   ...{ihnp4!hpfcla,hplabs}!hpfclp!paul
arpa:    paul%hpfclp@hplabs