[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*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 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.)

- Prev by Date:
**(PROCLAIM '(IGNORE ...))** - Next by Date:
**We are entering a new stage....** - Previous by thread:
**Type Specifier: (OR (FUNCTION ...) ...)** - Next by thread:
**We are entering a new stage....** - Index(es):