Re: floats and intervals, constants, 0.1, 1e400 and Inf
Michel Hack schrieb:
> 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
This is exactly waht is in my proposal (v2.0)
> -- 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.
This is something new, not considered in my proposal
- that the floats used to represent bounds are
different from the floats used to represent intervals.
> 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.
Yes.
> 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.
Though briefly discussed, I think nobody has shown strong emotions for
satandardizing mdpoint-radius interval representations.
I advocate against it.
> 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.
This is another issue not considered in my proposal.
The correct conversion would be by outward rounding the bounds.
> 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).
There is level-index arithmetic, which makes overflow and undeflow
almost impossible.... See
C.W. Clenshaw and F.W.J. Olver
Beyond Floating Point
J. ACM 31 (1984), 319-328
http://portal.acm.org/citation.cfm?id=62.322429
But it hasn't been widely used.
Note that my proposal is almost independent of the underlying
number representation.
If there is sufficient positive interest, I can easily adapt to
multiple floating-point formats.
Arnold Neumaier