Re: Midpoint paper (2012-02-08 version)
> Date: Fri, 10 Feb 2012 11:04:38 -0800 (PST)
> From: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
> To: <intervals08@xxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Midpoint paper (2012-02-08 version)
>
> Dan,
>
> I read the last version of "Midpoint paper".
> And it seems to me that it is 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] whe=
> re 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.
Sorry for the misunderstanding. My last post was
in reply to Michel's (quite correct but, I believe,
harmless) complaint that midpoint was not independent
of the underlying floating-point type in the semi-
infinite case.
> I desired such a property:
> (*) midrad([u,v]) is finite floating-point number for finite [u,v] interval=
> s (explicit or implicit).
> The definition (15) may return infinite midpoint for some finite implicit i=
> ntervals.
Alas, while this may be true in one direction for
some specific pair of explicit & implicit types,
I believe it is true that finite intervals of one
flavor may be required to become infinite or
semi-infinite in another if only to preserve
containment.
So, in its full generality, I believe seeking (*)
is a forlorn hope. I'll have to think about
whether or not there is less restrictive but still
useful form of (*) that is always true.
>
> Then I read the Michel's post. It was about semi-finite interval of wider f=
> ormat,
> but it came to me the same may happen
> with midpoint_F([u,v]) Level 2 operation that maps infsup intervals [u,v] o=
> f 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 n=
> umber format ?
I presume the question is asking: if X is in format F
& X' = convertFromF2F'(X) is in format F', what can be
said about width(X)/midpoint(X)/radius(X) in relation
to width(X')/etc.?
It is a good question.
Off the top of my head, I believe that we will find
that if both X & X' are finite in their respective
formats then, for example, radius(X) is within an
ULP of convertF'2F(radius(X')). I don't believe it
is true that radius(X) = convertF'2F(radius(X')) on
the grounds that there are multiple rounding errors
involved. But I haven't looked into it.
I chose radius for that example since (because of you)
it is the most robust of the 3 functions. Still, I
think the other two will have the same property with
the proviso that one or the other might over/underflow.
As for the infinite & semi-infinite cases, I believe
that the fact that explicit & implicit types actually
represent quite different classes of intervals will
mess thing up. As will Michel's observation about
different precisions. Other than weak monotonicity
within a format & Nate's equation (22), I'm not sure
what other properties remain that might contribute
to some formal proof.
Is it properties needed for formal proofs you seek
or something else?
>
> 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 -Fm=
> ax64 }
> > 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 t=
> he set F.
> So I think that it was not binary32-specific .
>
> -Dima
>
Nate & I are proposing width/midpoint/radius that
return floating-point answers in the same format
as the interval inputs. (If that is not in the
text somewhere it should be.)
One could have a format specific (like 754's
formatOf) form of midpoint, for example, that
returns a specific format no matter what the
format of its input. Indeed, some ways that John
might write up this proposal would have them
lying around.
But how (beyond a single extra rounding error)
would such a function differ from
convert2F(midpoint(X'))? All the finite &
semi-infinite inputs would convert with or
without over/underflow as a function of the
relative exponent ranges of the two formats WRT
their floating-point behavior not WRT their
interval behavior. At least I think so.
Indeed, while the issues you raise are valid
& may be important in some contexts, they are
really issues of the incompatibility of the
various formats more than issues of the nature
of these particular functions.
In other words, how do they differ from the
same issues WRT add, subtract, multiply, &
divide?
And what properties do THESE operations still
possess that you can use for formal proofs?
That's about all I can think of at the moment.
Let me know if you can think of some explicit
change to width/midpoint/radius that would
help with any of these concerns.
Dan