Re: Midpoint paper (2012-02-08 version)
Dan,
I read the last version of "Midpoint paper".
And it seems to me that it works good for explicit infsup interval types.
Then I started to think about abitrary imlicit interval types.
What will be the results of midpoint_F([u,v]) definition of (15)
when u and v don't belong to number format F.
Initially I thought about the representation (r;a;b) = [r + a, r + b] where r \in F, a \in F, b \in F.
I found that sometimes midpoint of a finite interval becomes infinite.
Let us consider 2-digit decimal numbers with the exponent range from -9 to +9 .
The (r;a;b) = (9.9e+9;0;1.0e+8) .
Then (15) says that midpoint([r+a,r+b])=midpoint([9.9e9;1e10])=
roundNear((9.9e9 + 1.0e10)/2)=roundNear(9.95e9)=+Infinity .
That was my original complaint.
I desired such a property:
(*) midrad([u,v]) is finite floating-point number for finite [u,v] intervals (explicit or implicit).
The definition (15) may return infinite midpoint for some finite implicit intervals.
Then I read the Michel's post. It was about semi-finite interval of wider format,
but it came to me the same may happen
with midpoint_F([u,v]) Level 2 operation that maps infsup intervals [u,v] of wider IEEE-754 format Fw to
narrower IEEE-754 format F.
So the question that bothers me is:
What properties do we expect from width(X)/midpoint(X)/radius(X) when
X is of implicit interval type or X is of explicit interval type of wider number format ?
I concern about central form application of functions midpoint(X),radius(X).
The property (*) is important for this purpose.
> One MIGHT solve that problem by something like:
>
> midpoint([u,v]) = if ((u==-inf) && (v==+inf)) then 0
> else if (u==-inf) then { if (v>-Fmax32) then -Fmax32 else -Fmax64 }
> else if (v==+inf) then { if (u<Fmax32) then Fmax32 else Fmax64 }
> else roundToNearest((u+v)/2)
>
> That way both single & double precision semi-infinite
> intervals would go through the same sequence of
> midpoints but for the fact that [Fmax32,+inf] is
> further splittable in double but not in single.
> THIS is a function that addresses Michel's original
> complaint. But now we have a function that is specific
> to systems that support binary32 & binary64, no more &
> no less. A system that supports, say, decimal64 &
> decimal 128 would be different. As would a system that
> supports multiple (possibly unbounded) larger precisions
> no matter the radix.
I spoke about midpoint_F([u,v]) operation that maps arbitrary real interval [u,v]
to the fixed format F. My definition used only Fmax and -Fmax elements of the set F.
So I think that it was not binary32-specific .
-Dima