On 6/22/07, Thomas Lord <[EMAIL PROTECTED]> wrote: > Joe Marshall wrote: > > > > On 6/22/07, Thomas Lord <[EMAIL PROTECTED]> wrote: > >> > >> That's wrong. NaN is not an interval. > >> > >> All normal floating point numbers are intervals. > > > > That's wrong (and a common misconception). All normal floating point > > numbers > > are exact rational numbers. While it is true that there are intervals > > on the real > > number line where every real in the interval maps to the same floating > > point number, > > the floating point number itself is just a rational. > > > > > > > That is a misleading way to describe the situation.
I disagree. > Floating point numbers may be interpreted as certain > Rationals, to be sure. (I'm capitalizing set names > when I mean the mathematical sets as opposed to > Scheme's type categories.) > > However, the semantics of those floating point numbers > comes from regarding each of those rationals > as the name for an interval of the Reals. This is incorrect, and again, this is a popular misconception. Interval arithmetic doesn't really work as a model for floating-point. The problem is that intervals have width, and that is not modeled in the floating point representation. The IEEE standard requires that floating point numbers are treated as *exact* numbers. Operations are required to return the *exact* answer if that answer can be represented, and the closest representable answer otherwise. > The rational > number stored in the bits of a floating point number > are the "canonical members" of those intervals. (The > inf intervals are exceptional: they have no characteristic > member and the semantics of floating point math reflects > this.) This, too, is incorrect and a different, but common, misinterpretation. Floating point numbers are not `stand-ins' for numbers within intervals. > When we write floating point numbers like "0.1", we > are essentially writing "There exists a number X in the > interval [0.1-epsilon_a .. 0.1+epsilon_b]" and we go > from there. No. A floating point number like 0.1 is interpreted by the computer as the exact *representable* number closest to 0.1 If the computer uses decimal floats, it is exactly 1/10, if double-precision binary it is *exactly* 3602879701896397/36028797018963968 There is no epsilon anywhere in there. > The "terms" in floating point equations > are all existentially qualified statements like that. The > "operators" in floating point equations reliably draw > certain inferences from one or two of those terms, generating > a new term of the same form (or NaN): "there exists > A near 0.25 and there exists B near 0.5 so there > exists C near 0.75" This is wrong. The floating point operations are defined on exact inputs, in your example, A would be exactly 4503599627370496/18014398509481984, B would be exactly 4503599627370496/9007199254740992 and the answer C would be exactly 6755399441055744/9007199254740992 Note that no rounding takes place at all anywhere in this operation. > The particular inferences an FPU will draw are, in part, defined with > reference to the characteristic dyadic rationals of the > finite intervals in the system -- but the semantics are > really "about" those intervals (the ones implied by those > existentially qualified statements). You can also see that the > semantics are really "about" the intervals, not the rationals > per se, from the treatment of inf or the treatment of rounding. As I mentioned before, the floating-point unit has no notion whatsoever of widths, which is of primary importance in interval arithmetic. The semantics are defined in terms of exact rationals. In fact, the interval model will fail on the edge cases. > The interval view, as opposed to seeing floating points > as Rationals, is also a good way to make sense of figuring > out error terms for results from an FPU under various > conditions and assumptions. I disagree, and I'm in good company. Kahan, for example, explicitly notes that floating point numbers are *not* intervals. -- ~jrm _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
