Re: formatOfMidpoint()
> Date: Sat, 11 Feb 2012 16:20:06 -0500
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: formatOfMidpoint()
>
> It seems obvious to me that if a midpoint is not representable in the
> target format, the result should simply be NaN. I'm using the minimal
> definition of midpoint here: an interior point.
It is less obvious to me. More on that below.
>
> This might also be the case for some of the off-center implicit-format
> examples, where the issue is not range but precision: if the Level 1
> interval is entirely between two representable target-format values,
> then there is no representable midpoint, and the result should be NaN.
>
> Michel.
It can happen among the inf-sups as well.
Just after I sent off my reply to Dmitry's
latest posting, I realized it could happen
between 754 floats & doubles.
Suppose the ULP(1) = u in float. Then an
interval like X = [1+u^2,1+2*u^2] can be
exactly represented in double.
But midpoint_Float(X) = 1, which is not in
X. Not because of any poor definition of
midpoint_Float on our part. But because
there ARE NO floats within X.
You might get a hint that something sneaky
is going on when you discover that
width(X) = u^2 << ULP(1).
But Dmitry's definition assures us that
radius(X) = u so long as the rounding is
carried out in float.
Thus (22) still holds. Amazing.
But all that having been said, I'm still not
sure the correct answer is NaN in this case.
Yes, it is true that the midpoint_Float
returns an answer which is strictly OUTSIDE
the interval in this case. But there ARE NO
representable floats within the interval so
there is no better answer.
In a sense, Michel is correct in that the
function has no sensible answer which is the
very DEFINITION of why one returns a NaN.
(The rule is one returns a NaN when there is
no better or less astonishing result.)
But in another sense returning 1 is the best
answer possible under the circumstances.
So we are left with a quality conundrum:
Applying the principle of least astonishment
to an impossible situation, which answer is
likely to cause the least trouble down the
line? NaN? Or 1?
Both are wrong.
But my experience tells me that NaN would
cause more trouble than 1. Returning 1 is
the least astonishing thing to do.
Besides, we have been scrupulously careful
to eliminate the need for NaNs in the ordinary
course of otherwise valid calculations. It
would be a shame to let the camel's nose in
the tent now.
Still, once again, I am not the expert here.
What do you (collectively) think?
Dan
P.S. - I just thought of another good reason
to return 1. If we do then we can define it
something like:
midpoint_Float([u,v]) = convert2Float((u+v)/2)
but to return the NaN we would need to do
something like:
midpoint_Float([u,v]) = {
t = convert2Float((u+v)/2);
dt = convert2Double(t);
if ((u <= dt) && (dt <= v)) return t
else return NaN;
}
Parsimony favors the former.