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

- Prev by Date:
**Re: block/tagbody and catch/throw** - Next by Date:
**[no subject]** - Previous by thread:
**Re: block/tagbody and catch/throw** - Next by thread:
**[no subject]** - Index(es):