On 26 Sep 2010, at 13:54, Dan Zuras Intervals wrote:
Arnold Neumaier wrote:
Dan Zuras Intervals wrote:
On 25 Sep 16:48 John Pryce wrote:
On 24 Sep 2010, at 11:48, Arnold Neumaier wrote:
Nate Hayes wrote:
special cases for
A \interior B
such as when A and B are both Entire or A=[1,Infnity]
and B=[0,Infinity]. In these cases, the interior operator
would need to return a different result than when A and B
are compact intervals, such as A=[1,100] and B=[0,200].
??? There is a uniform formula in 754:
[al,au] interior [bl,bu] iff ~(bl-al>=0) and ~(au-bu>=0).
Looking at 754-2008 §5.3.1, I think
(nextDown(al) >= bl) and (nextUp(au) <= bu)
also works, since nextDown(-oo) = -oo and nextUp(+oo) = +oo.
interior([al,au],[bl,bu]) ==
((bl < al) || (bl == -infinity)) &&
((au < bu) || (bu == +infinity))
None of the three formulas works correctly in some cases where
A or B or both are Empty, represented as a pair of NaN's,
(Note that Empty is interior to every interval.)
So some additional patching seems unavoidable anyway.
Arnold Neumaier
I guess it depends on what we store in the interval
part when we are trying to represent empty.
What I get from this thread is that
- We have had at least four valid formulas presented for the topological
"A interiorTo B" when A and B are nonempty, all of which, in principle,
seem to allay Nate's worst fears of performance hit. My nextDown/nextUp
method is clearly bad if these are done in software, but they are such
trivial operations given the 754 number encoding, and so useful, that I
would hope a bit of chip area would be devoted to hard-wiring them in the
near future.
- I am very sceptical that anyone could predict which of the 4 will work
best on a given commonly used architecture, and that probably depends
strongly on how vectorised the code is.
- An "overall best way" to represent Empty in an inf-sup interval type
depends on many things and I am equally sceptical that we can predict it.
So, reluctantly, I believe P1788 should NOT standardise a representation
of Empty this time around. It can do so at the next revision of 1788, if
existing implementations show a "best way" has emerged.
Well, you had been advocating an IsBounded decoration. What is the
meaning of
[1,Infinity] \subseteq [1,Infinity]
if both intervals have the IsBounded decoration?
We hadn't yet discussed the behavior of decorations for nonarithmetic
operations; Motion 8 was silent on these, but in the present context
it must be decided. The rationale is as follows:
Decorations are primarily there to allow making decisions about
nonexistence, existence, and uniqueness correctly. This is the only
place where I think they are essential for the correctness of interval
programs.
Therefore, one needs to ensure that a test for disjointness,
containment, or interiorness, is never false positive.
This rule is enough to decide all ambiguities for these
three comparisons.
In particular, in your query, defining the result to be false is
the only consistent choice.