[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Question regarding numeric types
|
Hi Axel
> 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.
OCL is just electing to use C++/Java value semantics with unspecified and so
unlimited representation.
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.
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
>
