Re: Midpoint paper (2012-02-08 version)
> Date: Thu, 09 Feb 2012 11:01:05 -0500
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Midpoint paper (2012-02-08 version)
>
> Some comments.
>
> Just below equation (10): "Note that (10) holds... "
> This should say: "Note that (10) should hold ..."
> or perhaps: "Note that (10) should also hold ..."
> (We haven't defined midpoint() yet, just stated a desired property!)
>
> Page 3, top: "[Fbig, +Inf] which contains three Level 2 datums"
> is false; it only contains two, Fbig and Fmax.
In this case we are considering all of Fbig, Fmax, & +Inf as
Level 2 datums. Thus Fmax is an interior point to this & any
larger positive semi-infinite interval.
>
> 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 case [Fmax, +Inf] is the awkward one since it does not have a
> Level 2 interior point.
It turns out that all intervals containing exactly 2
consecutive representable numbers are awkward in much
the same way. Nate & I spent a lot of time going back
& forth to get that right. It was a property of much
concern to his work.
>
> Note that my rule does not violate weak monotonicity (10). It simply
> means that splitting of a semi-bounded interval takes one extra step,
> first into [low, Fmax] and [Fmax, +Inf], and then on the next step
> we get the midpoint (Fmax+low)/2 for the lower piece (the upper piece
> is not splittable).
One can frame many rules for these functions that don't
break weak monotonicity. Yours is a special case of
"Pick the right most finite point" applied to semi-infinite
intervals only. One could also lean to the left. But we
thought something near the arithmetic mean would make the
most sense to everyone.
At one point, I raised the possibility of the mean of the
number of representable elements. For intervals wider
than the radix, this amounts to something akin to the
geometric mean. And, for intervals containing zero in
their interior, it invariably picks a number quite near
zero.
When I raised the possibility, I thought it would be shot
down for much the same reason as similar functions are
shot down in floating-point: It is too specific to the
floating-point system in question & requires bit twiddling
rather than arithmetic to compute.
But I was wrong & a number of people thought it might be
useful in the interval context. So I may propose it at
some later date. But I would like to think about it a
bit first. It would be a function that lives only at
level 2 & Nate & I have had some difficulty with Dmitry's
definition of radius() in that respect. It is not a
trivial thing to consider.
There is an arithmetic formula rattling around in my head
but I would like it to settle down a bit before I write
it down.
>
> Does this not avoid all the complications described on page 3?
> My rule also satisfies all of the properties of rule (15).
In a way, yes. But looked at another way, defining Fmax
as the midpoint for all (positive) semi-infinites means
we spend an extra step shaving the infinity off the
interval & deal with a finite interval bounded by Fmax
after that.
Special casing midpoint to near (lo+Fmax)/2 avoids that
step.
Further, it may be that the result you are looking for
is something like [5,+inf]. All shaving off infinity
does for you is to require you state the result as
something like [5,Fmax] \union [Fmax,inf].
Its a bit arbitrary don't you think? I will grant you
that it is no more arbitrary than going to (lo+Fmax)/2
but at least that was chosen to save a few of these
extra steps.
>
> I'm not saying rule (15) is bad -- just that the analysis was not quite
> correct, and that there is another, perhaps a bit simpler, possibility.
> As Remark 1 states there is also a more complicated possibility.
Remark 1 is my fault. In an earlier draft that only went
between Nate & myself I proposed using nextUp or nextDown
to preserve weak monotonicity in the semi infinite case.
Then Nate suggested we use directed rounding instead & I
agreed that it was a much more elegant solution. The
remark remains because Nate wanted to record the fact
that we had considered it.
As I said, there are many ways to go. We're just trying
to come up with one we can justify that is also useful
for the applications intended.
If you got a better one, trot it out. Dmitry did.
>
> But in fact I think my rule is better in an environment that supports
> multiple precisions. Consider [low, +Inf]_64 where low < Fmax32 for
> example. This interval can also be represented as [low, +Inf]_32.
> Now lets take midpoints. Converting a midpoint to a narrower range
> should round towards zero to preserve the finiteness property. With
> my rule taking midpoint and converting from binary64 to binary32 would
> commute (both paths ending up with Fmax32), but with rule (15) the
> midpoints would be different.
In fairness we did not consider the case of multiple
precisions. And you are correct that (lo+Fmax32)/2 is
far far smaller than (lo+Fmax64)/2. By the time you
get to this situation, midpoint() is a level 2 function
anyway so both make sense within their contexts.
But I'm OK with that.
Then again, with your approach [Fmax32,inf] is also
far different from [Fmax64,inf]. Neither method splits
the interval is the same (level 1) place.
The one problen I could see is that you might want to
play in both precisions for some application. (I can't
think of one but let's assume there is one out there.)
In this case you would have to say that weak monotonicity
is a level 1 property that is violated among different
precisions at level 2 for semi-infinite intervals only.
Shaving off the infinity would kind of work in this case.
But the issue raised with violating weak monotonicity
would appear again both in the shaved off intervals &
the remaining finite intervals one step later.
It is not the infinity that gets us here. It is the
extra dynamic range.
I am not the expert here. Do you really think this will
be a problem? And even if it is, do you think merely
shaving off the infinity is the solution?
>
> Page 6, Example 4. This is either bizarre or incomplete. I understand
> the reasoning that relation (26) holds for any "m", including points
> not contained in the interval. But calling m a "midpoint" is silly.
> The triplet (m;a;b) that denotes [m+a,m+b] may be useful in certain
> contexts, but when a and b have the same sign it hardly qualifies as
> a (perhaps off-center) midpoint; "reference point" would be a better
> term. The real issue that no matter how we define "midpoint" the
> definition of radius by means of (26) has certain desirable properties.
>
> I certainly would not want the standard to allow mid(m;a;b) blindly
> to return "m". Now, computing "m" from the representation may indeed
> return "m" due to rounding, and perhaps that's what example 4 tried to
> illustrate. But surely midpoint(1.0;10;20) would be 15 and not 1.0,
> right? Perhaps using "m" as the name for the first component is a
> bad idea.
This is Nates text. He can defend himself but the point
he was trying to make here is that, with Dmitry's
definition
radius(X) = magnitude(X-midpoint(X))
equation (22) holds no matter WHAT you pick for the
midpoint. Indeed, it need not even be in the interior
of the interval for the formula to work.
He is not proposing any interval representation along
these lines (although others have). He is just trying
to say that the formula is very robust to the choice
of midpoint.
That's all.
>
> Page 6, 1st line of last paragraph: "This is the true" -> "This is true"
>
> Michel.
Ain't it the truth. :-) - Dan