Dan, Arnold, Nate, P1788
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.