Re: dependent and independent intervals, proposal to toss out
Richard Fateman wrote:
> Again, from an implementation perspective, there seems to be enough
> dispute about the handling of decorations at this point that -- from
> the point of view of implementation -- it looks more like an option
> tacked on to a library for bare intervals, ...
The problem here is that the purpose of P1788 is "dependable computing",
using Interval Arithmetic (and exact dot product, another "DC" primitive).
Some algorithms require, in addition to guaranteed enclosure, a guarantee
that the computation did not gloss over discontinuities in a domain.
In the absence of some kind of exception mechanism this requires testing
intermediate results in many places. IEEE 754 tried to avoid this using
sticky flags (global within a scope that need not be the whole program,
but has to encompass the entire computation over which validity checking
is being deferred). Both of these approaches have severe performance
impacts on parallel programs. By attaching the validity information to
the data, those problems are avoided. This is what led to decorations.
We may still be debating details of the decoration mechanism, but I
think we are all in agreement as to its necessity -- barring any new
invention.
Earlier, Richard also wrote:
> If we are allowed to be slightly sloppy, by about half a unit in the
> last place, we can take the closest binary approximation for 0.1d0
> and widen it by one ulp up and down, and enclose it.
The reason for requiring at least the primitive operations to return the
tightest enclosure is because slop tends to grow rather fast in certain
cases, so when exact point intervals are possible (zero slop), they should
be exploited. Unfortunately floating point scalars are not tagged with an
exactness indicator, so as soon as the context in which a literal is seen
is left, the information is gone. That's why we need interval literals,
and in an environment where intervals are not first-class objects, this
requires (conceptually at least) a function like text2interval().
I mentioned earlier that some compilers allow a global rounding mode to
be specified for converting literals. If the choice of rounding modes
included IBM's Round-to-prepare-for-shorter-precision, which for BFP is
equivalent to ORing in the Inexact indication in the low-order bit, then
one could generate tight intervals from scalars: if the low-order bit is
zero, generate a point interval; otherwise record the bounds as +-1ulp
(the two even representable scalars enclosing the odd argument).
However I don't know of any compilers that do this, not even IBM's.
In any case, this only works when the scalar was derived directly from a
literal (or a constant expression subject to the same rules), so we would
still need two separate constructors: nums2interval() and lits2interval(),
where the latter implements the special rule.
Michel.
---Sent: 2013-02-20 16:17:26 UTC