Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!ucsd!nosc!logicon.arpa!trantor.harris-atd.com!x102c!bbadger
From: bbadger@x102c.harris-atd.com (Badger BA 64810)
Newsgroups: comp.lang.eiffel
Subject: Re: a < b < c
Summary: Not all relations are transitive
Message-ID: <2644@trantor.harris-atd.com>
Date: 3 Sep 89 00:34:18 GMT
References: <182@enea.se> <192@eiffel.UUCP> <1300@cheops.eecs.unsw.oz>
Sender: news@trantor.harris-atd.com
Reply-To: bbadger@x102c.harris-atd.com (Badger BA 64810)
Organization: Harris GISD, Melbourne, FL
Lines: 83

In article <1300@cheops.eecs.unsw.oz> marku@cheops.eecs.unsw.oz (Mark Utting) writes:
[...]
>
>I like this abbreviated notation, with one slight reservation.
>
>"a < b <= c" is fine, but "d < e > f" seems to me to be less readable
>than using an explicit `and'.  I agree that it is not ambiguous given
>the above semantics, but it makes me wonder what the relationship between
>"d" and "f" is.
>
>When the relational operators all go in the same direction (possibly mixed
>with equalities), the transitive relationships all hold as well.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Eg. "a" is clearly less than "c" in the above.
>However, when increasing and decreasing operators are mixed, this nice
>transitive property disappears.
>
>I guess I would like to be able to abbreviate sequences of {<,<=,=}
>operators, and sequences of {>,>=,=} operators, but not mix the two.
>
>The specification language Z allows any boolean relational operators
>to be abbreviated in this way, but published specifications seem to
>keep to the convention mentioned above.
>
Please excuse my ignorance of Eiffel syntax.  I don't know the
syntax of Eiffel, but I've been following this discussion with interest.
(Perhaps someone could post an abbreviated Eiffel syntax, to give us
some of the flavor?)  

Also, in what follows, I'm assuming that relational operators can be
defined on user-defined data types.  If this isn't so, I'm sorry.

Holding to a single ``flow'' might seem to avoid ``syntax shock'', but
not all boolean operations on objects yeild transitive relations.
That is,``a < b and b < c'' does not imply ``a < c''.  My favorite
example of this is a probability function which compares the outcome
of dice.
I'll use C syntax (sorry):
Given:

typedef int die_t [6];
  die_t  a = {3,3, 3,3, 3,3};
  die_t  b = {2,2, 2,2, 6,6};
  die_t  c = {1,1, 4,4, 4,4};
int win_loss ( die_t p, die_t q) {
	int i,j;
	int win_loss;
	count = 0;
	for (i = 0; i < 6; i++) { for (j = 0; j < 6; j++) {
		if ( p[i] > q[j] ) count ++;
		if ( p[i] < q[j] ) count --;
	}}
}
int wins ( die_t p, die_t q) {	return win_loss(p,q) > 0;}
int loses ( die_t p, die_t q) {	return win_loss(p,q) < 0;}

Now it turns out that:
	     win_loss   loses           Relation (`a<b' is `loses(a,b)')
              --        -----    
	a b   12        True    	a < b
	b c    4        True     	b < c
	a c  -12	FALSE!   not  ( c < a )

Also keep in mind that ``not (a<=b)'' does not necessarily imply ``a>b''.  
Even when (a<b)  <==> (b>a) .
For example,
 (not subset(a,b) and not eq(a,b)) does not imply (subset(b,a)).

In conclusion, I like the idea of a compact notation, but I think
you'll have to restrict the relational operators.  In Ada, for
example, the not-equals operator (``/='') is derived from the equals
operator and the pre-defined BOOLEAN ``not'' operation.  You cannot
define ``/='' independently of ``=''.  On the other hand, in Ada, 
``<='' is totally independent of ``<'' and ``=''.  The relational
operators are, I think, constrained to return a BOOLEAN type.  (It's
been a while, so I might be wrong on this.)

What constraints to relational operators should be applied?  
What about purity and simplicity?  Does common usage supersede simplicity?
    -----	-	-	-	-	-	-	-	----
Bernard A. Badger Jr.	407/984-6385          |``Get a LIFE!''  -- J.H. Conway
Harris GISD, Melbourne, FL  32902             |Buddy, can you paradigm?
Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.