Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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

```