Re: Midpoint paper (2012-02-08 version)
> > 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
>
> This is slightly different for decimals, but I take
> your point.
>
> > The monotonic property (10) fails for this interval datatype.
>
> So it does.
>
> I have never heard anyone propose such an interval
> type. It is certainly outside the scope of the 1788
> draft as I understand it.
>
> And you have just given a good reason why it should be. :-)
I read again Level2 draft submitted by John on Jan 5. It says in 6.3.2:
Mid-rad types are not specified by this standard but are useful for examples. A mid-rad
bare interval type is taken to be one whose nonempty bounded intervals comprise all intervals of
the form [m − r, m + r], where m is in some number format F, and r is in a possibly different
number format F , with m, r finite and r ≥ 0. From the definition in §6.3.1 the type must also
contain Empty and Entire; it may also contain semi-infinite intervals.
So P1788 midrad_F type may contain both <Fmax,Fmax>=[0,2*Fmax] and [0,+oo[ intervals.
And definition (15) violates monotonic property (10) on this pair of intervals.
There is another issue with midpoint on midrad_F type. Sometimes this midpoint can't be used for B&B splitting.
Consider interval in 2-digit decimal arithmetic.
<15,0.1>=[1.49,1.51] .
Its midpoint is surely 15, but we can't split it into two midrad intervals.
It seems that the Midpoint paper should restrict its scope to infsup_F intervals.
And in this scope it is good.