Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Question regarding numeric types 
I can always write an expression

	let r:Real=1.0/3.0 in r*3

and hope to get back 1.0. But how realistic is that in practice?


This is nothing to do with OCL.

The same in C++ or Java would also have a debatable same-typed 1.0 as an
answer.
It may as well come back with .9999999999 and have the comparison fail. That's why it's good practice in those languages not to rely on arbitrary precision and never compare two double values with ==. 


OCL is just electing to use C++/Java value semantics with unspecified and so
unlimited representation.
Only that the implementation can't currently provide such unlimited representation, particularly for periodic fractions. Of course you could come up with some Fraction class to represent such values internally, but then you still don't have the Real numbers but just the rational numbers which doesn't suffice for the OCL spec either. Futile, I think. 


The (1.0./3.0)*3 == 1.0 problem (calculation accuracy) is completely
different to the 1 == 1.0 problem (numeric equivalence).

You obviously haven't read my 'Aligning OCL with UML' paper. It makes it
very clear how important it is to separate OCL and implementation semantics
in different layers so that the two are independent until you want them to
be dependent. e.g. in an EMF-object semantics library.
I generally like the idea of a library that defines semantics for a particular environment. For after Indigo it seems worthwhile exploring how to apply the evaluator you wrote for the Pivot model to the Ecore model and replace the old evaluator with it. It would gain most of the benefits of the new Pivot package while not raising the bar due to an additional model to be maintained.
What is your suggestions w.r.t the "mature" implementation? Shouldn't we at least be able to specify exactly how it behaves even if we think this is not literally in line with what the specification says? 

Best,
-- Axel



	Regards

		Ed


-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx
[mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
Sent: 18 April 2011 15:00
To: MDT OCL mailing list
Subject: Re: [mdt-ocl.dev] Question regarding numeric types

Ed,

I agree with the value semantics part. That's not a problem with
EMF/Java semantics because Java collections don't compare by
identity of
the Java primitive wrappers but by equality. So the "this 3
!= that 3"
doesn't cause problems.

The OCL conformance of Integer to Real is really a pain in
the neck from
the Java perspective, probably the specification of the type Real as
such: "The standard type Real represents the mathematical concept of
real." I can always write an expression

	let r:Real=1.0/3.0 in r*3

and hope to get back 1.0. But how realistic is that in practice? Even
one step further:

	let r:Real=1.0/3.0 in 1=r*3

How likely is it that all OCL implementations will solidly
return true
in this case? This seems a very unreliable operation except
for writing
is as documentation next to some model (which I care less
about than I
do care about executable specifications).

Also, from an EMF perspective, the int 3 == double 3.0
doesn't matter so
much because I'm not aware of an EMF case where this type of
comparison
collapses the two values. All collections in Java are Object-typed,
therefore will use the wrappers.

The potential inconsistency between an EMF
x.many_feature.size() and a
corresponding OCL x.many_feature->size() is pretty irritating.

Best,
-- Axel

On 4/18/2011 3:16 PM, Willink, Ed wrote:

Hi Axel

Interesting observation.

Pedantically, OCL 2.0, 2.2, 2.3 has no explicit numeric

equality semantics.

Just:

"OCLAny
=(object2 : OclAny) : Boolean
True if self is the same object as object2. Infix operator.
post: result = (self = object2)"

which does not require that this 3 is equal to that 3.

--------------------------------------------------------------------

IMVHO OCL is primarily a specification language and so

should be highly

implementation-independent; although I'm not convinced that

million-digit

precision is totally necessary or practical for division.

OCL should support libraries so migration should be an issue.



---------------------------------------------------------------------


OCL cannot just adopt Java semantics because Java has three

different

semantics for two different equalities

value-semantics: int 3 == double 3.0
object-semantics: Integer 3 != Double 3.0, and this Integer

3 != that

Integer 3
object-value-semantics: Integer 3 !.equals Double 3.0, but

this Integer 3

.equals that Integer 3



---------------------------------------------------------------------


OCL does have Integer to Real conformance which strongly

suggests that if


this Real 3 = that Real 3, then this Real = that Integer 3

I think that anything other than value-semantics for OCL

numerics is almost

untenable.



----------------------------------------------------------------------


The EMF anomally is embarrassing, but can be worked around

by ensuring

the the EMF UniqueEList is assessed for OCL uniqueness when

creating a

corresponding SetValue. This should lead to no

inconsistency, any access

within OCL should see the collapsed collection.

In order to be more EMF-friendly, the EMF OCL Standard

Library which must

anyway
define the mapping of Etypes to OCL primitives can define

its own variant

equality
semantics.

NB. With a modelled library, equality is defined by the

library not by OCL.


[I haven't got the code to hand, but I suspect that

SetValue is already

collapsing a collection, using polymorphic Value equality, which is
currently
built-in. It's one of a number of areas that can be more

model driven.]


	Regards

		Ed


-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx
[mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
Sent: 18 April 2011 13:09
To: MDT OCL mailing list
Subject: [mdt-ocl.dev] Question regarding numeric types

Ed, all,

I'm wondering how OCL semantics for numeric types interferes
with Java's
definition. We had this discussion before. But here's a
thought that I
think hasn't been brought forward yet.

If we integrate OCL with Ecore/EMF then on the EMF side there are
collection types and their constraints, derived from the Ecore
multiplicity settings. For example, there is UniqueEList. It's
add/contains is based on regular Java equality.

With this, an EObject many-feature that is modeled as unique
can easily
hold EDoubleObject and EIntegerObject values that are not equal
according to Java semantics but will be equal according to
standard OCL
semantics. If an OCL PropertyCallExp accesses such a feature, an
inconsistent OCL collection will result, inconsistent in one
of two ways:

    - if OCL chooses to collapse values equal to each other
according to
OCL semantics, the property's cardinality will differ from the EMF
feature's cardinality

    - if OCL leaves the values distinct according to Java

semantics in

place, the collection is inconsistent from OCL's point of
view because
it should be unique but has two distinct values equal
according to OCL
semantics.

   From an EMF/Ecore perspective, the most pragmatic way out of this
dilemma seems to be to alter OCL semantics such that they

comply with

Java semantics. In particular, this would make 3.0<>   3 which
might come
as a shock to the OCL purist but would probably be fairly
intuitive to
Java/EMF/Ecore consumers.

The implications, of course, are horrible in another sense. OCL
expressions would not be entirely portable across
environments. But: is
this a dominant use case? What would it look like? How

would I obtain

and re-use a significant body of OCL-implemented libraries in
a platform
context different from the one where it was developed?

Best,
-- Axel
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev



Please consider the environment before printing a hard copy of this
e-mail.

The information contained in this e-mail is confidential.

It is intended

only for the stated addressee(s) and access to it by any

other person is

unauthorised. If you are not an addressee, you must not

disclose, copy,

circulate or in any other way use or rely on the

information contained in

this e-mail. Such unauthorised use may be unlawful. If you

have received

this e-mail in error, please inform us immediately on +44

(0)118 986 8601

and delete it and all copies from your system.

Thales Research and Technology (UK) Limited. A company registered in
England and Wales. Registered Office: 2 Dashwood Lang Road,

The Bourne

Business Park, Addlestone, Weybridge, Surrey KT15 2NX.

Registered Number:

774298

Thales UK Limited. A company registered in England and

Wales. Registered

Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX. Registered Number: 868273
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev




_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev

Back to the top