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

*To*: common-lisp@su-ai.arpa*Subject*: IEEE float co-processors*From*: fateman@dali.berkeley.edu (Richard Fateman)*Date*: Mon, 27 Jan 86 23:08:19 PST*Cc*: fateman@dali.berkeley.edu

in CLtL p193-194 it is stated that an operation combining a short float with a long results in a long. Presumably if you combine a short + a single you get a single. But how precise is the intermediate arithmetic? Is it OK to do the arithmetic in "long", or MUST you do the arithmetic no more precisely and with no larger range than "single"? Consider any of a number of existing and proposed co-processors in which all arithmetic is in fact done in, say, 80 bit units. A single * short * short then stored to a single would be done by converting each argument to a long, multiplying and rounding to single. This is faster than any other method using most such chips. Unfortunately, it might get an answer better than that prescribed by following CLtL strictly. Using the method on p 194, one can come up with problems where intermediate arithmetic done in single might overflow, underflow, or lose precision disasterously, (or all of these) before the final, exactly-single-representable answer is computed. I believe the standard should allow the processor to perform all floating point arithmetic computations in highest precision, and not require multiple conversions (from short to single to double to long). The paragraph which allows rearrangement or conversion to the longest format IN THE EXPRESSION is not flexible enough to quite allow this.

**Follow-Ups**:**IEEE float co-processors***From:*David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>

- Prev by Date:
**:capitalize in *print-case*** - Next by Date:
**Spelling correction** - Previous by thread:
**:capitalize in *print-case*** - Next by thread:
**IEEE float co-processors** - Index(es):