Re: formatOfMidpoint()
> Date: Sat, 11 Feb 2012 21:47:39 -0500
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Re: formatOfMidpoint()
>
> Dan Zuras wrote, in reply to my suggestion of
> returning NaN when there is no interior point
> representable in the target format:
>
> > 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.
>
> What about midpoint(Empty)?
Yes, I have thought about that & I have no
good answer. The same could be said of
width & radius but, at least in that case,
one could argue that
width(Empty) = Radius(Empty) = 0.
Under those circumstances any answer for
midpoint(Empty) is as good as any other.
Or as bad. For if X = Empty what does
equation (22) mean?
X \subset [m-r,m+r] (22)
where m = midpoint(Empty) & r = radius(Empty)?
It works for any midpoint but NaN. But it
fails for NaN.
>
> I guess you could claim that NaN is to be used only
> when the Level 1 result would be undefined...
John & others have gone back & forth about
whether or not NaNs or NaIs live at level 1.
I am against it if we can find any way out.
But I admit I have no good answer to these
questions.
>
> However, rules such as midpoint having to be interior
> points could be as relevant as containment rules, so
> we have to be careful!
>
> Michel.
Agreed. Very much so.
But please note that WHATEVER answer is returned
for midpoint(X), it will not be in the interior
of X if X has fewer that 3 representable points
in it. That is, it will not be in the interior
unless X HAS an interior. And clearly, Empty
has no interior.
But there is more to these issues than the
definition of midpoint or problems with formatOf
functions.
One problem is the level structure itself.
Proofs must be done at level 1.
The implementations exist at level 3 & below.
But the standard that the user sees exists
at level 2 & no where else. All the behaviors
we define are defined there. They may related
to level 1 to understand the meaning & some
deference must be paid to the lower levels as
a practical matter (say, for speed or memory
limitations). But the user sees level 2 only.
Now one of the problems with looking at the
standard through the lens of the level
structure is that there is no way to relate
one type of intervals to another there. So
far all we know is that, for example,
interval_Float is one finite subset of
contiguous sets of extended Reals & that
interval_Double is another. We know nothing
about how they relate to each other.
So far, anyway. We MIGHT be able to say that
interval_Float is ALSO a subset of interval_Double.
We might, therefore, assert that calculations
done in interval_Double are guaranteed to be
subsets of the same calculations done in
interval_Float.
But have we made sure that is true? I hope so
but Dmitry has raised doubts in me.
The next question is what about calculations
done in BOTH interval types. What can we
claim about those? Can we claim that they are
subsets of the same calculation done strictly
in interval_float &, in turn, that those done
strictly in interval_Double are subsets of the
mixed calculations? I just don't know any more.
BTW, these issues are not confined to just those
functions that Nate & I are discussing. A quick
glance at table 4 in John's 04.3 text lists:
inf(), sup(), mid(), wid(), rad(), midRad(),
mag(), & mig(), all of which are undefined for
Empty inputs.
I must presume that what is meant by that is
these functions return NaN for Empty inputs.
But, in other contexts good answers are:
inf(Empty) = +inf
sup(Empty) = -inf
wid(Empty) = 0
rad(Empty) = 0
mag(Empty) = 0
mig(Empty) = +inf
(Each can be had merely by removing the
"if X is non-empty" from the definition.)
So why are these functions returning NaN?
This still leave us with some serious
questions for mid() & midRad(). But we
can do better than we are at the moment.
Lower down, table 5 defines comparisons
for non-empty sets but says nothing about
how Empty compares out. The text in 5.6.9
details how it works. I'm sure a user
would not be astonished to find that
Empty == Empty is true. But how would
they feel about Empty \disjoint Empty
being true also? Also, Empty \disjoint
AnyNonEmpty is true & yet Empty
\containedIn AnyNonEmpty is also true.
(John, I'm sorry if these criticisms are
late to the party. But I have to admit
that I did not give it so close a look
until the precision & range issues came
up.)
OK, enough grousing.
Nate & I have to come up with some answer
for midpoint(Empty). Suggestions welcome.
But, for now, I'm claiming that all these
other issues, however important, are
outside the scope of our proposal.
It may seem narrow minded.
But that's my story & I'm sticking to it. :-)
Dan