Re: [mdt-ocl.dev] Equality

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Axel

These are examples of the problems Laurent found. I've added further 
subtests to

/org/eclipse/ocl/examples/pivot/tests/EvaluateNumericOperationsTest.java

        assertQueryFalse(null, "1.0 = 1.0000000000000001");

        assertQueryTrue(null, "1.0 <> 1.0000000000000001");

/org/eclipse/ocl/examples/pivot/tests/EvaluateCollectionOperationsTest.java

        assertQueryTrue(null, "Set{1.0} = Set{1}");
        assertQueryTrue(null, "Set{Set{1.0}} = Set{Set{1}}");

demonstrating expected behaviour for the Xtext parser/pivot evaluator.

The OMG spec is unclear.

"11.4.1 Real

The standard type Real represents the mathematical concept of real. Note 
that UnlimitedNatural is a subclass of Integer
and that Integer is a subclass of Real, so for each parameter of type 
Real, you can use an unlimited natural or an integer
as the actual parameter."

This suggests that Integer 1 is substitutable for and so equal to Real 1.

[Of course 11.3.1 OclAny::= is not overloaded for numerics so

"True if self is the same object as object2."

does not even require that Integer 1 is equal to Integer 1, since there 
is no requirement that numeric values are drawn from a set of singleton 
objects.]

----

I was surprised by the non equality of Java's Integer and Double, but 
this is consistent OO behaviour. Integer and Double are both subclasses 
of Number but mutually independent, so as Objects they are not equal. 
Java does not treat Integer and Double as points on a number line.

Java's int, double equality demonstrates that these convertable types 
are equal and treated as points on a number line.

In OCL, Real and Integer are conformant so equality is to be expected 
between equi-valued Integer and Real.

I don't plan to change OCL<Ecore> or OCL<UML>. But we can at least get 
the pivot evaluator right.

     Regards

        Ed


On 21/03/2011 13:41, Axel Uhl wrote:
> Hi,
>
> following a discussion I had with Ed during EclipseCon, I looked at 
> the equality implementations of numerical data types in Java and OCL. 
> Here are a few first results:
>
> Java:
> -----
>
> System.out.println((double) 1.0 == (int) 1); // --> true
> System.out.println(1l == 1);                 // --> true
> System.out.println(new Integer(1).equals(new Double(1.0))); // -->false
> System.out.println(BigInteger.valueOf(1).equals(new Integer(1))); // 
> -->false
> Set<Number> s1 = new HashSet<Number>();
> Set<Number> s2 = new HashSet<Number>();
> s1.add(1);
> s2.add(1.0);
> System.out.println(s1.equals(s2)); // -->false
>
>
> The corresponding comparisons in OCLEcore:
> ------------------------------------------
>
> 1.0 = 1   --> true
> Set{1.0} = Set{1}   --> false
>
> Additionally, OCL has this:
>
> 1=1.0000000001       --> false
> 1=1.0000000000000001 --> true
>
> which I find somewhat surprising.
>
> We can therefore at least say that there is a similar anomaly in OCL 
> when it comes to numerical types in collections like we see it in Java.
>
> This adds to the question of to which degree OCLEcore should mimic 
> Java/Ecore default behavior versus complying to the letters of the OCL 
> specification. We see a similar discussion in 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=339952 where we can 
> observe different dynamic dispatch behavior for OCL and Java.
>
> In my opinion, OCLEcore should stay close to the Java/Ecore semantics 
> to avoid confusion for the most common use cases. For 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=339952 my opinion is 
> obvious as I raised the bug :-). For the numerical issues, I fear this 
> discussion, in the face of backward compatibility, may open pandora's 
> box. Not sure we can/should change the existing implementation at this 
> point regarding its handling of numerical values.
>
> I'm curious for your opinions.
>
> Best,
> -- Axel
>
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1204 / Virus Database: 1498/3520 - Release Date: 03/21/11