I asked:

>>  Is there a fundamental reason not to define A/=B automatically
>>  as .not.(A==B)? Or is that just a bloody oversight that will take
>>  years to make it into the standard?
    <snip>

Richard Shapiro wrote:

> Yes, it's not true. Consider if A and B are IEEE reals, and A is NaN. 
> A==B is false, and so is A/=B. It's not hard to imagine a derived type with
> a similar property.

But here one of the variables (or expressions) have an illegal value for
the operation in question. I should get an exception (core dump) rather
than see the code executed.
So I cannot accept this as a fundamental counter argument.

BTW Ada does define an intrinsic  A==B  operator for user-derived types,
where A and B are the same type, and that implies /= as well (as .not.(A==B)).
This is a very useful definition and covers probably 99 precent of all user
cases. Ada, however, also accepts that there are cases where this is not
quite the right default and allows so-called limited types where these
intrinsic operators have to be defined by the programmer. That seems to be
a very reasonable solution.
(There is a complication with recursive types like linked lists where one could
ask whether the two pointer elements have the same value or the same address.
The latter implies same value as well. The equality-of-address is certainly
easier and more in line with the implementation of pointers in Fortran, e.g.
the assignment rules of such types.)


Miles Ellis wrote:

> It was certainly not an oversight.  The relationship, if any, between
> overloaded operators is not related to the relationship, if any, between
> the similar looking intrinsic operators.
> 
> For example, it might be useful in some "fuzzy logic type" applications for
> A==B to mean that A and B were "approximately equal", but for A/=B to mean
> that A and B were not exactly equal (or "identical").  If A==B and A/=B
> were both true then the program would know that A and B were not
> "identical", but were close enough for most purposes, whereas if A==B was
> true and A/=B was false then A and B would be "identical".

I know little about fuzzy systems but what about the four cases
"equal", "approximately equal", "not equal" and "not approximately equal"?
One can also "abuse" notation to mean something similar but different
which is usually confusing unless it is commmonly used in the field.
The Ada solution for limited types could be applied in this case.

Harvey Richardson wrote:
> Here is a (very) contrived example...
> I can define DUMP to be a derived type encapsulating access to
> an IO device.  I can define T to be an arbitraray derived type
> with many components.  
> Then assume variables t,dump and that I overload > so that I can 
> write
>  t > dump
> means write t to the dump device and return true on success.
> Your transformations are not helpful since 
>   t < dump  
> could mean read t from dump.
> (back to sanity now...)

Yes, I agree. My ambition to get beyond == and /= let me go too far.
One would need certain restrictions on the types of arguments that can
be used to allow the negations, in other words the types would have to
have the attribute of being sortable (which implies that A<B, A==B, or A>B).

Cheers,
Werner
-----------------------------------------------------------------------
| Werner W Schulz                                                     |
| Dept of Chemistry                  email:     [log in to unmask]       |
| University of Cambridge            Phone:     (+44) (0)1223 336 502 |
| Lensfield Road                     Secretary:          1223 336 338 |
| Cambridge CB2 1EW                  Fax:                1223 336 536 |
| United Kingdom                     WWW:                             |
-----------------------------------------------------------------------





%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%