Re: Midpoint paper (2012-02-08 version)
Dan,
> Indeed, let me mention that this entire discussion
> is outside the scope of the proposal that Nate & I
> are making.
Even the discussion is outside the scope, it is very close to it.
I suppose that "midpoint" operation is another name of the required numeric function of interval "mid"
that is defined in Table 4 of DRAFT 04.3 . If "midpoint" is a new function then my emails are really out of the scope.
The objective of your proposals is "to define width and midpoint operations for P1788
intervals in such a way that the operations are useful for numerical methods
involving centered forms and bisection algorithms that require the
splitting or shrinking of intervals."
The current "Midpoint paper" succeed to find the operation for two common interval datatypes:
the argument is of infsup interval datatype T derived from the number format F and the result is of F;
the argument is of midrad interval datatype T derived from the number format F and the result is of F.
I shall name these datatype infsup-F and midrad-F.
However, the current draft for Level 2
http://grouper.ieee.org/groups/1788/email/msg04488.html
mentions in 6.3.1 arbitrary interval datatype T that is not tied to any
number format F. I suppose that the standard will have a common definition of "mid" function
both for infsup-F/midrad-F datatype and as well for arbitary datatypes.
Hence, IMHO, the attempt to explore definitions of "mid" for arbitrary datatypes
is close to the scope of definition of "mid" for infsup-F/midrad-F.
I see that there are two opinions about midpoint of narrow intervals:
midpoint([1+u^2,1+2*u^2])=1 or midpoint([1+u^2,1+2*u^2])=NaN .
So I retain from considering midpoint on narrow intervals for a while .
I still have some feeling that part of definition (15) mid_F([u,+oo[) = ulp((u + Fmin)/2) is unnatural.
Informally, the semi-infinite right side is "larger" than finite left size.
I searched for example. And I found one that seems to be in the infsup-F/midrad-F scope.
Consider interval datatype T = infsup-F \union midrad-F .
Representation of this interval datatype is (F,F,bool) .
bool flag says if it is infsup or midrad .
Consider two intervals from T: midrad <Fmax,Fmax>=[0,2*Fmax] and infsup [0,+oo[ .
The formula (15) gives
mid_F([0,2*Fmax])=roundNear((0+2*Fmax)/2)=roundNear(Fmax)=Fmax .
mid_F([0,+oo[)=roundUp((0+Fmax)/2)=roundUp(Fmax/2)=Fmax/2
The monotonic property (10) fails for this interval datatype.
The Michel's suggestion that mid_F([u,+oo[)=Fmax passes property (10).
>>
>> This suggests that the midpoint of a semi-bounded interval should
>> simply be Fmax (or -Fmax) -- these will certainly be Interior points.
>
> Yes, we looked at this. And it would work in its own fashion.
> But we concluded that for the desired application, that of
> narrowing an interval by some means, choosing an interior
> point near (lo+Fmax)/2 was more useful. Indeed, that was
> the lowest point we could choose & still maintain weak
> monotonicity. For "wide" semi-infinite intervals it is
> still no where near the mean of the list of representable
> numbers (which would split our task into 2 equal parts).
> But it is the best we can do short of that.
The "(lo+Fmax)/2" definition saves 1 iteration of 1025 .
The advantage of "Fmax (or -Fmax)" definition is simlicity and regularity.
Also, the "Fmax (or -Fmax)" definition enables monotonic extension of mid_F(X) on arbitrary interval type T.
Either with mid([1+u^2,1+2*u^2])=1 or with mid([1+u^2,1+2*u^2])=NaN .
-Dima