floats and intervals, constants, 0.1, 1e400 and Inf
The relevant discussion has borrowed a number of subject lines so far:
| Subject: Alternate floating-point results under directed rounding
| Subject: signed zeros
| Subject: inf and 1e400 and alike
Some (e.g. Siegfried Rump) want traditional constants to be transformed
magically into relevant intervals when needed, others (e.g. Arnold
Neumaier) want explicit control, with floating-point constants standing
for their exact selves, and string constants subject to appropriate
conversion to intervals.
I think we have to step back a bit and view the application domain of
an interval standard from some distance. We already agreed (I think)
that 1788 will not be tied to any particular programming language, and
that it would follow the spirit of 754.
There are two ways that I would expect to see 1788 being applied:
(1) As an integral part of certain languages, with explicit types for
interval variables and constants, and a syntax for specifying the
constants.
(2) As a library of structure types and functions, possibly exploiting
operator overloading as is available in some existing languages.
In case (1) the language processor has all the necessary information
for doing what Siegfried expects. Constants can be handled appropriately
when assigned to interval variables or passed as interval parameters.
Perhaps the Translation-Time-Data-Type approach is used, sensibly.
However, once a constant has been assigned to a plain floating-point
type, I believe it should be treated henceforth as an exact value --
because the thread back to the original expression is broken, and some
such values ARE exact -- few enough decimal or hexadecimal digits, for
example, for deliberately-constructed constants.
In case (2) the best that can be done is to exploit user-defined types
and/or operator overloading, but in fact it is the string form of the
constant that has to be converted, avoiding the intermediate step as
Arnold is urging programmers to do.
Now, from the point of view of the 1788 standard, what needs to be
specified is WHAT functionality needs to be available, and what its
semantics are, not HOW this is to be supported in a programming
environment (except as non-normative examples and suggestions).
So we need ConvertFloatToInterval as well as ConvertStringToInterval.
The former should treat its argument as exact -- ASSUMING that the
source type matches the implementation type of intervals. For
example, if the implementation type is Binary64 and the source type
is Binary80 or Binary128 (or Decimal for that matter), the conversion
could be Inexact.
Indeed, a general rule for constant->interval conversion should be
round-down for lower bound, round-up for upper bound (assuming the
implementation is indeed in terms of bounds). The fact that same-type
floats will be converted exactly is then simply a consequence of the
fact that both "conversions" (being no-ops) yield the same result.
This is of course also the place where Inf and Nan source operands
have to be interpreted in the proper context -- and the most common
view here appears to be as an empty interval (with or without raising
some flags). The same thing would happen for a midpoint-radius
implementation, as the radius would simply be zero. Indeed, I suspect
conversion to midpoint-radius would probably go through an intermediate
lower-upper-bound representation.
Now, one concept that has not been discussed so far is whether there
can be several interval types, with different precisions. If so, there
would have to be conversion functions between interval types as well.
Some interval types might not even match traditional floating-point
types exactly, as it might be useful to trade range for precision in
a dynamic manner (e.g. to get a better grip on the gap between Inf
and maxReal).
Michel.
Sent: 2008-11-07 23:06:18 UTC