Re: [IEEE P-1788] Motion P1788/M0013.01:ComparisonOperations up for discussion
> Subject: Re: [IEEE P-1788] Motion P1788/M0013.01:ComparisonOperations up for discussion
> From: John Pryce <prycejd1@xxxxxxxxxxxxx>
> Date: Thu, 8 Apr 2010 12:07:57 +0100
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> 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 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
Folks,
I think there are a few issues here that should be kept
separate in our discussion of comparisons.
What set of comparisons should we standardize & make
available to the user? We defined 22 comparisons in all
in 754-2008 (see 5.6.1 & 5.11). I'm sure we will need
more in 1788.
What is the minimum mathematical basis from which to
construct these comparisons? There are several ways to
approach this problem. Motion 13 is one way. The one
John just outlined above is also interesting.
What comparisons should be assigned to existing language
operators "<", "=", "<=", etc? And what names (language
constructs) should we use for the new ones? As we will
be defining comparisons new to languages, the principle
of least astonishment will be strained no matter what we
do. For example, with the set that Ulrich & Bo propose
we have that:
(xx < yy) or (xx = yy) ==> (xx <= yy) but
(xx <= yy) =/=> (xx < yy) or (xx = yy).
I'm sure this is intended but it will astonish some.
While programmers will have to get used to the fact that
trichotomy is just not true for intervals, I don't think
it will take much to convince them.
My interpretation of the intent of motion 13 is that it
only addresses the second question of providing the basis
we need for the larger issues. Motion 13 provides us with
4 comparisons for that basis.
Are they enough to construct all your favorite comparisons?
Are they the proper basis for this task or is there a
better one available?
Issues of the exact set of comparisons we will need & what
names or language constructs will be assigned to them are
important.
But they are not important for motion 13.
So let's put them off to a later day.
IMHO, of course.
Yours,
Dan