Re: [IEEE P-1788] Motion P1788/M0013.01:ComparisonOperations up for discussion
P1788
I agree with the questions George is asking (i.e., that they should be asked) and with the implied suggestion that we should take a step back and ask what P1788 should aim to achieve with comparisons.
On 7 Apr 2010, at 21:27, Corliss, George wrote:
> On 7 Apr 2010, at 12:49, Marco Nehmeier wrote:
>> I think we need the intersection and the following operation
>>
>> isSingleton(\x) :<=> x_inf == x_sup
>>
>> together with glb and lub as defined in the Motion to realize the required "certainly" and "possibly" relations.
> If that is so, should they be included in Motion 13?
>
> Or, do they belong in a different list of operators and let Motion 13 assume their existence.
>
> Clearly, with glb or inf and lub or sup, we can program any comparisons we want. Then why specify comparisons at all?
Indeed. inf and sup are not as simple as they look, as regards exceptional cases.
- Do we mean the mathematical inf and sup of sets? In this case the usual convention in real analysis is that
inf(Empty) = +oo, sup(Empty) = -oo.
- Or do we mean the Level 3 operations "extract the inf and sup fields of an interval data structure"? In which case inf and sup of Empty will almost certainly be implementation-dependent (though usually NaN). I am VERY against this, and think getting inside the data structure should be forbidden to the "ordinary 1788 user" and restricted to library developers in some way.
- And what are inf and sup of a "notValid" interval? This isn't decided yet, but I would go for NaN.
> Is the intent that Motion 13 list a minimal set of comparisons so that all others can be build WITHOUT inf & sup?
>
> Or should Motion 13 list all the comparisons we want?
Good Qs
> I favor a minimalist approach, but I am not convinced the list in Motion 13 is the right set of comparison operators.
I agree, and see (*).
> I agree with Prof. Markov that the notation violates the Principle of Least Astonishment regarding "<" and "<=", but I'm willing to assign descriptive names to these operators later.
I also wrote to Ulrich saying I'm not keen on "<" and "<=", but am willing to do as George suggests.
(*) I think we should consider the scheme proposed in the draft C++ interval standard N2137 (2006), where there is a uniform scheme _exactly_ analogous to numeric interval operations:
xx rel yy = { x rel y | x in xx and y in yy }, (where rel is <, <=, etc.)
returning a subset bb of {0,1} = {false, true}. I believe all the "possibly" and "certainly" relations are easily constructed from these, but that the Kulisch xx <= yy cannot be, so would need to be a separate operation. The object bb can be (but I don't think one should prescribe it must be) represented as a bit-string of length 2. Since we already have decoration trits probably represented in the same way, that is no big deal.
That's my two pennyworth. Would Guillaume, who is an author of N2137, be interested to propose a discussion of this scheme?
John