# Re: equality

From: Tim Klinger (klinger@cs.nyu.edu)
Date: Mon 24 Nov 2003 - 17:30:25 GMT

```Thomas,

Thanks _very_ much for your detailed response.  I went and read the formal semantics chapter which is considerably more expansive on this topic than the informal semantics, and now understand the intent here.  One question though.  Looking at the definition of I(=_t) on p. A-12, it seems that \bottom = \bottom evaluates to \bottom.  I would've thought it should evaluate to true.  Is \bottom really the intended evaluation?

Thanks,
Tim
----- Original Message -----
From: Thomas Baar
To: puml-list@cs.york.ac.uk
Sent: Monday, November 24, 2003 8:46 AM
Subject: Re: equality

Dear Tim,

the equality symbol = you refer to (p. 6-3) is the declared for the OCL type OclAny. Since Integer and Real
are subtypes of OclAny, you can compare with = also integers and reals, i.e. 1 = 1 or 1 = 1.0 are syntactically correct
expressions on OCL.

In order to decide, whether 1=1 is evaluated to true or false you have to consult Section A.2 (the informal
explanation '"x = y" evaluates to true if x is the same object as y' may confuse, since we are speaking
here about data rather than objects).

In A.2.1 you find, that the data type Integer is always interpreted by the set of integers plus the bottom symbol
for undefinedness  ( I(Integer) = \semint \uni \{\bottom\}) and the data type Real by the set of reals plus the bottom
(I(Real) = \semreal \uni \{\bottom\})
(To express it more in the programmer's way: I(Integer) and I(Real) are the data which are available during
execution time of a program. In that respect they are similar to the objects I(c) of a class c.
The main difference between data and instances is that the set of data can never change (one cannot
create/ destroy data). Furthermore, data are unique, i.e. you cannot find two elements in I(Integer)
with the same value (e.g. value one (denoted here as \semone)).)

After that introduction we come back to your question whether 1=1 is evaluated to true or false.
The literal 1 is always evaluated to its corresponding value in I(Integer) \semone (see A-10 last paragraph)
and the equation symbol = is always evaluated to the identity relation in the semantic domain (here I(Integer),
see A.2.2). So, we have to answer the question whether \semone is identical to \semone and the answer
is simply 'yes, this is true'.

The argumentation for 1=1.0 is similar. Bear in mind, that the data type Integer is a subtype of Real and thus
I(Integer) is a subset of I(Real). Since there is only one element in I(Real) representing the value
one, this must be the same element \semone we have already used above.
Consequently, the literal 1.0 is evaluated to \semone as well and 1=1.0 is evaluated to true.

As you see, this is very similar to the primitive types as realized in Java.

********************

There is no predefined support in OCL to handle integer as objects of classes. But, of course, one
can for instance define a class MyInt with attribute val of type Integer.

As for any other classes, different objects of MyInt (i.e. their identities are distinct from each other)
may have the same value for attribute val,
so we could find a snapshot where the following constraint is evaluated to true:

MyInt.allInstances()->exists(mi1, mi2| not(mi1 = mi2) and mi1.val = mi2.val)

The query equals(arg:MyInt):Boolean in class MyInt you have in mind could be specified as follows:

context MyInt inv:
MyInt.allInstances->forAll(arg|
self.equals(arg) = (self.val = arg.val))

To my knowledge, there is no standardized support in OCL for additional queries as 'equals'
(one could imagine to have them added by default to every class in the user's class model...)

Best regards,

Thomas Baar

Tim Klinger wrote:

Hello all,

I am a bit confused/concerned about the semantics of equality in OCL2.  The spec (1/6/2003) says (p. 6-3) that an expression like "x = y" evaluates to true if x is the same object as y.  For one thing, this is dependent on the mapping of symbols to objects which is not specified anywhere I've seen.  For example, if I implement the evaluation by creating a new object for each integer literal I encounter then "1 = 1" will be false according to this definition.  Regardless, it doesn't seem natural for the primitive types -- something like "1 = 1.0" will evaluate to false.  The java semantics for primitive types seems more intuitive.  Also, for non-primitive objects, object identity is often not a very useful measure of equality.  Maybe it would be better would be to require the evaluation to use an "equals" method on the types if it one were available and default to object identity if not.  I noticed a proposal in the finalization process to add equality for collection types; object identity will not be very useful in that case either.