Re: Comparisons and decorations, part 2
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.
John