[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Numbers
Date: Tue, 22 Aug 89 14:40 PDT
From: bawden.pa@xerox.com
...
Inexact numbers do not necessarily contain a representation of the
precision with which a quantity is known. In the common case where
floating point is used, they most definitely do not. (In the rare case
where interval arithmetic is used, the bounds are known.) Thus in a
floating point implementation of inexact numbers, you cannot represent the
concepts of "within a few microns of 1000 feet" or "within four inches of
three feet". The best you can do is "perhaps 1000 feet" and "about four
feet". The MAX of these two is "perhaps 1000 feet" -- any arguments about
the precision ("within a few microns of 1000 feet" vs. "within four inches
of 1000 feet") are in the province of a numerical analyst to reason about.
Okay, I'll grant that. But I inserted "within a few microns" one for the
sake of lending plausibility to my physical metaphor--possibly a rhetorical
mistake. My code example clearly involves "exactly 1000 feet".
What I was -actually- claiming was that the MAX of "exactly 1000 feet" and
"about four feet" is "perhaps 1000 feet". (In an implementation that used
interval arithmetic, I could indeed compute the MAX of "exactly 1000 feet"
and "within four inches of three feet" and get "exactly 1000 feet", but in
-general-, inexact arithmetic does not have this ability.)
I agree that in *some* cases the best you can do is return an inexact
representation of one's best guess. But sometimes you can tell for sure
that the answer is exact, even if some of the inputs were inexact.
Perhaps a numerical analyst can look at my program and tell me that for
sure. Perhaps if I am using interval arithmetic my implementation can tell
me that for sure. But if I am using floating point, my implementation can
-never- know that for sure.
Here is where the cart may be before the horse. I'll let you inspect the
*types* of the arguments up front in any case. Are you then deciding a
priori to use floating-point to represent the result only on the basis of
the argument types, without regard to the values involved? Or do you
entertain the possibility that the type (or representation) of the result
may depend on the specific values of the arguments? I am arguing for the
latter.
In other words, I deny that the inexactness contagion used for + and * is
appropriate for MAX and MIN. Why is 549755813888.0 the closest we can
come? Only because we have made an arbitrary decision to cast the result
into a representation that reflects the inexactness of the least exact
input, regardless of whether that amount of inexactness in fact had
anything to do with the result computed.
It was not an "arbitrary decision" at all. 549755813888.0 is closest
because we only have 23-bit floating point to represent inexact numbers,
and the answer must be inexact. Its the best we can do. If we return an
exact number we are potentially returning an -INCORRECT- result. We don't
know the answer exactly, so we cannot return an exact number.
Presumably when you say "perhaps 1000 feet" you mean something different
from "perhaps 4 feet", or otherwise you would not bother; you would have a
single inexact number called "perhaps". There is some level of confidence
that leads you to say "perhaps 100" in preference to any other inexact
result. Am I to regard an inexact number as a probability distribution
(whose shape I may know nothing about)? An interval is one kind of
probability distribution. Maybe I am to understand it as more like a
Gaussian, which tails off but is never zero anywhere. Maybe in that case I
agree that (max 4.0 1000) is "perhaps 1000". But then I am not sure I
believe the underlying model. This is not a fair argument, of course,
because I am knocking down my own straw man. But it illustrates the sort
of model for inexact numbers that I seek. I find the "perhaps" model a bit
*too* vague.
WHat can be said about the level of confidence that leads one to
say "perhaps 1000" instead of merely "perhaps"?
--Guy