Re: Midpoint and unbounded intervals
> Date: Wed, 25 Jan 2012 13:06:10 -0500
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Re: Midpoint and unbounded intervals
Michel,
You raise so many questions that Nate & I have discussed
offline recently.
>
> Looks good. But I'd like to point out that using radius() instead of
> width() would avoid the underindication of width for very wide intervals.
We were after pinning down the properties of both width() &
midpoint(). Our goal was to provide a sound basis for those
algorithms that seek to narrow an interval. Radius() was not
on our list but I have no objections to including it.
>
> In fact, I wonder whether pegging width of finite intervals at Fmax could
> not lead to problems similar to containment violation. What if a program
> were to rely on implied additivity of widths of disjoint intervals?
If you read the proposal carefully, you will see we considered
doing just that for the "narrower" of the semi-infinite intervals
as well as the "wider" finite intervals. It turns out that it
can be defined in a manner that does not violate weak monotonicity
which is the property related to containment that you mention.
But it also turned out not to buy us anything when it came time
to use width() in an algorithm. And as the definition
width([lo,hi]) = roundToNearest(hi - lo)
Is so much simpler & has no branches, we thought it best to go
with that.
>
> The only issue with radius is for very narrow intervals with subnormal
> endpoints, because ulp/2 might not be expressible.
Two points here: (1) If you have no objection to the definition
radius([lo,hi]) = roundToNearest((hi - lo)/2)
such that the difference is done in a manner that avoids overflow,
then I have no objection to including it in our proposal. The
extreme underflow you mention should also not be a problem.
(2) We also considered defining ULP(interval) in such a manner
that it is the (downward) ULP of the largest finite element in
the interval. But we could not agree on its utility. So we
left it out rather than raise a divisive issue among otherwise
fairly simple support functions. If it is alright with you I'd
rather raise it at a later date when this discussion has played
itself out.
>
> Given that one of the functions is "midpoint", having the other one
> be "radius" sounds sort of natural anyway.
Yes. It seems a natural way to talk about mid-rad intervals.
After all, in that case we have
midpoint(<mid,rad>) = mid &
radius(<mid,rad>) = radius.
But, of course, it is also natural to use
width(<mid,rad>) = 2*radius
in that case as well.
>
> At level 1, radius = width/2. At level 2 this works because the base
> is even for both BFP and DFP -- with the possible exception of intervals
> with subnormal endpoints. The maximum finite radius is Fmax, and is the
> correct radius of the widest-possible finite inf-sup interval.
Actually, one must be careful in decimal. For example, in a
4 digit decimal we might have width = 20.05 exactly but require
that radius = width/2 = 20.05/2 = 10.025 be rounded to either
10.02 or 10.03 according to the rounding mode of choice (of
which there are more in decimal than in binary).
>
> Separately, what is the justification for using round-to-nearest when
> computing width or radius? It does make sense for midpoint, but it
> seems to me that width or radius should use directed rounding, meaning
> that we need two versions, inner_radius() and outer_radius().
I would rather not see 2 versions of such a fundamental
property.
But your point about roundToNearest has deserves some
discussion.
For sufficiently narrow intervals where 2*lo > hi we
have that hi - lo is exact. So width() doesn't care
about the rounding mode in that case. For wider intervals
it is possible that there might be a rounding error &,
strictly speaking, it is possible that one might "interpret"
that containment is in danger by half an ULP if one were to
read the midpoint() & width() of an interval in an output
somewhere. But the original [lo,hi] itself is in no danger
of losing containment.
But if you think this is important, we could go with roundUp
for width() & radius().
I'm OK either way.
>
> If having a to-nearest radius() makes sense, perhaps inner_radius() and
> outer_radius() could be additional functions.
>
> Michel.
>
> ---Sent: 2012-01-25 18:24:09 UTC
No, let's pick one we can all agree on, justify it, & stick
with that. Like I said, I'm OK either way.
Dan