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

*To*: Common-Lisp@sail.stanford.edu, DCP@quabbin.scrc.symbolics.com, Greenwald@stony-brook.scrc.symbolics.com, Moon@stony-brook.scrc.symbolics.com, gls@think.com*Subject*: Re: Numerical Comparison: "required coercions"*From*: fateman@mike.Berkeley.EDU (Richard Fateman)*Date*: Thu, 26 Mar 87 11:54:28 PST*Cc*: Numerics@stony-brook.scrc.symbolics.com

I think that comparing more than 2 operands could simply be forbidden since the semantics is unclear and the utility is doubtful. I disagree with the statement that "it is misleading to *add* bits of precision during a computation." In fact, unless the language starts by assuming that ALL numbers, floating point numbers or rationals are exact, you are in trouble. (Some languages screw this up, and perhaps this is where the inspiration comes from.) The best model might be to say that changing representations (e.g. float to double conversion) is fine, as long as it doesn't change the value. But rational to float sometimes changes values (sometimes it loses the whole ball of wax when the number over/underflows). This is not good. .... Confusing accuracy with precision is dangerous. No one knows for sure that 1/3 is more accurate than 0.3. In fact, they may both be used as poor approximations to 1/2. .... There is an IEEE "inexact" flag which pertain to operations, not operands. It helps you do things in lower precision than you thought you could, and still get the right answer. More later.,.

**Follow-Ups**:**Re: Numerical Comparison: "required coercions"***From:*Guy Steele <gls@Think.COM>

- Prev by Date:
**Re: Numerical Comparison: "required coercions"** - Next by Date:
**Numerical Comparison: "required coercions"** - Previous by thread:
**Numerical Comparison: "required coercions"** - Next by thread:
**Re: Numerical Comparison: "required coercions"** - Index(es):