Re: formatOfMidpoint()
Dan, P1788
On 12 Feb 2012, at 04:57, Dan Zuras Intervals wrote:
> Now one of the problems with looking at the
> standard through the lens of the level
> structure is that there is no way to relate
> one type of intervals to another there. So
> far all we know is that, for example,
> interval_Float is one finite subset of
> contiguous sets of extended Reals & that
> interval_Double is another. We know nothing
> about how they relate to each other.
This isn't a problem caused by the levels structure. At Level 2 it's possible to use arguments such as "Float is a subset of Double" (where Float means the set of numbers representable in IEEE binary32, etc.) hence "the type interval_Float (which I tend to call infsup(binary32)) is a subset of interval_Double".
> So far, anyway. We MIGHT be able to say that
> interval_Float is ALSO a subset of interval_Double.
Do you see any problem in that? Surely it IS so.
> We might, therefore, assert that calculations
> done in interval_Double are guaranteed to be
> subsets of the same calculations done in
> interval_Float. (*)
Ah, there things get trickier. By requiring it to be true for interval elementary functions we make it automatically true for interval-evaluation of expressions (simple extension of the FTIA proof).
But beyond that one must analyse an algorithm line by line.
> ... The next question is what about calculations
> done in BOTH interval types.
That certainly requires line by line analysis, but no more than numerical analysts have been doing for a long time I think.
For an iterative method I would expect (*) to often fail. I haven't an example, but try this. Suppose you have a fast-converging iteration of intervals X enclosing a root z of an equation. Suppose running in Double, it takes 5 iterations to enclose z in an interval Xdouble of width <= TOL. But in Float, after 5 iterations the X is wider than TOL, so it does a 6th iteration that gives a MUCH smaller interval Xfloat, strictly contained in Xdouble. This seems highly possible.
John