On 6/22/07, Thomas Lord <lord at emf.net> wrote:
> Joe Marshall wrote:
> >
> > On 6/22/07, Thomas Lord <lord at emf.net> 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
Received on Fri Jun 22 2007 - 19:22:23 UTC