Re: equality



Date view Thread view Subject view Author view Attachment view

From: Steffen Zschaler (sz9@inf.tu-dresden.de)
Date: Tue 25 Nov 2003 - 08:25:02 GMT


Hi,

Yes, equality (as most operations and operators in OCL) is strict, 
meaning that the undefined value is propagated. Differences to this are 
specifically noted. In order to test for undefinedness you use the 
oclIsUndefined() operation as in: (not x.oclIsUndefined() implies x > 10).

Steffen

Tim Klinger schrieb:

> 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 <mailto:baar@ira.uka.de>
>     To: puml-list@cs.york.ac.uk <mailto: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.
>>
>>     Comments would be welcome.
>>
>>     Thanks,
>>     Tim Klinger 
>

-- 
Dipl.-Inf. Steffen Zschaler
Research Assistant

Dresden University of Technology
Department of Computer Science

Phone +49 351 463 38555
Fax   +49 351 463 38459
Email Steffen.Zschaler@inf.tu-dresden.de

Date view Thread view Subject view Author view Attachment view