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.
This suggests that the midpoint of a semi-bounded interval should
simply be Fmax (or -Fmax) -- these will certainly be Interior points.
The case [Fmax, +Inf] is the awkward one since it does not have a
Level 2 interior point.
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).
Does this not avoid all the complications described on page 3?
My rule also satisfies all of the properties of rule (15).
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.
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.
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.
Page 6, 1st line of last paragraph: "This is the true" -> "This is true"
Michel.
---Sent: 2012-02-09 17:33:33 UTC