Home » Modeling » OCL » UnlimitedNaturalLiteralExp name mismatch
| UnlimitedNaturalLiteralExp name mismatch [message #50897] |
Fri, 22 February 2008 21:59  |
Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Hello!
The 'UnlimitedNaturalLiteralExp' EClass in the OCL metamodel does not match
the (probably inconsistent) 'UnlimitedNaturalExp' name found in the OCL
specification (in formal/06-05-01, at least). Also the 'symbol' attribute
is named as 'integerSymbol' instead. Is this right? By the way, should not
this 'integerSymbol' be of an 'EBigInteger' type rather than an
'EIntegerObject'?
I am currently working with OCL 1.2.0 M5.
Thank you very much!
Victor Sánchez
|
|
|
| Re: UnlimitedNaturalLiteralExp name mismatch [message #50925 is a reply to message #50897] |
Fri, 22 February 2008 22:53  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
You have rediscovered https://bugs.eclipse.org/190461
BigInteger cannot represent the 'unlimited' value (*) any better than
Integer can. And, since it isn't very interesting in models to be able to
specify multiplicity values in the billions, anyway, Integer seemed a good
choice.
Not to mention that OCL's Integer datatype represents the mathematical group
of the same name and, therefore, does not have finite precision as does
Java's Integer. Thus, MDT OCL would, logically, map OCL's Integer to
Java's BigInteger, too. Besides the fact that mapping UnlimitedNatural to
BigInteger would necessitate the same mapping for Integer, because it
wouldn't be practically useful to be able to specify a multiplicity
upper-bound that you cannot match with the equal lower bound (with the sole
exception of *). In any case, BigIntegers don't make for a usable Java
API.
Natural numbers are a subset of the Integers, specifically those that are
greater than zero. The name "UnlimitedNatural" is silly because these
numbers are, actually, more limited than the Integers. The only thing
special about UnlimitedNatural is that it includes the value *, which isn't
a number at all.
Finally, MDT OCL had to re-define all of the primitives that OCL formally
re-uses from the UML Infrastructure because, among other reasons, OCL
defines the Real that UML forgot and made Integer a specialization of it.
All told, it's a pretty bleak picture.
HTH,
Christian
Victor Sanchez wrote:
> Hello!
>
> The 'UnlimitedNaturalLiteralExp' EClass in the OCL metamodel does not
> match the (probably inconsistent) 'UnlimitedNaturalExp' name found in the
> OCL specification (in formal/06-05-01, at least). Also the 'symbol'
> attribute is named as 'integerSymbol' instead. Is this right? By the way,
> should not this 'integerSymbol' be of an 'EBigInteger' type rather than an
> 'EIntegerObject'?
>
> I am currently working with OCL 1.2.0 M5.
>
> Thank you very much!
>
> Victor Sánchez
|
|
|
| Re: UnlimitedNaturalLiteralExp name mismatch [message #50952 is a reply to message #50925] |
Fri, 22 February 2008 23:55 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Oops! Didn't know about that bug (not that I know about plenty of
them anyways).
Thank you for these very insightful comments, Christian. I
didn't manage to completely understand them on the first try. ;)
Victor Sánchez
|
|
|
| Re: UnlimitedNaturalLiteralExp name mismatch [message #50979 is a reply to message #50952] |
Sat, 23 February 2008 00:45 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hey, no problem, Victor.
There are more bugs in the OCL component than I would like, and I don't have
the resources that I would like to fix them. That's how I know that I'm
normal!
Sorry about what must have seemed like a rant ... I shouldn't let my bad day
leak out like that.
cW
Victor Sanchez wrote:
> Oops! Didn't know about that bug (not that I know about plenty of
> them anyways).
>
> Thank you for these very insightful comments, Christian. I
> didn't manage to completely understand them on the first try. ;)
>
> Victor Sánchez
|
|
|
| Re: UnlimitedNaturalLiteralExp name mismatch [message #51006 is a reply to message #50979] |
Sat, 23 February 2008 08:48 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Christian, replies inline.
> There are more bugs in the OCL component than I would like, and I don't
> have the resources that I would like to fix them. That's how I know
> that I'm normal!
Yeah, nice scientific evidence.
I didn't mean to imply that the OCL project had many bugs, which I don't
really know and on the other hand perhaps it should not be seen as a bad
sign. I just wanted to point out that I am not usually aware of any bugs
concerning the whole Eclipse platform except a couple of them related with
my work and at most a couple more. I'm afraid I don't have time for more,
and that may be seen as evidence that I'm not Unlimited! ;)
What I meant was simply that it occured to me that a quick search in
the bugzilla could have easily led me to that bug.
> Sorry about what must have seemed like a rant ... I shouldn't
let my bad
> day leak out like that.
I didn't noticed that. Your replies have been very enlightening for
me and I am nothing but grateful about that. :)
Anyways, I have given the subject a couple more thoughts. On one part, I
am (only a little) uncomfortable with the presence of the 'unlimited'
attribute, which could easily be internally represented as a negative
value of the 'integerSymbol' in 'UnlimitedNaturalLiteralExp', both the
'EIntegerObject' or an 'EBigInteger' types being equally capable of
distinguishing between natural numbers plus zero versus negative numbers.
Just like EMF does with ETypedElement.UNBOUNDED_MULTIPLICITY, a negative
constant could be provided to uniformly represent the unlimited (non)
number. However I wasn't able to find any description about the exact
representation intended for storing UnlimitedNaturals in neither the OCL
nor the UML specs, so I suppose yours is as valid as any other.
On the other hand, languages extending OCL could import such
UnlimitedNatural for their own purposes (provided that
these reinterpretations are allowed), such as their use in some
(sophisticated or precision demanding) algorithms, in which case, the
precision provided by EIntegerObject might become insufficient in some
cases. The opposite problem is, as you point out, that suddenly all lower
and upper bounds would have to be refactored as EBigIntegers, which seems
to be a little bit excessive from a practical sense. In the meantime, I
can easily adapt to whichever format you use in the OCL project, so it is
not really a big deal.
By the way, you surely are aware of the OCL specification mentioning
UnlimitedInteger in section 11.4.5.
Thank you again for your replies!
Victor Sánchez
|
|
|
| Re: UnlimitedNaturalLiteralExp name mismatch [message #51034 is a reply to message #51006] |
Sat, 23 February 2008 09:05 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
Ok, I now see that you do have a (negative) constant for the unlimited
value and that 'unlimited' is derived. Sorry about that! :)
Victor Sánchez
> Anyways, I have given the subject a couple more thoughts. On one part, I
> am (only a little) uncomfortable with the presence of the 'unlimited'
> attribute, which could easily be internally represented as a negative
> value of the 'integerSymbol' in 'UnlimitedNaturalLiteralExp', both the
> 'EIntegerObject' or an 'EBigInteger' types being equally capable of
> distinguishing between natural numbers plus zero versus negative numbers.
> Just like EMF does with ETypedElement.UNBOUNDED_MULTIPLICITY, a negative
> constant could be provided to uniformly represent the unlimited (non)
> number. However I wasn't able to find any description about the exact
> representation intended for storing UnlimitedNaturals in neither the OCL
> nor the UML specs, so I suppose yours is as valid as any other.
|
|
|
| Re: UnlimitedNaturalLiteralExp name mismatch [message #51089 is a reply to message #51034] |
Mon, 25 February 2008 13:43 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Victor Sanchez wrote:
> Ok, I now see that you do have a (negative) constant for the unlimited
> value and that 'unlimited' is derived. Sorry about that! :)
I do? Cool. I had completely forgotten. :-)
There it is, in the org.eclipse.ocl.expressions.UnlimitedNaturalLiteralExp
interface: UNLIMITED.
cW
>
> Victor Sánchez
>
>> Anyways, I have given the subject a couple more thoughts. On one part, I
>> am (only a little) uncomfortable with the presence of the 'unlimited'
>> attribute, which could easily be internally represented as a negative
>> value of the 'integerSymbol' in 'UnlimitedNaturalLiteralExp', both the
>> 'EIntegerObject' or an 'EBigInteger' types being equally capable of
>> distinguishing between natural numbers plus zero versus negative numbers.
>> Just like EMF does with ETypedElement.UNBOUNDED_MULTIPLICITY, a negative
>> constant could be provided to uniformly represent the unlimited (non)
>> number. However I wasn't able to find any description about the exact
>> representation intended for storing UnlimitedNaturals in neither the OCL
>> nor the UML specs, so I suppose yours is as valid as any other.
|
|
|
| Re: UnlimitedNaturalLiteralExp name mismatch [message #51117 is a reply to message #51006] |
Mon, 25 February 2008 14:11 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
See some replies in-line, below.
Cheers,
Christian
Victor Sanchez wrote:
> Christian, replies inline.
>
>> There are more bugs in the OCL component than I would like, and I don't
>> have the resources that I would like to fix them. That's how I know
>> that I'm normal!
>
> Yeah, nice scientific evidence.
I used to be a scientist: trained in Geology. Now, I'm a computer
programmer. So, my grasp on scientific principles is weakening :-)
> I didn't mean to imply that the OCL project had many bugs, which I don't
> really know and on the other hand perhaps it should not be seen as a bad
> sign. I just wanted to point out that I am not usually aware of any bugs
> concerning the whole Eclipse platform except a couple of them related with
> my work and at most a couple more. I'm afraid I don't have time for more,
Nah, don't worry. I wasn't offended. There really are more bugs than I can
cope with, and unfortunately quite a few that cannot be resolved until
release 2.0 because they require API breakage.
> and that may be seen as evidence that I'm not Unlimited! ;)
heh heh
> What I meant was simply that it occured to me that a quick search in
> the bugzilla could have easily led me to that bug.
It could, but sometimes the newsgroup is faster! And provides more complete
answers, anyway. I enjoy discussions like this.
>> Sorry about what must have seemed like a rant ... I shouldn't
> let my bad
>> day leak out like that.
>
> I didn't noticed that. Your replies have been very enlightening for
> me and I am nothing but grateful about that. :)
I, too, have given this whole numeric precision issue a good deal of
thought. Actually, one of the contributions that I committed in this
release added support for run-time values of Long precision
(https://bugs.eclipse.org/198451) but that doesn't support the BigInteger
datatype, either.
> Anyways, I have given the subject a couple more thoughts. On one part, I
> am (only a little) uncomfortable with the presence of the 'unlimited'
> attribute, which could easily be internally represented as a negative
> value of the 'integerSymbol' in 'UnlimitedNaturalLiteralExp', both the
> 'EIntegerObject' or an 'EBigInteger' types being equally capable of
> distinguishing between natural numbers plus zero versus negative numbers.
Right, as you observed in a follow-up, 'unlimited' is actually derived from
the -1 value.
> Just like EMF does with ETypedElement.UNBOUNDED_MULTIPLICITY, a negative
> constant could be provided to uniformly represent the unlimited (non)
> number. However I wasn't able to find any description about the exact
> representation intended for storing UnlimitedNaturals in neither the OCL
> nor the UML specs, so I suppose yours is as valid as any other.
There is much else that the OCL spec forgot to specify how it should be
persisted, including dynamically-generated types (as indicated by the spec)
such as collection types and tuple types, that are referenced by
expressions. There is no guidance suggesting how to persist references to
these transitory types. But, this is an unrelated problem ...
> On the other hand, languages extending OCL could import such
> UnlimitedNatural for their own purposes (provided that
> these reinterpretations are allowed), such as their use in some
I think these reinterpretations should be allowed. OCL, itself,
reinterprets the UML Infrastructure Library's Integer as a primitive type
conforming to Real (defined by OCL).
> (sophisticated or precision demanding) algorithms, in which case, the
> precision provided by EIntegerObject might become insufficient in some
Yes. A strategy such as was implemented in the contribution I linked to,
above, may prove useful, here. Only the final value of a run-time
calculation must conform to the declared type of the variable or feature to
which it is assigned.
> cases. The opposite problem is, as you point out, that suddenly all lower
> and upper bounds would have to be refactored as EBigIntegers, which seems
> to be a little bit excessive from a practical sense. In the meantime, I
> can easily adapt to whichever format you use in the OCL project, so it is
> not really a big deal.
Well, I don't think OCL can change this any time soon. It would be a
considerable API breakage.
> By the way, you surely are aware of the OCL specification mentioning
> UnlimitedInteger in section 11.4.5.
Oh, yes. Using the wrong name, of course, and described as an instance of
the bogus UnlimitedIntegerType metatype, instead of PrimitiveType as
specified by UML. As the UnlimitedIntegerType is missing from the Types
package specification (Section 8.2) I can only conclude that this
definition in Section 11.4.5 is yet another inconsistent/missed update from
a previous revision as the spec slowly catches up to the actual reality of
the UML 2.x spec.
What is also missing is a formal definition of the UnlimitedNaturalExp in
Section 8.3.5. I would not have been surprised if, had it been described
in that section, it would have been named UnlimitedNaturalLiteralExp as in
the MDT OCL model. There have, through the history of revisions of the OCL
2.0 spec, been other inconsistencies between the diagrams and the text, and
between various chapters of the text.
> Thank you again for your replies!
No problem. As I indicated, these discussions are fun. :-)
> Victor Sánchez
|
|
|
| Re: UnlimitedNaturalLiteralExp name mismatch [message #51174 is a reply to message #51117] |
Mon, 25 February 2008 21:53 |
| Eclipse User |
|
|
|
Originally posted by: research.opencanarias.com
>> What I meant was simply that it occured to me that a quick search in
>> the bugzilla could have easily led me to that bug.
>
> It could, but sometimes the newsgroup is faster! And provides more complete
> answers, anyway. I enjoy discussions like this.
Thank you very much, Christian. Now I feel less ashamed :D
> There is much else that the OCL spec forgot to specify how it should be
> persisted, including dynamically-generated types (as indicated by the spec)
> such as collection types and tuple types, that are referenced by
> expressions. There is no guidance suggesting how to persist references to
> these transitory types. But, this is an unrelated problem ...
Yeah, but one that affects me as well, I'm afraid. :)
>> On the other hand, languages extending OCL could import such
>> UnlimitedNatural for their own purposes (provided that
>> these reinterpretations are allowed), such as their use in some
>
> I think these reinterpretations should be allowed. OCL, itself,
> reinterprets the UML Infrastructure Library's Integer as a primitive type
> conforming to Real (defined by OCL).
Very neat case in point. I was just trying to be cautious with my words
without giving them much thought. ;)
See you!
Victor Sánchez
|
|
|
Goto Forum:
Current Time: Fri Apr 19 11:32:41 GMT 2024
Powered by FUDForum. Page generated in 0.02311 seconds |
] 
Search
Help
Register
Login
Home
