(Really: conversions from IEEE 754 floats to Intervals)
R. Baker Kearfott schrieb:
Arnold Neumaier wrote:
I don't think that the floating-point number 2 is derived
from a set of real numbers near 2.
Huh? Certain exact (perhaps irrational numbers) are rounded to 2.
That's what I was saying, no more and no less.
These discussions (back and forth) might make sense if floats
carried a history around -- but they don't. Programs do (or,
at any rate, can), and may know not only whether a particular
float represents an exact value (e.g. a small integer), but
also, more generally, what the error bounds are, and whether
they are absolute or relative.
We have seen application languages that permit numeric literals
to be decorated with uncertainty indications. The same thing
should be possible with computed floats.
Now, surely there will be a generic intval(lower, upper) to
construct an interval from two floats. Perhaps we should also
have explicit support for relative and absolute uncertainty
being passed as an argument, e.g.:
absUncertainFloatToInterval(value, abserr)
relUncertainFloatToInterval(value, relerr)
The advantage of having these is not just convenience: since
the computation of interval bounds is encapsulated, it can
handle overflow and underflow appropriately (e.g. when value
is near a range edge).
The basic floatToInterval() would then always generate a point,
unless conversion was involved (in case of type mismatch).
In languages with implicit type conversion one has to be careful
about precedence. For example, if the interval implementation
type is binary64 but the input value is binary128, the input
must not be coerced to binary64 before being passed to the
encapsulation function. In C for example there would have to
be a separate function for each input type. If preprocessors
are used to generate interval code (one possible implementation
when the language does not support interval types directly),
this step could be hidden behind macros. Conceptually it must
be there however, and 1788 should require this.
Michel.
P.S. Often the question of string vs IEEE float has come up with
regard to '1e400' vs 1e400. These arguments all apply even
in the absence of strings, when multiple floating-point types
are supported: 1e400 is a pretty small Binary128 finite number.
Sent: 2008-11-10 20:21:22 UTC