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

*To*: common-lisp@su-ai.arpa*Subject*: comparisons between floats and ratios*From*: fateman@dali.berkeley.edu (Richard Fateman)*Date*: Fri, 24 Jan 86 12:25:47 PST

There is a rule (top of p 194, CLtL) indicating that CL preserves "as much accuracy as possible" (although not guaranteeing it). Thus when two numeric values are operated upon, the coercion is to the larger precision, which tends to preserve more accuracy. To be consistent with this rule, operations which combine floats of any precision with ratios should convert floats to ratios, not the reverse. Any float (except possibly IEEE NaN and infinity) can be converted to a ratio without loss of precision. (and Nan=0/0, inf = 1/0 might even be used). Of course the rational answer could be re-floated if required. This would solve the problem of incorrect equality of 0.0 with a non-zero but small ratio which "underflows". Now consider comparing the floating point number 0.5 with an integer sufficiently large as to overflow the exponent range of floats. The comparison is "an error", according to CLtL (p 194). If one is to ensure correct handling of the large number of numeric data types in the language specification, I think the comparison should return the mathematically correct answer. (Alternatively, one could consider re-building all built-in functions for applications like Macsyma.)

**Follow-Ups**:**comparisons between floats and ratios***From:*Robert A. Cassels <Cassels@TENEX.SCRC.Symbolics.COM>

- Prev by Date:
**common-lisp loop** - Next by Date:
**comparisons between floats and ratios** - Previous by thread:
**common-lisp loop** - Next by thread:
**comparisons between floats and ratios** - Index(es):