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

*To*: info-mcl@ministry.cambridge.apple.com*Subject*: Re: weird math*From*: Steven Ritter <sr0o+@andrew.cmu.edu>*Date*: Thu, 26 Aug 1993 13:27:25 -0400*Distribution*: world*In-reply-to*: <9308252313.AA22085@cambridge.apple.com>*Newsgroups*: comp.lang.lisp.mcl*Organization*: Psychology, Carnegie Mellon, Pittsburgh, PA*References*: <9308252313.AA22085@cambridge.apple.com>

Thanks for the answers. Bill St. Clair and Kim Barrett are right. This has more to do with how comparisons between rationals and floats work than with floating point accuracy (coercing 7/5 to a float yields the same answer as reading 1.4, although neither are really equal to 1.4). I assumed that, in comparing a ratio to a float, the ratio would be converted to a float, and then the comparison would take place. X3J13 decided that the float gets converted to a ratio, and then the comparison takes place. So: ? (rational 1.4) 3152519739159347/2251799813685248 ;;because 1.4 isn't really 1.4 And, of course, the above mess is not equal to 7/5. Now, let me explain why I think X3J13 is wrong. The nice thing about ratios is that they are accurate to arbitrary precision. This means that you can do integer arithmetic, including integer division, with no roundoff error (until, of course, you want to print the final ratio as a float, in which case you almost never want full precision anyway). What X3J13's comparison rule says, in effect, is that LISP believes that the floating point number is more accurate than the ratio. This, of course, will never be true (although, sometimes, they might be equally accurate). As explained on p. 290, X3J13's comparison rule preserves transitivity in cases where you depend on numbers being precise to LISP's limits. In exchange, we lose the ability to compare floats to ratios in any reasonable way. We can no longer hold the belief that ratios are always exact, while floats are always approximate. Now, both are approximate (at least, in some circumstances). I think this is a bad trade. Steve

**References**:**Re: weird math***From:*kab (Kim Barrett)

- Prev by Date:
**ISAM or better for MCL & .DIF file import.** - Next by Date:
**Accessing C floating point data type in MCL** - Previous by thread:
**Re: weird math** - Next by thread:
**Re: weird math** - Index(es):