Issue 15780: OCL 2.2 Unlimited and Infinity (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: OCL supports a '*' value for UnlimitedNatural in order to accommodate the full range of UML multiplicities. UnlimitedNatural conforms to Integer and Real, so that any UnlimitedNatural conversion must perform a run-time check in order to convert '*' to invalid. This conversion cannot be replicated in the reverse direction. Suggest that '*' be aligned with the conventional IEEE math notion of infinity, so that * and -* are valid values for Integer and Real. UnlimitedNatural is then a simple restriction of Integer which is a simple restriction of Real. Resolution: Revised Text: Actions taken: October 25, 2010: received issue Discussion: End of Annotations:===== m: "Willink, Ed" To: "'issues@omg.org'" Subject: OCL 2.2 Unlimited and Infinity Date: Mon, 25 Oct 2010 13:42:00 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi OCL supports a '*' value for UnlimitedNatural in order to accommodate the full range of UML multiplicities. UnlimitedNatural conforms to Integer and Real, so that any UnlimitedNatural conversion must perform a run-time check in order to convert '*' to invalid. This conversion cannot be replicated in the reverse direction. Suggest that '*' be aligned with the conventional IEEE math notion of infinity, so that * and -* are valid values for Integer and Real. UnlimitedNatural is then a simple restriction of Integer which is a simple restriction of Real. Regards Ed Willink 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 From: "Willink, Ed" To: ocl2-rtf@omg.org Subject: RE: issue 15780 -- Unlimited and Infinity Date: Tue, 9 Nov 2010 13:23:27 -0000 X-Mailer: Internet Mail Service (5.5.2657.72) Hi If * is allowed as an integer, then in 8.3.7 CollectionRange, there should be a well-formedness rule prohibiting an infinite collection such as "0..*" to ensure that OCL's guarantee of executability for collections is preserved. Regards Ed Willink -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 25 October 2010 18:08 To: issues@omg.org; ocl2-rtf@omg.org Subject: issue 15780 -- OCL 2 RTF issue From: "Willink, Ed" To: "'issues@omg.org'" Subject: OCL 2.2 Unlimited and Infinity Date: Mon, 25 Oct 2010 13:42:00 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi OCL supports a '*' value for UnlimitedNatural in order to accommodate the full range of UML multiplicities. UnlimitedNatural conforms to Integer and Real, so that any UnlimitedNatural conversion must perform a run-time check in order to convert '*' to invalid. This conversion cannot be replicated in the reverse direction. Suggest that '*' be aligned with the conventional IEEE math notion of infinity, so that * and -* are valid values for Integer and Real. UnlimitedNatural is then a simple restriction of Integer which is a simple restriction of Real. Regards Ed Willink Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org 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 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANhUrU3Unw4R/2dsb2JhbAClKXfFMYVxBJIC Date: Tue, 19 Apr 2011 10:25:17 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 To: "ocl2-rtf@omg.org" Subject: RE: Issue 15780: OCL 2.2 Unlimited and Infinity Hi As a further corrolary of avoiding the anomally that UnlimitedNatural conforms to Integer but that not all UnlimitedNaturals have an Integer representation: If '*' is treated at +infinity for Real and Integer as well as UnlimitedNatural, what use is UnlimitedNatural? UnlimitedNatural can be eliminated and replaced by a lower bound constraint on multiplicity lower bounds. Regards X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=f8pxWoCM c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=rk6kYgpkzp0A:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=Kx6ptYt8N3gA:10 a=yMhMjlubAAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=kWytO6vVTQZOUEltNyQA:9 a=LSf6fgMDIKmL4jq6:21 a=flyQQzuYgqBUawbh:21 a=FU-zk-S00G0tnEa8:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=WP4_USCxRkkA:10 Date: Wed, 24 Jul 2013 11:53:11 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "ocl2-rtf@omg.org" Subject: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to invalid. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. 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. a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: >Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of .minus unbounded. to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 23 July 2013 23:04 To: ocl2-rtf@omg.org Subject: Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = .Boolean." be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -14 X-BigFish: VS-14(z21cRzbb2dI98dIc89bh601Ic85dh1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h17326ah8275dh18c673h1de097h1de096h1954cbh18602eh84d07h8275bhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: Ed Willink , "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHg Date: Wed, 24 Jul 2013 13:53:36 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org B2 seems the obvious choice to me. >Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types. These types are not .unrelated., they are just not subtypes of one another. >it seems a bit odd to have plus-infinity without minus-infinity What .*. means is that a collection has unbounded size. A collection always has a non-negative size. >an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 11:53 To: ocl2-rtf@omg.org Subject: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to invalid. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. 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. a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: >Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of .minus unbounded. to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve From: Ed Willink [mailto:ed@willink.me.uk] Sent: 23 July 2013 23:04 To: ocl2-rtf@omg.org Subject: Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = .Boolean." be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=1+ZEHI+sXpQDqucsWgCCH+1uJlE5lUeexvzVXEkML5c=; b=bCMsRGAuu5Uhn5XwARpUrOH8iTXNu9aG4CXfiaM65vQUOtwb3TtymmKR4YHRp4GleB N/UYhNfzblN4w+tA1G2P5lMnjqWDt7HQF20Q7OqIXdqet+SgZB82x1VlMJlUJLjRyjXK IjjsTe++x6DpskAsdT8cuzcgYuNb1VoLshJrkpVKpx9Bo8WijRscCicIRzWXp1TShxnk 4XrwWLhRUhLKGHowXx3Fl5Bu4UWMLQCh5UJ7Xs9IHeSgwi0UNrUnRx0SmMMi7xysaEGx woVVaDarATvFeDpsvqABuSScXeezlciCSBNO1ieBuGLeEfe1cppcm88r3DH3YgagTMco uwcQ== X-Received: by 10.14.177.8 with SMTP id c8mr37327706eem.93.1374676134134; Wed, 24 Jul 2013 07:28:54 -0700 (PDT) Sender: Adolfo Sanchez Barbudo Date: Wed, 24 Jul 2013 15:28:52 +0100 From: Adolfo Sáhez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: Steve Cook CC: Ed Willink , "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Gm-Message-State: ALoCoQk1Vat+ryF6UQD5CLrzGKHMeC8BXeMbXxmjDlAVeu4tXy8AqOVLsH6gVfufb/VBUlf+kXNB X-Virus-Scanned: amavisd-new at omg.org Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not .unrelated., they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What .*. means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: >Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of .minus unbounded. to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = .Boolean." be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=33RrB3tuMlcA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=NCPkTe1-gb2PPKgSmdUA:9 a=MwE-99AbhbKKdDcc:21 a=GvaafX5Z1hApBlC-:21 a=pILNOxqGKmIA:10 a=WP4_USCxRkkA:10 Date: Wed, 24 Jul 2013 15:53:35 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org HI Indeed more than 5 minutes thought. I'll see what happens to Eclipse OCL if we remove the subtyping relationship. If only a few eccentric unit tests need revision, I'll revise this resolution for Ballot 3. If the consequences are nastier we'll have to wait till we're more confident of a better direction than the status quo. It may just be necessary to carefully identify all the scenarios in which we need to specify an unrelated type conversion between Integer and UnlimitedNatural. Either way this resolution is withdrawn from Ballot 1. Regards Ed Willink On 24/07/2013 15:28, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not .unrelated., they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What .*. means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: >Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of .minus unbounded. to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = .Boolean." be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 X-IronPort-AV: E=Sophos;i="4.89,736,1367967600"; d="scan'208";a="63889565" From: AKEHURST David To: "ocl2-rtf@omg.org" Date: Wed, 24 Jul 2013 16:08:02 +0100 Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: Ac6Iel+QGcBID/RiR6y3B56XhWraqgABK41g Accept-Language: en-US, en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB X-SpamInfo: helo-dns, X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6OF8EuU017568 > we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: > B2 seems the obvious choice to me. > >>Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. > > Lots of programming languages do it between numeric types.These types > are not "unrelated", they are just not subtypes of one another. > >>it seems a bit odd to have plus-infinity without minus-infinity > > What "*" means is that a collection has unbounded size.A collection > always has a non-negative size. > >>an early deprecation would avoid one source of user confusion > > Deprecating UnlimitedNatural in UML is just not going to happen, and > taking OCL in a direction that widens the gap with UML is a poor strategy. > > -- Steve > > *From:*Ed Willink [mailto:ed@willink.me.uk] > *Sent:* 24 July 2013 11:53 > *To:* ocl2-rtf@omg.org > *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > > Hi > > It is certainly not the intention to require integer implementation > using floating point; just to require that the Integer and Real (as well > UnlimitedNatural) have a special larger-than-anything-else (infinity) > value. How implementations choose to implement that special value is not > defined by the OCL specification. > > Currently implementations are required to check that every implicit > conversion from UnlimitedNatural to Integer converts * to /invalid/. I > suspect that many implementations are broken here already and so allow > the implementation convenience of -1 to become visible; we certainly had > to fix problems with Eclipse OCL here. > > Whether there is a minus-infinity is possibly a separate issue, but it > seems a bit odd to have plus-infinity without minus-infinity. > > I'm not clear what the relevance of your comment that Integers are not > closed under division is. OCL currently specifies the type conversion to > Real to guarantee a result (except divide by 0). There is a separate div > operator if you want the limited precision of an Integer result. > > Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines > +,*,/, etc (no -). Conversion to Integer occurs when the capabilities of > UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. > > We have two main choices to resolve the contradictory subtyping claims > for UnlimitedNatural. See 11.4.1, 11.4.2. > > /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./ > > a) Make UnlimitedNatural a full subtype of Integer by introducing > plus-infinity to Integer and Real (the current resolution proposal) > > b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. > - require positive integers to be parsed as Integer rather than > UnlimitedNatural > - require use of toInteger() to convert non-unlimited UnlimitedNatural > to Integer > - introduce and require use of toUnlimitedNatural() to convert > non-negative Integer to UnlimitedNatural > - retract all UnlimitedNatural arithmetic capabilities > > b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. > - allow implicit conversion of non-unlimited UnlimitedNatural to Integer > - allow implicit conversion of non-negative Integer to UnlimitedNatural > > IMHO breaking the subtype contract will cause problems for programs that > currently exploit the free conversion since OCL currently has numbers > that grow in range/precision as required. Providing free conversion > between unrelated types is not something that I would like to try to > justify to the academics. > > The current specified arithmetic capabilities for UnlimitedNatural allow > * to participate in comparisons and max/min operations without the > special casing that UML specification engages in to work around the > inadequacies of implementations that execute with -1 for *. > (Implementations are already broken.) > > Introducing *-is-infinity to Integer would allow UnlimitedNatural to be > eliminated altogether. UML need only specify that the lowerBound is > finite and non-negative. (Actual elimination of UnlimitedNatural is > probably out of the question for compatibility reasons, but an early > deprecation would avoid one source of user confusion.) > > Regards > > Ed Willink > > On 24/07/2013 10:46, Steve Cook wrote: > > >Can the issue be that UnlimitedNatural is not really a subtype of Integer? > > Absolutely. These numeric types are not subtypes of each other > under any useful algebraic notion of substitutability. Integers are > not closed under division, as Reals are. UnlimitedNaturals are only > ever subject to comparison, and do not engage in arithmetic with > each other or with other numbers. There is no value and only > confusion in pretending that subtyping is going on. In practice, > Integer maps to whatever your computer counts in its words and adds > up in its CPU, and UnlimitedNatural is mapped to the same thing with > a special value (usually -1) to represent *. > > There may be coercions, even implicit ones, but that is not the same > thing. > > I see no value in introducing the idea of "minus unbounded" to OCL. > Requiring all of these types to be implemented as floating point > numbers, as is implied by the proposed resolution to 15780, will > presumably invalidate all existing implementations of UML and OCL, > and is a poor idea. > > -- Steve > > *From:*Ed Willink [mailto:ed@willink.me.uk] > *Sent:* 23 July 2013 23:04 > *To:* ocl2-rtf@omg.org > *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 > > On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: > > Hi Ed, > > Some feedback about your document. > > Issue 15009 : > Shorthand is used along OCL/QVT rather than shortform. > > Fixed in Preview 2 > > > Since the new subsection is related to object navigation, I'm > wondering if section 7.6 is more suitable for it. > > The idea was to get it in before navigation. Also one of the PAS > issues complians about no ./-> in 7.5.8. > > > > Issue 15780 : > 1. What does symbolic analysis mean? > > Analyzing an expression without evaluating it. > > > 2. IEEE 754 alignment sounds like a UML2 misalignment. Note > that UnlimitedNatural not only accommodates the need for an > unlimited upper bound multiplicity, but also the lower bound > value is constrained by not permitting the unbounded (or > infinite) one by using the Integer type. With this proposal OCL > is changing the semantics of Integer (and Real) given by UML. > Can the issue be that UnlimitedNatural is not really a subtype > of Integer (Looking at the varied Real-Integer-UnlimitedNatural > operations, it looks like there is some Liskov substitution > principle violation smell)?. Are we again dealing with a > conformance related issue ?. > > I don't understand your point. > > There is no problem with UnlimitedNatural having fewer values (no > negatives). The problem is an extra positive value. > > > > Issue 18437: > OclAny defines post conditions for their library operations. > I see no point why this should be different for the new > operations on OclVoid and OclInvalid > > The OclAny postconditions had somethjing to say. > I dont'tsee the point in padding out " Evaluates to true." with > post: result = true. > > > Issue 18464: > OCL is mainly founded on (first-order) predicate logic and > set theory. Could you provide a reference supporting your > affirmation about why the algorithm is correct and the text > incorrect ?. > > I don't understand your point. > This is a fix for inconsistency in the wording, not an algorithm change. > > > > Issue 6600: > I must be missing/misunderstanding something. I see a table > of contents in the beginning. What's wrong with OCL 2.3 ? > > An Index is not the TOC. It is generally at the end. There is no > index in OCL 2.3.1. > > > > Issue 6879-6882: > We could argue about if shorthands are convenient/readable or > not, but rationale like "but avoids introducing a "?" syntax > irregularity" doesn't seem convincing for discarding the syntax > enhancement. What does syntax irregularity mean ?. > In general, I find aligning OCL-QVT syntax as a good idea. So > unless you identify real problems of adopting this alignment, I > don't see the point of closing these issues as no change. > Borrowing your comment to discard other proposals: "The > 'problems' have not prevented QVT tool being built" > > Nobody has demonstrated that QVTo has no limitations over the full > OCL syntax in particular UML qualifiers. > I'm not comfortable with the QVTo syntax extensions and the drift to > be a non-Java Java.. > I don't see that usage by QVTo requires adoption by OCL. > I figure that if Mariano had really wanted these changes he would > have put them to a ballot for OCL 2.2. > > > Issue 6894: > Better solution = no change ?? > > An additional library routine is not a change to the OCL language. > > > Issue 7466: > Should not every "self.condition.type.oclIsKindOf(Primitive) > and self.condition.type.name = 'Boolean'" be changed by > "self.condition.type = Boolean" ? > I guess this could be deferred until specification > generation is done. > > Yes. That is why half the issues cannot be addressed very profitably > at present. We still have only visual OCL checking. > > > > Issue 14985: > Resolution keyword missing, so summary and resolution is > mixed in the summary section. > > No. The summary is what the original submitter wrote. I often write > solutions in the submissions. > The missing Resolution paragraph will be added in Preview 2. > > Regards > > Ed Willink > > > > Regards, > Adolfo. > -- > On 22/07/2013 07:23, Ed Willink wrote: > > > Hi > > Attached: Preview 1 of the Issues resolved in Ballot 1. > > The one week preview lasts from now until voting starts on > 29th July. > > The two week voting period lasts from 29th July to 11th August. > > More details may be found in the preamble to the attached. > > Regards > > Ed Willink > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: > 07/22/13 > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: > 07/23/13 > X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC104.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -14 X-BigFish: VS-14(z21cRzbb2dI98dIc89bh542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah8275dh1de097h1de096h18602eh84d07h8275bhz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: AKEHURST David , "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0Ag Date: Wed, 24 Jul 2013 15:39:23 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6OFeJPm028149 >a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) > we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: > B2 seems the obvious choice to me. > >>Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. > > Lots of programming languages do it between numeric types.These types > are not "unrelated", they are just not subtypes of one another. > >>it seems a bit odd to have plus-infinity without minus-infinity > > What "*" means is that a collection has unbounded size.A collection > always has a non-negative size. > >>an early deprecation would avoid one source of user confusion > > Deprecating UnlimitedNatural in UML is just not going to happen, and > taking OCL in a direction that widens the gap with UML is a poor strategy. > > -- Steve > > *From:*Ed Willink [mailto:ed@willink.me.uk] > *Sent:* 24 July 2013 11:53 > *To:* ocl2-rtf@omg.org > *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > > Hi > > It is certainly not the intention to require integer implementation > using floating point; just to require that the Integer and Real (as > well > UnlimitedNatural) have a special larger-than-anything-else (infinity) > value. How implementations choose to implement that special value is > not defined by the OCL specification. > > Currently implementations are required to check that every implicit > conversion from UnlimitedNatural to Integer converts * to /invalid/. I > suspect that many implementations are broken here already and so allow > the implementation convenience of -1 to become visible; we certainly > had to fix problems with Eclipse OCL here. > > Whether there is a minus-infinity is possibly a separate issue, but it > seems a bit odd to have plus-infinity without minus-infinity. > > I'm not clear what the relevance of your comment that Integers are not > closed under division is. OCL currently specifies the type conversion > to Real to guarantee a result (except divide by 0). There is a > separate div operator if you want the limited precision of an Integer result. > > Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines > +,*,/, etc (no -). Conversion to Integer occurs when the capabilities > +of > UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. > > We have two main choices to resolve the contradictory subtyping claims > for UnlimitedNatural. See 11.4.1, 11.4.2. > > /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./ > > a) Make UnlimitedNatural a full subtype of Integer by introducing > plus-infinity to Integer and Real (the current resolution proposal) > > b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. > - require positive integers to be parsed as Integer rather than > UnlimitedNatural > - require use of toInteger() to convert non-unlimited UnlimitedNatural > to Integer > - introduce and require use of toUnlimitedNatural() to convert > non-negative Integer to UnlimitedNatural > - retract all UnlimitedNatural arithmetic capabilities > > b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. > - allow implicit conversion of non-unlimited UnlimitedNatural to > Integer > - allow implicit conversion of non-negative Integer to > UnlimitedNatural > > IMHO breaking the subtype contract will cause problems for programs > that currently exploit the free conversion since OCL currently has > numbers that grow in range/precision as required. Providing free > conversion between unrelated types is not something that I would like > to try to justify to the academics. > > The current specified arithmetic capabilities for UnlimitedNatural > allow > * to participate in comparisons and max/min operations without the > special casing that UML specification engages in to work around the > inadequacies of implementations that execute with -1 for *. > (Implementations are already broken.) > > Introducing *-is-infinity to Integer would allow UnlimitedNatural to > be eliminated altogether. UML need only specify that the lowerBound is > finite and non-negative. (Actual elimination of UnlimitedNatural is > probably out of the question for compatibility reasons, but an early > deprecation would avoid one source of user confusion.) > > Regards > > Ed Willink > > On 24/07/2013 10:46, Steve Cook wrote: > > >Can the issue be that UnlimitedNatural is not really a subtype of Integer? > > Absolutely. These numeric types are not subtypes of each other > under any useful algebraic notion of substitutability. Integers are > not closed under division, as Reals are. UnlimitedNaturals are only > ever subject to comparison, and do not engage in arithmetic with > each other or with other numbers. There is no value and only > confusion in pretending that subtyping is going on. In practice, > Integer maps to whatever your computer counts in its words and adds > up in its CPU, and UnlimitedNatural is mapped to the same thing with > a special value (usually -1) to represent *. > > There may be coercions, even implicit ones, but that is not the same > thing. > > I see no value in introducing the idea of "minus unbounded" to OCL. > Requiring all of these types to be implemented as floating point > numbers, as is implied by the proposed resolution to 15780, will > presumably invalidate all existing implementations of UML and OCL, > and is a poor idea. > > -- Steve > > *From:*Ed Willink [mailto:ed@willink.me.uk] > *Sent:* 23 July 2013 23:04 > *To:* ocl2-rtf@omg.org > *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 > > On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: > > Hi Ed, > > Some feedback about your document. > > Issue 15009 : > Shorthand is used along OCL/QVT rather than shortform. > > Fixed in Preview 2 > > > Since the new subsection is related to object navigation, I'm > wondering if section 7.6 is more suitable for it. > > The idea was to get it in before navigation. Also one of the PAS > issues complians about no ./-> in 7.5.8. > > > > Issue 15780 : > 1. What does symbolic analysis mean? > > Analyzing an expression without evaluating it. > > > 2. IEEE 754 alignment sounds like a UML2 misalignment. Note > that UnlimitedNatural not only accommodates the need for an > unlimited upper bound multiplicity, but also the lower bound > value is constrained by not permitting the unbounded (or > infinite) one by using the Integer type. With this proposal OCL > is changing the semantics of Integer (and Real) given by UML. > Can the issue be that UnlimitedNatural is not really a subtype > of Integer (Looking at the varied Real-Integer-UnlimitedNatural > operations, it looks like there is some Liskov substitution > principle violation smell)?. Are we again dealing with a > conformance related issue ?. > > I don't understand your point. > > There is no problem with UnlimitedNatural having fewer values (no > negatives). The problem is an extra positive value. > > > > Issue 18437: > OclAny defines post conditions for their library operations. > I see no point why this should be different for the new > operations on OclVoid and OclInvalid > > The OclAny postconditions had somethjing to say. > I dont'tsee the point in padding out " Evaluates to true." with > post: result = true. > > > Issue 18464: > OCL is mainly founded on (first-order) predicate logic and > set theory. Could you provide a reference supporting your > affirmation about why the algorithm is correct and the text > incorrect ?. > > I don't understand your point. > This is a fix for inconsistency in the wording, not an algorithm change. > > > > Issue 6600: > I must be missing/misunderstanding something. I see a table > of contents in the beginning. What's wrong with OCL 2.3 ? > > An Index is not the TOC. It is generally at the end. There is no > index in OCL 2.3.1. > > > > Issue 6879-6882: > We could argue about if shorthands are convenient/readable or > not, but rationale like "but avoids introducing a "?" syntax > irregularity" doesn't seem convincing for discarding the syntax > enhancement. What does syntax irregularity mean ?. > In general, I find aligning OCL-QVT syntax as a good idea. So > unless you identify real problems of adopting this alignment, I > don't see the point of closing these issues as no change. > Borrowing your comment to discard other proposals: "The > 'problems' have not prevented QVT tool being built" > > Nobody has demonstrated that QVTo has no limitations over the full > OCL syntax in particular UML qualifiers. > I'm not comfortable with the QVTo syntax extensions and the drift to > be a non-Java Java.. > I don't see that usage by QVTo requires adoption by OCL. > I figure that if Mariano had really wanted these changes he would > have put them to a ballot for OCL 2.2. > > > Issue 6894: > Better solution = no change ?? > > An additional library routine is not a change to the OCL language. > > > Issue 7466: > Should not every "self.condition.type.oclIsKindOf(Primitive) > and self.condition.type.name = 'Boolean'" be changed by > "self.condition.type = Boolean" ? > I guess this could be deferred until specification > generation is done. > > Yes. That is why half the issues cannot be addressed very profitably > at present. We still have only visual OCL checking. > > > > Issue 14985: > Resolution keyword missing, so summary and resolution is > mixed in the summary section. > > No. The summary is what the original submitter wrote. I often write > solutions in the submissions. > The missing Resolution paragraph will be added in Preview 2. > > Regards > > Ed Willink > > > > Regards, > Adolfo. > -- > On 22/07/2013 07:23, Ed Willink wrote: > > > Hi > > Attached: Preview 1 of the Issues resolved in Ballot 1. > > The one week preview lasts from now until voting starts on > 29th July. > > The two week voting period lasts from 29th July to 11th August. > > More details may be found in the preamble to the attached. > > Regards > > Ed Willink > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: > 07/22/13 > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: > 07/23/13 > X-IronPort-AV: E=Sophos;i="4.89,736,1367967600"; d="scan'208";a="63893432" From: AKEHURST David To: "ocl2-rtf@omg.org" Date: Wed, 24 Jul 2013 16:53:27 +0100 Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljA= Accept-Language: en-US, en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB X-SpamInfo: helo-dns, X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6OFrbKC000539 http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" > The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) >a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) > we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: > B2 seems the obvious choice to me. > >>Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. > > Lots of programming languages do it between numeric types.These types > are not "unrelated", they are just not subtypes of one another. > >>it seems a bit odd to have plus-infinity without minus-infinity > > What "*" means is that a collection has unbounded size.A collection > always has a non-negative size. > >>an early deprecation would avoid one source of user confusion > > Deprecating UnlimitedNatural in UML is just not going to happen, and > taking OCL in a direction that widens the gap with UML is a poor strategy. > > -- Steve > > *From:*Ed Willink [mailto:ed@willink.me.uk] > *Sent:* 24 July 2013 11:53 > *To:* ocl2-rtf@omg.org > *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > > Hi > > It is certainly not the intention to require integer implementation > using floating point; just to require that the Integer and Real (as > well > UnlimitedNatural) have a special larger-than-anything-else (infinity) > value. How implementations choose to implement that special value is > not defined by the OCL specification. > > Currently implementations are required to check that every implicit > conversion from UnlimitedNatural to Integer converts * to /invalid/. I > suspect that many implementations are broken here already and so allow > the implementation convenience of -1 to become visible; we certainly > had to fix problems with Eclipse OCL here. > > Whether there is a minus-infinity is possibly a separate issue, but it > seems a bit odd to have plus-infinity without minus-infinity. > > I'm not clear what the relevance of your comment that Integers are not > closed under division is. OCL currently specifies the type conversion > to Real to guarantee a result (except divide by 0). There is a > separate div operator if you want the limited precision of an Integer result. > > Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines > +,*,/, etc (no -). Conversion to Integer occurs when the capabilities > +of > UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. > > We have two main choices to resolve the contradictory subtyping claims > for UnlimitedNatural. See 11.4.1, 11.4.2. > > /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./ > > a) Make UnlimitedNatural a full subtype of Integer by introducing > plus-infinity to Integer and Real (the current resolution proposal) > > b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. > - require positive integers to be parsed as Integer rather than > UnlimitedNatural > - require use of toInteger() to convert non-unlimited UnlimitedNatural > to Integer > - introduce and require use of toUnlimitedNatural() to convert > non-negative Integer to UnlimitedNatural > - retract all UnlimitedNatural arithmetic capabilities > > b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. > - allow implicit conversion of non-unlimited UnlimitedNatural to > Integer > - allow implicit conversion of non-negative Integer to > UnlimitedNatural > > IMHO breaking the subtype contract will cause problems for programs > that currently exploit the free conversion since OCL currently has > numbers that grow in range/precision as required. Providing free > conversion between unrelated types is not something that I would like > to try to justify to the academics. > > The current specified arithmetic capabilities for UnlimitedNatural > allow > * to participate in comparisons and max/min operations without the > special casing that UML specification engages in to work around the > inadequacies of implementations that execute with -1 for *. > (Implementations are already broken.) > > Introducing *-is-infinity to Integer would allow UnlimitedNatural to > be eliminated altogether. UML need only specify that the lowerBound is > finite and non-negative. (Actual elimination of UnlimitedNatural is > probably out of the question for compatibility reasons, but an early > deprecation would avoid one source of user confusion.) > > Regards > > Ed Willink > > On 24/07/2013 10:46, Steve Cook wrote: > > >Can the issue be that UnlimitedNatural is not really a subtype of Integer? > > Absolutely. These numeric types are not subtypes of each other > under any useful algebraic notion of substitutability. Integers are > not closed under division, as Reals are. UnlimitedNaturals are only > ever subject to comparison, and do not engage in arithmetic with > each other or with other numbers. There is no value and only > confusion in pretending that subtyping is going on. In practice, > Integer maps to whatever your computer counts in its words and adds > up in its CPU, and UnlimitedNatural is mapped to the same thing with > a special value (usually -1) to represent *. > > There may be coercions, even implicit ones, but that is not the same > thing. > > I see no value in introducing the idea of "minus unbounded" to OCL. > Requiring all of these types to be implemented as floating point > numbers, as is implied by the proposed resolution to 15780, will > presumably invalidate all existing implementations of UML and OCL, > and is a poor idea. > > -- Steve > > *From:*Ed Willink [mailto:ed@willink.me.uk] > *Sent:* 23 July 2013 23:04 > *To:* ocl2-rtf@omg.org > *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 > > On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: > > Hi Ed, > > Some feedback about your document. > > Issue 15009 : > Shorthand is used along OCL/QVT rather than shortform. > > Fixed in Preview 2 > > > Since the new subsection is related to object navigation, I'm > wondering if section 7.6 is more suitable for it. > > The idea was to get it in before navigation. Also one of the PAS > issues complians about no ./-> in 7.5.8. > > > > Issue 15780 : > 1. What does symbolic analysis mean? > > Analyzing an expression without evaluating it. > > > 2. IEEE 754 alignment sounds like a UML2 misalignment. Note > that UnlimitedNatural not only accommodates the need for an > unlimited upper bound multiplicity, but also the lower bound > value is constrained by not permitting the unbounded (or > infinite) one by using the Integer type. With this proposal OCL > is changing the semantics of Integer (and Real) given by UML. > Can the issue be that UnlimitedNatural is not really a subtype > of Integer (Looking at the varied Real-Integer-UnlimitedNatural > operations, it looks like there is some Liskov substitution > principle violation smell)?. Are we again dealing with a > conformance related issue ?. > > I don't understand your point. > > There is no problem with UnlimitedNatural having fewer values (no > negatives). The problem is an extra positive value. > > > > Issue 18437: > OclAny defines post conditions for their library operations. > I see no point why this should be different for the new > operations on OclVoid and OclInvalid > > The OclAny postconditions had somethjing to say. > I dont'tsee the point in padding out " Evaluates to true." with > post: result = true. > > > Issue 18464: > OCL is mainly founded on (first-order) predicate logic and > set theory. Could you provide a reference supporting your > affirmation about why the algorithm is correct and the text > incorrect ?. > > I don't understand your point. > This is a fix for inconsistency in the wording, not an algorithm change. > > > > Issue 6600: > I must be missing/misunderstanding something. I see a table > of contents in the beginning. What's wrong with OCL 2.3 ? > > An Index is not the TOC. It is generally at the end. There is no > index in OCL 2.3.1. > > > > Issue 6879-6882: > We could argue about if shorthands are convenient/readable or > not, but rationale like "but avoids introducing a "?" syntax > irregularity" doesn't seem convincing for discarding the syntax > enhancement. What does syntax irregularity mean ?. > In general, I find aligning OCL-QVT syntax as a good idea. So > unless you identify real problems of adopting this alignment, I > don't see the point of closing these issues as no change. > Borrowing your comment to discard other proposals: "The > 'problems' have not prevented QVT tool being built" > > Nobody has demonstrated that QVTo has no limitations over the full > OCL syntax in particular UML qualifiers. > I'm not comfortable with the QVTo syntax extensions and the drift to > be a non-Java Java.. > I don't see that usage by QVTo requires adoption by OCL. > I figure that if Mariano had really wanted these changes he would > have put them to a ballot for OCL 2.2. > > > Issue 6894: > Better solution = no change ?? > > An additional library routine is not a change to the OCL language. > > > Issue 7466: > Should not every "self.condition.type.oclIsKindOf(Primitive) > and self.condition.type.name = 'Boolean'" be changed by > "self.condition.type = Boolean" ? > I guess this could be deferred until specification > generation is done. > > Yes. That is why half the issues cannot be addressed very profitably > at present. We still have only visual OCL checking. > > > > Issue 14985: > Resolution keyword missing, so summary and resolution is > mixed in the summary section. > > No. The summary is what the original submitter wrote. I often write > solutions in the submissions. > The missing Resolution paragraph will be added in Preview 2. > > Regards > > Ed Willink > > > > Regards, > Adolfo. > -- > On 22/07/2013 07:23, Ed Willink wrote: > > > Hi > > Attached: Preview 1 of the Issues resolved in Ballot 1. > > The one week preview lasts from now until voting starts on > 29th July. > > The two week voting period lasts from 29th July to 11th August. > > More details may be found in the preamble to the attached. > > Regards > > Ed Willink > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: > 07/22/13 > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: > 07/23/13 > X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=33RrB3tuMlcA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=jb1_pgqOAAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=zQ4kh4N2OzcmdWqRHEkA:9 a=MAJ9thhJafCzYKB4:21 a=Q9QJhjXUkE_cVRn2:21 a=wPNLvfGTeEIA:10 a=WP4_USCxRkkA:10 Date: Wed, 24 Jul 2013 17:48:09 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi Steve I wish I hadn't mentioned IEEE 754, it seems to have confused you despite my added comment that precision was unconstrained by IEEE 754. The only aspect of IEEE 754 that I was proposing to exploit was the rules for {Number,Zero,+Infinity,-Infinity,Invalid} x {Number,Zero,+Infinity,-Infinity,Invalid} => {Number,Zero,+Infinity,-Infinity,Invalid}. OCL Integers are fully substitutable with respect to Real since Real is specified to be unbounded. You are confusing typical implementation approaches with the specified behaviour. Any OCL implementation that is limited to 32/64 bit integers or 32/64/128 bit floats is buggy. IMHO adding +/-Infinity to OCL Integer and Real is almost no change. It just cleans up a deficiency with respect to standard arithmetic capabilities and eliminates the UnlimitedNatural subtyping problem at the same time. If anyone tries to implement an OCL Maths library with log() etc, they will of course look to IEEE-754 for guidance and will find the lack of support for +/- infinity in OCL a major pain. Regards Ed Willink On 24/07/2013 16:39, Steve Cook wrote: a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities +of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: >Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=JcpmC7oQgQOHHiYJsDOLeIJKTdYMyHvpNmZgAsaRy9c=; b=YkSTJOT8u59f0cPgN9HRe5W+SFhcXirVMOJkHUnwN5f0BfZj5Ir6qWCTGJ7x6+K/nL MLhOcyo0IhWR1F1XUwuwXIjEMZujpapZyexz8fPO/vTebHrE/brnTBolI0q9vIClJ6ct DpZy5MTbvAp+GnHSqmeThLrGvqHqdFfD8hAmustwYmm0PGUWnWHVITo7BacZaxpXwibi EWAOpxbIMHBM380t01sbQjgO44v8F9JZdJtQ6Ql2PWw2oh/eXXvkSIf8P91ZnL6JlwrH AYraclbTWsiELqpq8Pmp5lpL9vgSlyLa8e01nC0cRZYNB04ZzXMACn5B0QxJmgfm8XF0 nnlQ== X-Received: by 10.204.186.8 with SMTP id cq8mr5458799bkb.129.1374685128970; Wed, 24 Jul 2013 09:58:48 -0700 (PDT) Cc: "ocl2-rtf@omg.org" X-Mailer: iPad Mail (9B206) From: Bran Selic Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Date: Wed, 24 Jul 2013 18:58:49 +0200 To: AKEHURST David X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6OGwr0A017126 Content-Transfer-Encoding: 8bit Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: > http://en.wikipedia.org/wiki/Integer > > "The set of integers is a subset of the real numbers" > > >> The desire for subtyping between these types is misplaced. It is unnecessary. > > that depends on your perspective, context, where your are coming from. > I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, > > My point was that I believe that OCL has its roots in formal maths, not in programming languages. > > > The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying > (platform specific) architecture of the processors we use. > I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) > why should they care about restrictions on number representation caused by platform specific issues? > The "programming language practical solutions" are platform specific issues are they not? > > > Personally I really like using the OCL Integer and Real with the subtype/subset relationship. > > > > -----Original Message----- > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: 24 July 2013 16:39 > To: AKEHURST David; ocl2-rtf@omg.org > Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) > >> a subtype (subset) > > Subtype does not mean subset. It means algebraically substitutable. > > There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. > > The desire for subtyping between these types is misplaced. It is unnecessary. > > Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. > > -- Steve > > -----Original Message----- > From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] > Sent: 24 July 2013 16:08 > To: ocl2-rtf@omg.org > Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) > >> we just need to have a look about what programming languages > > not sure that that is a good idea, > > My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. > > perhaps one should look at formal languages/mathematics to determine the solution! > > > -----Original Message----- > From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera > Sent: 24 July 2013 15:29 > To: Steve Cook > Cc: Ed Willink; ocl2-rtf@omg.org > Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) > > Hi Ed, Steve. > > - I don't like A since OCL changes Integer/Real semantics given by UML. > - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. > - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. > > I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded > (*) value). > > As a side note, in java, Integer object is not a subtype of Real one. > > Regards, > Adolfo. > On 24/07/2013 14:53, Steve Cook wrote: >> B2 seems the obvious choice to me. >> >>> Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. >> >> Lots of programming languages do it between numeric types.These types >> are not "unrelated", they are just not subtypes of one another. >> >>> it seems a bit odd to have plus-infinity without minus-infinity >> >> What "*" means is that a collection has unbounded size.A collection >> always has a non-negative size. >> >>> an early deprecation would avoid one source of user confusion >> >> Deprecating UnlimitedNatural in UML is just not going to happen, and >> taking OCL in a direction that widens the gap with UML is a poor strategy. >> >> -- Steve >> >> *From:*Ed Willink [mailto:ed@willink.me.uk] >> *Sent:* 24 July 2013 11:53 >> *To:* ocl2-rtf@omg.org >> *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >> Preview 1) >> >> Hi >> >> It is certainly not the intention to require integer implementation >> using floating point; just to require that the Integer and Real (as >> well >> UnlimitedNatural) have a special larger-than-anything-else (infinity) >> value. How implementations choose to implement that special value is >> not defined by the OCL specification. >> >> Currently implementations are required to check that every implicit >> conversion from UnlimitedNatural to Integer converts * to /invalid/. I >> suspect that many implementations are broken here already and so allow >> the implementation convenience of -1 to become visible; we certainly >> had to fix problems with Eclipse OCL here. >> >> Whether there is a minus-infinity is possibly a separate issue, but it >> seems a bit odd to have plus-infinity without minus-infinity. >> >> I'm not clear what the relevance of your comment that Integers are not >> closed under division is. OCL currently specifies the type conversion >> to Real to guarantee a result (except divide by 0). There is a >> separate div operator if you want the limited precision of an Integer result. >> >> Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines >> +,*,/, etc (no -). Conversion to Integer occurs when the capabilities >> +of >> UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. >> >> We have two main choices to resolve the contradictory subtyping claims >> for UnlimitedNatural. See 11.4.1, 11.4.2. >> >> /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./ >> >> a) Make UnlimitedNatural a full subtype of Integer by introducing >> plus-infinity to Integer and Real (the current resolution proposal) >> >> b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. >> - require positive integers to be parsed as Integer rather than >> UnlimitedNatural >> - require use of toInteger() to convert non-unlimited UnlimitedNatural >> to Integer >> - introduce and require use of toUnlimitedNatural() to convert >> non-negative Integer to UnlimitedNatural >> - retract all UnlimitedNatural arithmetic capabilities >> >> b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. >> - allow implicit conversion of non-unlimited UnlimitedNatural to >> Integer >> - allow implicit conversion of non-negative Integer to >> UnlimitedNatural >> >> IMHO breaking the subtype contract will cause problems for programs >> that currently exploit the free conversion since OCL currently has >> numbers that grow in range/precision as required. Providing free >> conversion between unrelated types is not something that I would like >> to try to justify to the academics. >> >> The current specified arithmetic capabilities for UnlimitedNatural >> allow >> * to participate in comparisons and max/min operations without the >> special casing that UML specification engages in to work around the >> inadequacies of implementations that execute with -1 for *. >> (Implementations are already broken.) >> >> Introducing *-is-infinity to Integer would allow UnlimitedNatural to >> be eliminated altogether. UML need only specify that the lowerBound is >> finite and non-negative. (Actual elimination of UnlimitedNatural is >> probably out of the question for compatibility reasons, but an early >> deprecation would avoid one source of user confusion.) >> >> Regards >> >> Ed Willink >> >> On 24/07/2013 10:46, Steve Cook wrote: >> >>> Can the issue be that UnlimitedNatural is not really a subtype of Integer? >> >> Absolutely. These numeric types are not subtypes of each other >> under any useful algebraic notion of substitutability. Integers are >> not closed under division, as Reals are. UnlimitedNaturals are only >> ever subject to comparison, and do not engage in arithmetic with >> each other or with other numbers. There is no value and only >> confusion in pretending that subtyping is going on. In practice, >> Integer maps to whatever your computer counts in its words and adds >> up in its CPU, and UnlimitedNatural is mapped to the same thing with >> a special value (usually -1) to represent *. >> >> There may be coercions, even implicit ones, but that is not the same >> thing. >> >> I see no value in introducing the idea of "minus unbounded" to OCL. >> Requiring all of these types to be implemented as floating point >> numbers, as is implied by the proposed resolution to 15780, will >> presumably invalidate all existing implementations of UML and OCL, >> and is a poor idea. >> >> -- Steve >> >> *From:*Ed Willink [mailto:ed@willink.me.uk] >> *Sent:* 23 July 2013 23:04 >> *To:* ocl2-rtf@omg.org >> *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 >> >> On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: >> >> Hi Ed, >> >> Some feedback about your document. >> >> Issue 15009 : >> Shorthand is used along OCL/QVT rather than shortform. >> >> Fixed in Preview 2 >> >> >> Since the new subsection is related to object navigation, I'm >> wondering if section 7.6 is more suitable for it. >> >> The idea was to get it in before navigation. Also one of the PAS >> issues complians about no ./-> in 7.5.8. >> >> >> >> Issue 15780 : >> 1. What does symbolic analysis mean? >> >> Analyzing an expression without evaluating it. >> >> >> 2. IEEE 754 alignment sounds like a UML2 misalignment. Note >> that UnlimitedNatural not only accommodates the need for an >> unlimited upper bound multiplicity, but also the lower bound >> value is constrained by not permitting the unbounded (or >> infinite) one by using the Integer type. With this proposal OCL >> is changing the semantics of Integer (and Real) given by UML. >> Can the issue be that UnlimitedNatural is not really a subtype >> of Integer (Looking at the varied Real-Integer-UnlimitedNatural >> operations, it looks like there is some Liskov substitution >> principle violation smell)?. Are we again dealing with a >> conformance related issue ?. >> >> I don't understand your point. >> >> There is no problem with UnlimitedNatural having fewer values (no >> negatives). The problem is an extra positive value. >> >> >> >> Issue 18437: >> OclAny defines post conditions for their library operations. >> I see no point why this should be different for the new >> operations on OclVoid and OclInvalid >> >> The OclAny postconditions had somethjing to say. >> I dont'tsee the point in padding out " Evaluates to true." with >> post: result = true. >> >> >> Issue 18464: >> OCL is mainly founded on (first-order) predicate logic and >> set theory. Could you provide a reference supporting your >> affirmation about why the algorithm is correct and the text >> incorrect ?. >> >> I don't understand your point. >> This is a fix for inconsistency in the wording, not an algorithm change. >> >> >> >> Issue 6600: >> I must be missing/misunderstanding something. I see a table >> of contents in the beginning. What's wrong with OCL 2.3 ? >> >> An Index is not the TOC. It is generally at the end. There is no >> index in OCL 2.3.1. >> >> >> >> Issue 6879-6882: >> We could argue about if shorthands are convenient/readable or >> not, but rationale like "but avoids introducing a "?" syntax >> irregularity" doesn't seem convincing for discarding the syntax >> enhancement. What does syntax irregularity mean ?. >> In general, I find aligning OCL-QVT syntax as a good idea. So >> unless you identify real problems of adopting this alignment, I >> don't see the point of closing these issues as no change. >> Borrowing your comment to discard other proposals: "The >> 'problems' have not prevented QVT tool being built" >> >> Nobody has demonstrated that QVTo has no limitations over the full >> OCL syntax in particular UML qualifiers. >> I'm not comfortable with the QVTo syntax extensions and the drift to >> be a non-Java Java.. >> I don't see that usage by QVTo requires adoption by OCL. >> I figure that if Mariano had really wanted these changes he would >> have put them to a ballot for OCL 2.2. >> >> >> Issue 6894: >> Better solution = no change ?? >> >> An additional library routine is not a change to the OCL language. >> >> >> Issue 7466: >> Should not every "self.condition.type.oclIsKindOf(Primitive) >> and self.condition.type.name = 'Boolean'" be changed by >> "self.condition.type = Boolean" ? >> I guess this could be deferred until specification >> generation is done. >> >> Yes. That is why half the issues cannot be addressed very profitably >> at present. We still have only visual OCL checking. >> >> >> >> Issue 14985: >> Resolution keyword missing, so summary and resolution is >> mixed in the summary section. >> >> No. The summary is what the original submitter wrote. I often write >> solutions in the submissions. >> The missing Resolution paragraph will be added in Preview 2. >> >> Regards >> >> Ed Willink >> >> >> >> Regards, >> Adolfo. >> -- >> On 22/07/2013 07:23, Ed Willink wrote: >> >> >> Hi >> >> Attached: Preview 1 of the Issues resolved in Ballot 1. >> >> The one week preview lasts from now until voting starts on >> 29th July. >> >> The two week voting period lasts from 29th July to 11th August. >> >> More details may be found in the preamble to the attached. >> >> Regards >> >> Ed Willink >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: >> 07/22/13 >> >> >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >> 07/23/13 >> > > X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=574b5qI6gykO5TJEFizlDhjZ9njg3wLeo7b4ilzJlzA=; b=DR7KiI8DOSeXOCEPkuglUN5SROoHpTMzt+HUV9JdVNQ5Bi7DqIIJW/iYzy7MmEkj7C tGjs5jqa1KrblsLvvEckRhWf8E1jjMWXiEwkAKYdPwVWnAXx4N69VDmBCOComCJWKgmo O+3Now6UmKlejA7jwrToEkQBkN2w+tPhXO5JN9HgYpW95Sz/yYWZCi0ALnt8YyXiz8Kz e9m9frnlnwuP2x7myQ1r2yI4j/TfOlpssZ69Hy+XdIfBoiliUoiIVizzBXvz6jXt229s NVORmk8tCovvrQKE966tWuUgZsviw6dB3UN7d0dM7lz806kNyQimSqgkXjaj+5P79jwp GgJQ== X-Received: by 10.14.220.66 with SMTP id n42mr38270745eep.67.1374686957374; Wed, 24 Jul 2013 10:29:17 -0700 (PDT) Sender: Adolfo Sanchez Barbudo Date: Wed, 24 Jul 2013 18:29:15 +0100 From: Adolfo Sáhez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: AKEHURST David CC: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Gm-Message-State: ALoCoQngR7Burnp7Mu6Z5aX8CmRbupOULF0NhYWPZd5GARoBeNW9OcJZo3Vm+dGdJk09+51uKSUl X-Virus-Scanned: amavisd-new at omg.org Hi David, Having integers as a subset of real numbers, doesn't mean that subtype = subset: Having X as the set of possible values of a type A, and having Y as the set of possible values of a type B (a subtype of A), X and Y can be same set. IMO, subtype = subset is incorrect. In this case (Real-Integer types) applies, due to restrictions of possible valid values on the latter. Anyway, my comment was related about how to properly deal with implicit conversions between Integer and UnlimitedNatural. I don't expect to see any implementation-specific decision in the specification. Trade-offs on pragmatic decisions may be considered, though (See, last OCL Stdlib String operations inclusion). The issue that UnlimitedNatural is not a subtype (nor a subset) of Integer is clear, so something needs to be addressed in this respect. I'm still inclined to B2 proposal. Regards, Adolfo. On 24/07/2013 16:53, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities +of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: >Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 X-IronPort-AV: E=Sophos;i="4.89,736,1367967600"; d="scan'208";a="63898749" From: AKEHURST David To: Bran Selic CC: "ocl2-rtf@omg.org" Date: Wed, 24 Jul 2013 18:59:45 +0100 Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: Ac6IjxdRbU08sD36QDiSt703+VumxgACGLNw Accept-Language: en-US, en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB X-SpamInfo: helo-dns, X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r6OHxqqe028882 Content-Transfer-Encoding: 8bit Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: > http://en.wikipedia.org/wiki/Integer > > "The set of integers is a subset of the real numbers" > > >> The desire for subtyping between these types is misplaced. It is unnecessary. > > that depends on your perspective, context, where your are coming from. > I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, > > My point was that I believe that OCL has its roots in formal maths, not in programming languages. > > > The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying > (platform specific) architecture of the processors we use. > I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) > why should they care about restrictions on number representation caused by platform specific issues? > The "programming language practical solutions" are platform specific issues are they not? > > > Personally I really like using the OCL Integer and Real with the subtype/subset relationship. > > > > -----Original Message----- > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: 24 July 2013 16:39 > To: AKEHURST David; ocl2-rtf@omg.org > Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) > >> a subtype (subset) > > Subtype does not mean subset. It means algebraically substitutable. > > There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. > > The desire for subtyping between these types is misplaced. It is unnecessary. > > Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. > > -- Steve > > -----Original Message----- > From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] > Sent: 24 July 2013 16:08 > To: ocl2-rtf@omg.org > Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) > >> we just need to have a look about what programming languages > > not sure that that is a good idea, > > My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. > > perhaps one should look at formal languages/mathematics to determine the solution! > > > -----Original Message----- > From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera > Sent: 24 July 2013 15:29 > To: Steve Cook > Cc: Ed Willink; ocl2-rtf@omg.org > Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) > > Hi Ed, Steve. > > - I don't like A since OCL changes Integer/Real semantics given by UML. > - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. > - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. > > I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded > (*) value). > > As a side note, in java, Integer object is not a subtype of Real one. > > Regards, > Adolfo. > On 24/07/2013 14:53, Steve Cook wrote: >> B2 seems the obvious choice to me. >> >>> Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. >> >> Lots of programming languages do it between numeric types.These types >> are not "unrelated", they are just not subtypes of one another. >> >>> it seems a bit odd to have plus-infinity without minus-infinity >> >> What "*" means is that a collection has unbounded size.A collection >> always has a non-negative size. >> >>> an early deprecation would avoid one source of user confusion >> >> Deprecating UnlimitedNatural in UML is just not going to happen, and >> taking OCL in a direction that widens the gap with UML is a poor strategy. >> >> -- Steve >> >> *From:*Ed Willink [mailto:ed@willink.me.uk] >> *Sent:* 24 July 2013 11:53 >> *To:* ocl2-rtf@omg.org >> *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >> Preview 1) >> >> Hi >> >> It is certainly not the intention to require integer implementation >> using floating point; just to require that the Integer and Real (as >> well >> UnlimitedNatural) have a special larger-than-anything-else (infinity) >> value. How implementations choose to implement that special value is >> not defined by the OCL specification. >> >> Currently implementations are required to check that every implicit >> conversion from UnlimitedNatural to Integer converts * to /invalid/. I >> suspect that many implementations are broken here already and so allow >> the implementation convenience of -1 to become visible; we certainly >> had to fix problems with Eclipse OCL here. >> >> Whether there is a minus-infinity is possibly a separate issue, but it >> seems a bit odd to have plus-infinity without minus-infinity. >> >> I'm not clear what the relevance of your comment that Integers are not >> closed under division is. OCL currently specifies the type conversion >> to Real to guarantee a result (except divide by 0). There is a >> separate div operator if you want the limited precision of an Integer result. >> >> Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines >> +,*,/, etc (no -). Conversion to Integer occurs when the capabilities >> +of >> UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. >> >> We have two main choices to resolve the contradictory subtyping claims >> for UnlimitedNatural. See 11.4.1, 11.4.2. >> >> /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./ >> >> a) Make UnlimitedNatural a full subtype of Integer by introducing >> plus-infinity to Integer and Real (the current resolution proposal) >> >> b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. >> - require positive integers to be parsed as Integer rather than >> UnlimitedNatural >> - require use of toInteger() to convert non-unlimited UnlimitedNatural >> to Integer >> - introduce and require use of toUnlimitedNatural() to convert >> non-negative Integer to UnlimitedNatural >> - retract all UnlimitedNatural arithmetic capabilities >> >> b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. >> - allow implicit conversion of non-unlimited UnlimitedNatural to >> Integer >> - allow implicit conversion of non-negative Integer to >> UnlimitedNatural >> >> IMHO breaking the subtype contract will cause problems for programs >> that currently exploit the free conversion since OCL currently has >> numbers that grow in range/precision as required. Providing free >> conversion between unrelated types is not something that I would like >> to try to justify to the academics. >> >> The current specified arithmetic capabilities for UnlimitedNatural >> allow >> * to participate in comparisons and max/min operations without the >> special casing that UML specification engages in to work around the >> inadequacies of implementations that execute with -1 for *. >> (Implementations are already broken.) >> >> Introducing *-is-infinity to Integer would allow UnlimitedNatural to >> be eliminated altogether. UML need only specify that the lowerBound is >> finite and non-negative. (Actual elimination of UnlimitedNatural is >> probably out of the question for compatibility reasons, but an early >> deprecation would avoid one source of user confusion.) >> >> Regards >> >> Ed Willink >> >> On 24/07/2013 10:46, Steve Cook wrote: >> >>> Can the issue be that UnlimitedNatural is not really a subtype of Integer? >> >> Absolutely. These numeric types are not subtypes of each other >> under any useful algebraic notion of substitutability. Integers are >> not closed under division, as Reals are. UnlimitedNaturals are only >> ever subject to comparison, and do not engage in arithmetic with >> each other or with other numbers. There is no value and only >> confusion in pretending that subtyping is going on. In practice, >> Integer maps to whatever your computer counts in its words and adds >> up in its CPU, and UnlimitedNatural is mapped to the same thing with >> a special value (usually -1) to represent *. >> >> There may be coercions, even implicit ones, but that is not the same >> thing. >> >> I see no value in introducing the idea of "minus unbounded" to OCL. >> Requiring all of these types to be implemented as floating point >> numbers, as is implied by the proposed resolution to 15780, will >> presumably invalidate all existing implementations of UML and OCL, >> and is a poor idea. >> >> -- Steve >> >> *From:*Ed Willink [mailto:ed@willink.me.uk] >> *Sent:* 23 July 2013 23:04 >> *To:* ocl2-rtf@omg.org >> *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 >> >> On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: >> >> Hi Ed, >> >> Some feedback about your document. >> >> Issue 15009 : >> Shorthand is used along OCL/QVT rather than shortform. >> >> Fixed in Preview 2 >> >> >> Since the new subsection is related to object navigation, I'm >> wondering if section 7.6 is more suitable for it. >> >> The idea was to get it in before navigation. Also one of the PAS >> issues complians about no ./-> in 7.5.8. >> >> >> >> Issue 15780 : >> 1. What does symbolic analysis mean? >> >> Analyzing an expression without evaluating it. >> >> >> 2. IEEE 754 alignment sounds like a UML2 misalignment. Note >> that UnlimitedNatural not only accommodates the need for an >> unlimited upper bound multiplicity, but also the lower bound >> value is constrained by not permitting the unbounded (or >> infinite) one by using the Integer type. With this proposal OCL >> is changing the semantics of Integer (and Real) given by UML. >> Can the issue be that UnlimitedNatural is not really a subtype >> of Integer (Looking at the varied Real-Integer-UnlimitedNatural >> operations, it looks like there is some Liskov substitution >> principle violation smell)?. Are we again dealing with a >> conformance related issue ?. >> >> I don't understand your point. >> >> There is no problem with UnlimitedNatural having fewer values (no >> negatives). The problem is an extra positive value. >> >> >> >> Issue 18437: >> OclAny defines post conditions for their library operations. >> I see no point why this should be different for the new >> operations on OclVoid and OclInvalid >> >> The OclAny postconditions had somethjing to say. >> I dont'tsee the point in padding out " Evaluates to true." with >> post: result = true. >> >> >> Issue 18464: >> OCL is mainly founded on (first-order) predicate logic and >> set theory. Could you provide a reference supporting your >> affirmation about why the algorithm is correct and the text >> incorrect ?. >> >> I don't understand your point. >> This is a fix for inconsistency in the wording, not an algorithm change. >> >> >> >> Issue 6600: >> I must be missing/misunderstanding something. I see a table >> of contents in the beginning. What's wrong with OCL 2.3 ? >> >> An Index is not the TOC. It is generally at the end. There is no >> index in OCL 2.3.1. >> >> >> >> Issue 6879-6882: >> We could argue about if shorthands are convenient/readable or >> not, but rationale like "but avoids introducing a "?" syntax >> irregularity" doesn't seem convincing for discarding the syntax >> enhancement. What does syntax irregularity mean ?. >> In general, I find aligning OCL-QVT syntax as a good idea. So >> unless you identify real problems of adopting this alignment, I >> don't see the point of closing these issues as no change. >> Borrowing your comment to discard other proposals: "The >> 'problems' have not prevented QVT tool being built" >> >> Nobody has demonstrated that QVTo has no limitations over the full >> OCL syntax in particular UML qualifiers. >> I'm not comfortable with the QVTo syntax extensions and the drift to >> be a non-Java Java.. >> I don't see that usage by QVTo requires adoption by OCL. >> I figure that if Mariano had really wanted these changes he would >> have put them to a ballot for OCL 2.2. >> >> >> Issue 6894: >> Better solution = no change ?? >> >> An additional library routine is not a change to the OCL language. >> >> >> Issue 7466: >> Should not every "self.condition.type.oclIsKindOf(Primitive) >> and self.condition.type.name = 'Boolean'" be changed by >> "self.condition.type = Boolean" ? >> I guess this could be deferred until specification >> generation is done. >> >> Yes. That is why half the issues cannot be addressed very profitably >> at present. We still have only visual OCL checking. >> >> >> >> Issue 14985: >> Resolution keyword missing, so summary and resolution is >> mixed in the summary section. >> >> No. The summary is what the original submitter wrote. I often write >> solutions in the submissions. >> The missing Resolution paragraph will be added in Preview 2. >> >> Regards >> >> Ed Willink >> >> >> >> Regards, >> Adolfo. >> -- >> On 22/07/2013 07:23, Ed Willink wrote: >> >> >> Hi >> >> Attached: Preview 1 of the Issues resolved in Ballot 1. >> >> The one week preview lasts from now until voting starts on >> 29th July. >> >> The two week voting period lasts from 29th July to 11th August. >> >> More details may be found in the preamble to the attached. >> >> Regards >> >> Ed Willink >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: >> 07/22/13 >> >> >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >> 07/23/13 >> > > X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC107.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -14 X-BigFish: VS-14(z21cRzbb2dI98dIc89bh542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah8275dh1de097h1de096h18602eh84d07h8275bhz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: Ed Willink , "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAYuYCAABwDYA== Date: Wed, 24 Jul 2013 18:32:46 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6OIXmO8001576 Ed >Any OCL implementation that is limited to 32/64 bit integers or 32/64/128 bit floats is buggy. That is a completely unrealistic and uneconomic perspective on what it means in practice to implement a language. >will find the lack of support for +/- infinity in OCL a major pain Presumably they will find such support in the domain of real numbers, if those are done properly. -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 17:48 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Steve I wish I hadn't mentioned IEEE 754, it seems to have confused you despite my added comment that precision was unconstrained by IEEE 754. The only aspect of IEEE 754 that I was proposing to exploit was the rules for {Number,Zero,+Infinity,-Infinity,Invalid} x {Number,Zero,+Infinity,-Infinity,Invalid} => {Number,Zero,+Infinity,-Infinity,Invalid}. OCL Integers are fully substitutable with respect to Real since Real is specified to be unbounded. You are confusing typical implementation approaches with the specified behaviour. Any OCL implementation that is limited to 32/64 bit integers or 32/64/128 bit floats is buggy. IMHO adding +/-Infinity to OCL Integer and Real is almost no change. It just cleans up a deficiency with respect to standard arithmetic capabilities and eliminates the UnlimitedNatural subtyping problem at the same time. If anyone tries to implement an OCL Maths library with log() etc, they will of course look to IEEE-754 for guidance and will find the lack of support for +/- infinity in OCL a major pain. Regards Ed Willink On 24/07/2013 16:39, Steve Cook wrote: >> a subtype (subset) > Subtype does not mean subset. It means algebraically substitutable. > > There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. > > The desire for subtyping between these types is misplaced. It is unnecessary. > > Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. > > -- Steve > > -----Original Message----- > From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] > Sent: 24 July 2013 16:08 > To: ocl2-rtf@omg.org > Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > >> we just need to have a look about what programming languages > not sure that that is a good idea, > > My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. > > perhaps one should look at formal languages/mathematics to determine the solution! > > > -----Original Message----- > From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On > Behalf Of Adolfo Sáhez-Barbudo Herrera > Sent: 24 July 2013 15:29 > To: Steve Cook > Cc: Ed Willink; ocl2-rtf@omg.org > Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > > Hi Ed, Steve. > > - I don't like A since OCL changes Integer/Real semantics given by UML. > - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. > - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. > > I believe that there is not wheel to invent here, we just need to have > a look about what programming languages do (although traditional > programming languages -I've seen so far- don't deal with that > unbounded > (*) value). > > As a side note, in java, Integer object is not a subtype of Real one. > > Regards, > Adolfo. > On 24/07/2013 14:53, Steve Cook wrote: >> B2 seems the obvious choice to me. >> >>> Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. >> Lots of programming languages do it between numeric types.These types >> are not "unrelated", they are just not subtypes of one another. >> >>> it seems a bit odd to have plus-infinity without minus-infinity >> What "*" means is that a collection has unbounded size.A collection >> always has a non-negative size. >> >>> an early deprecation would avoid one source of user confusion >> Deprecating UnlimitedNatural in UML is just not going to happen, and >> taking OCL in a direction that widens the gap with UML is a poor strategy. >> >> -- Steve >> >> *From:*Ed Willink [mailto:ed@willink.me.uk] >> *Sent:* 24 July 2013 11:53 >> *To:* ocl2-rtf@omg.org >> *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >> Preview 1) >> >> Hi >> >> It is certainly not the intention to require integer implementation >> using floating point; just to require that the Integer and Real (as >> well >> UnlimitedNatural) have a special larger-than-anything-else (infinity) >> value. How implementations choose to implement that special value is >> not defined by the OCL specification. >> >> Currently implementations are required to check that every implicit >> conversion from UnlimitedNatural to Integer converts * to /invalid/. >> I suspect that many implementations are broken here already and so >> allow the implementation convenience of -1 to become visible; we >> certainly had to fix problems with Eclipse OCL here. >> >> Whether there is a minus-infinity is possibly a separate issue, but >> it seems a bit odd to have plus-infinity without minus-infinity. >> >> I'm not clear what the relevance of your comment that Integers are >> not closed under division is. OCL currently specifies the type >> conversion to Real to guarantee a result (except divide by 0). There >> is a separate div operator if you want the limited precision of an Integer result. >> >> Arithmetic is currently specified for UnlimitedNatural. 11.5.5 >> defines >> +,*,/, etc (no -). Conversion to Integer occurs when the capabilities >> +of >> UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. >> >> We have two main choices to resolve the contradictory subtyping >> claims for UnlimitedNatural. See 11.4.1, 11.4.2. >> >> /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./ >> >> a) Make UnlimitedNatural a full subtype of Integer by introducing >> plus-infinity to Integer and Real (the current resolution proposal) >> >> b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. >> - require positive integers to be parsed as Integer rather than >> UnlimitedNatural >> - require use of toInteger() to convert non-unlimited >> UnlimitedNatural to Integer >> - introduce and require use of toUnlimitedNatural() to convert >> non-negative Integer to UnlimitedNatural >> - retract all UnlimitedNatural arithmetic capabilities >> >> b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. >> - allow implicit conversion of non-unlimited UnlimitedNatural to >> Integer >> - allow implicit conversion of non-negative Integer to >> UnlimitedNatural >> >> IMHO breaking the subtype contract will cause problems for programs >> that currently exploit the free conversion since OCL currently has >> numbers that grow in range/precision as required. Providing free >> conversion between unrelated types is not something that I would like >> to try to justify to the academics. >> >> The current specified arithmetic capabilities for UnlimitedNatural >> allow >> * to participate in comparisons and max/min operations without the >> special casing that UML specification engages in to work around the >> inadequacies of implementations that execute with -1 for *. >> (Implementations are already broken.) >> >> Introducing *-is-infinity to Integer would allow UnlimitedNatural to >> be eliminated altogether. UML need only specify that the lowerBound >> is finite and non-negative. (Actual elimination of UnlimitedNatural >> is probably out of the question for compatibility reasons, but an >> early deprecation would avoid one source of user confusion.) >> >> Regards >> >> Ed Willink >> >> On 24/07/2013 10:46, Steve Cook wrote: >> >> >Can the issue be that UnlimitedNatural is not really a subtype of Integer? >> >> Absolutely. These numeric types are not subtypes of each other >> under any useful algebraic notion of substitutability. Integers are >> not closed under division, as Reals are. UnlimitedNaturals are only >> ever subject to comparison, and do not engage in arithmetic with >> each other or with other numbers. There is no value and only >> confusion in pretending that subtyping is going on. In practice, >> Integer maps to whatever your computer counts in its words and adds >> up in its CPU, and UnlimitedNatural is mapped to the same thing with >> a special value (usually -1) to represent *. >> >> There may be coercions, even implicit ones, but that is not the same >> thing. >> >> I see no value in introducing the idea of "minus unbounded" to OCL. >> Requiring all of these types to be implemented as floating point >> numbers, as is implied by the proposed resolution to 15780, will >> presumably invalidate all existing implementations of UML and OCL, >> and is a poor idea. >> >> -- Steve >> >> *From:*Ed Willink [mailto:ed@willink.me.uk] >> *Sent:* 23 July 2013 23:04 >> *To:* ocl2-rtf@omg.org >> *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 >> >> On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: >> >> Hi Ed, >> >> Some feedback about your document. >> >> Issue 15009 : >> Shorthand is used along OCL/QVT rather than shortform. >> >> Fixed in Preview 2 >> >> >> Since the new subsection is related to object navigation, I'm >> wondering if section 7.6 is more suitable for it. >> >> The idea was to get it in before navigation. Also one of the PAS >> issues complians about no ./-> in 7.5.8. >> >> >> >> Issue 15780 : >> 1. What does symbolic analysis mean? >> >> Analyzing an expression without evaluating it. >> >> >> 2. IEEE 754 alignment sounds like a UML2 misalignment. Note >> that UnlimitedNatural not only accommodates the need for an >> unlimited upper bound multiplicity, but also the lower bound >> value is constrained by not permitting the unbounded (or >> infinite) one by using the Integer type. With this proposal OCL >> is changing the semantics of Integer (and Real) given by UML. >> Can the issue be that UnlimitedNatural is not really a subtype >> of Integer (Looking at the varied Real-Integer-UnlimitedNatural >> operations, it looks like there is some Liskov substitution >> principle violation smell)?. Are we again dealing with a >> conformance related issue ?. >> >> I don't understand your point. >> >> There is no problem with UnlimitedNatural having fewer values (no >> negatives). The problem is an extra positive value. >> >> >> >> Issue 18437: >> OclAny defines post conditions for their library operations. >> I see no point why this should be different for the new >> operations on OclVoid and OclInvalid >> >> The OclAny postconditions had somethjing to say. >> I dont'tsee the point in padding out " Evaluates to true." with >> post: result = true. >> >> >> Issue 18464: >> OCL is mainly founded on (first-order) predicate logic and >> set theory. Could you provide a reference supporting your >> affirmation about why the algorithm is correct and the text >> incorrect ?. >> >> I don't understand your point. >> This is a fix for inconsistency in the wording, not an algorithm change. >> >> >> >> Issue 6600: >> I must be missing/misunderstanding something. I see a table >> of contents in the beginning. What's wrong with OCL 2.3 ? >> >> An Index is not the TOC. It is generally at the end. There is no >> index in OCL 2.3.1. >> >> >> >> Issue 6879-6882: >> We could argue about if shorthands are convenient/readable or >> not, but rationale like "but avoids introducing a "?" syntax >> irregularity" doesn't seem convincing for discarding the syntax >> enhancement. What does syntax irregularity mean ?. >> In general, I find aligning OCL-QVT syntax as a good idea. So >> unless you identify real problems of adopting this alignment, I >> don't see the point of closing these issues as no change. >> Borrowing your comment to discard other proposals: "The >> 'problems' have not prevented QVT tool being built" >> >> Nobody has demonstrated that QVTo has no limitations over the full >> OCL syntax in particular UML qualifiers. >> I'm not comfortable with the QVTo syntax extensions and the drift to >> be a non-Java Java.. >> I don't see that usage by QVTo requires adoption by OCL. >> I figure that if Mariano had really wanted these changes he would >> have put them to a ballot for OCL 2.2. >> >> >> Issue 6894: >> Better solution = no change ?? >> >> An additional library routine is not a change to the OCL language. >> >> >> Issue 7466: >> Should not every "self.condition.type.oclIsKindOf(Primitive) >> and self.condition.type.name = 'Boolean'" be changed by >> "self.condition.type = Boolean" ? >> I guess this could be deferred until specification >> generation is done. >> >> Yes. That is why half the issues cannot be addressed very profitably >> at present. We still have only visual OCL checking. >> >> >> >> Issue 14985: >> Resolution keyword missing, so summary and resolution is >> mixed in the summary section. >> >> No. The summary is what the original submitter wrote. I often write >> solutions in the submissions. >> The missing Resolution paragraph will be added in Preview 2. >> >> Regards >> >> Ed Willink >> >> >> >> Regards, >> Adolfo. >> -- >> On 22/07/2013 07:23, Ed Willink wrote: >> >> >> Hi >> >> Attached: Preview 1 of the Issues resolved in Ballot 1. >> >> The one week preview lasts from now until voting starts on >> 29th July. >> >> The two week voting period lasts from 29th July to 11th August. >> >> More details may be found in the preamble to the attached. >> >> Regards >> >> Ed Willink >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: >> 07/22/13 >> >> >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >> 07/23/13 >> > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: > 07/23/13 > > > X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC102.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -16 X-BigFish: VS-16(z21cRzbb2dI98dI9371Ic89bh936eI542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah8275dh1de097h1de096h18602eh84d07h8275bhz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: AKEHURST David , Bran Selic CC: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdA= Date: Wed, 24 Jul 2013 18:43:20 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r6OIiKeN003250 Content-Transfer-Encoding: 8bit I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. >Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: > http://en.wikipedia.org/wiki/Integer > > "The set of integers is a subset of the real numbers" > > >> The desire for subtyping between these types is misplaced. It is unnecessary. > > that depends on your perspective, context, where your are coming from. > I am not an expert in maths/algebra/formal computing/etc...so I shall > leave the debate to those who are, > > My point was that I believe that OCL has its roots in formal maths, not in programming languages. > > > The issue of IEEE floating point numbers etc, is a number > representation issue, due to the underlying (platform specific) architecture of the processors we use. > I thought that a key part of MDA, UML, OCL etc is that of Platform > Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? > The "programming language practical solutions" are platform specific issues are they not? > > > Personally I really like using the OCL Integer and Real with the subtype/subset relationship. > > > > -----Original Message----- > From: Steve Cook [mailto:Steve.Cook@microsoft.com] > Sent: 24 July 2013 16:39 > To: AKEHURST David; ocl2-rtf@omg.org > Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > >> a subtype (subset) > > Subtype does not mean subset. It means algebraically substitutable. > > There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. > > The desire for subtyping between these types is misplaced. It is unnecessary. > > Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. > > -- Steve > > -----Original Message----- > From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] > Sent: 24 July 2013 16:08 > To: ocl2-rtf@omg.org > Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > >> we just need to have a look about what programming languages > > not sure that that is a good idea, > > My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. > > perhaps one should look at formal languages/mathematics to determine the solution! > > > -----Original Message----- > From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On > Behalf Of Adolfo Sáhez-Barbudo Herrera > Sent: 24 July 2013 15:29 > To: Steve Cook > Cc: Ed Willink; ocl2-rtf@omg.org > Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > > Hi Ed, Steve. > > - I don't like A since OCL changes Integer/Real semantics given by UML. > - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. > - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. > > I believe that there is not wheel to invent here, we just need to have > a look about what programming languages do (although traditional > programming languages -I've seen so far- don't deal with that > unbounded > (*) value). > > As a side note, in java, Integer object is not a subtype of Real one. > > Regards, > Adolfo. > On 24/07/2013 14:53, Steve Cook wrote: >> B2 seems the obvious choice to me. >> >>> Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. >> >> Lots of programming languages do it between numeric types.These types >> are not "unrelated", they are just not subtypes of one another. >> >>> it seems a bit odd to have plus-infinity without minus-infinity >> >> What "*" means is that a collection has unbounded size.A collection >> always has a non-negative size. >> >>> an early deprecation would avoid one source of user confusion >> >> Deprecating UnlimitedNatural in UML is just not going to happen, and >> taking OCL in a direction that widens the gap with UML is a poor strategy. >> >> -- Steve >> >> *From:*Ed Willink [mailto:ed@willink.me.uk] >> *Sent:* 24 July 2013 11:53 >> *To:* ocl2-rtf@omg.org >> *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >> Preview 1) >> >> Hi >> >> It is certainly not the intention to require integer implementation >> using floating point; just to require that the Integer and Real (as >> well >> UnlimitedNatural) have a special larger-than-anything-else (infinity) >> value. How implementations choose to implement that special value is >> not defined by the OCL specification. >> >> Currently implementations are required to check that every implicit >> conversion from UnlimitedNatural to Integer converts * to /invalid/. >> I suspect that many implementations are broken here already and so >> allow the implementation convenience of -1 to become visible; we >> certainly had to fix problems with Eclipse OCL here. >> >> Whether there is a minus-infinity is possibly a separate issue, but >> it seems a bit odd to have plus-infinity without minus-infinity. >> >> I'm not clear what the relevance of your comment that Integers are >> not closed under division is. OCL currently specifies the type >> conversion to Real to guarantee a result (except divide by 0). There >> is a separate div operator if you want the limited precision of an Integer result. >> >> Arithmetic is currently specified for UnlimitedNatural. 11.5.5 >> defines >> +,*,/, etc (no -). Conversion to Integer occurs when the capabilities >> +of >> UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. >> >> We have two main choices to resolve the contradictory subtyping >> claims for UnlimitedNatural. See 11.4.1, 11.4.2. >> >> /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./ >> >> a) Make UnlimitedNatural a full subtype of Integer by introducing >> plus-infinity to Integer and Real (the current resolution proposal) >> >> b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. >> - require positive integers to be parsed as Integer rather than >> UnlimitedNatural >> - require use of toInteger() to convert non-unlimited >> UnlimitedNatural to Integer >> - introduce and require use of toUnlimitedNatural() to convert >> non-negative Integer to UnlimitedNatural >> - retract all UnlimitedNatural arithmetic capabilities >> >> b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. >> - allow implicit conversion of non-unlimited UnlimitedNatural to >> Integer >> - allow implicit conversion of non-negative Integer to >> UnlimitedNatural >> >> IMHO breaking the subtype contract will cause problems for programs >> that currently exploit the free conversion since OCL currently has >> numbers that grow in range/precision as required. Providing free >> conversion between unrelated types is not something that I would like >> to try to justify to the academics. >> >> The current specified arithmetic capabilities for UnlimitedNatural >> allow >> * to participate in comparisons and max/min operations without the >> special casing that UML specification engages in to work around the >> inadequacies of implementations that execute with -1 for *. >> (Implementations are already broken.) >> >> Introducing *-is-infinity to Integer would allow UnlimitedNatural to >> be eliminated altogether. UML need only specify that the lowerBound >> is finite and non-negative. (Actual elimination of UnlimitedNatural >> is probably out of the question for compatibility reasons, but an >> early deprecation would avoid one source of user confusion.) >> >> Regards >> >> Ed Willink >> >> On 24/07/2013 10:46, Steve Cook wrote: >> >>> Can the issue be that UnlimitedNatural is not really a subtype of Integer? >> >> Absolutely. These numeric types are not subtypes of each other >> under any useful algebraic notion of substitutability. Integers are >> not closed under division, as Reals are. UnlimitedNaturals are only >> ever subject to comparison, and do not engage in arithmetic with >> each other or with other numbers. There is no value and only >> confusion in pretending that subtyping is going on. In practice, >> Integer maps to whatever your computer counts in its words and adds >> up in its CPU, and UnlimitedNatural is mapped to the same thing with >> a special value (usually -1) to represent *. >> >> There may be coercions, even implicit ones, but that is not the same >> thing. >> >> I see no value in introducing the idea of "minus unbounded" to OCL. >> Requiring all of these types to be implemented as floating point >> numbers, as is implied by the proposed resolution to 15780, will >> presumably invalidate all existing implementations of UML and OCL, >> and is a poor idea. >> >> -- Steve >> >> *From:*Ed Willink [mailto:ed@willink.me.uk] >> *Sent:* 23 July 2013 23:04 >> *To:* ocl2-rtf@omg.org >> *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 >> >> On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: >> >> Hi Ed, >> >> Some feedback about your document. >> >> Issue 15009 : >> Shorthand is used along OCL/QVT rather than shortform. >> >> Fixed in Preview 2 >> >> >> Since the new subsection is related to object navigation, I'm >> wondering if section 7.6 is more suitable for it. >> >> The idea was to get it in before navigation. Also one of the PAS >> issues complians about no ./-> in 7.5.8. >> >> >> >> Issue 15780 : >> 1. What does symbolic analysis mean? >> >> Analyzing an expression without evaluating it. >> >> >> 2. IEEE 754 alignment sounds like a UML2 misalignment. Note >> that UnlimitedNatural not only accommodates the need for an >> unlimited upper bound multiplicity, but also the lower bound >> value is constrained by not permitting the unbounded (or >> infinite) one by using the Integer type. With this proposal OCL >> is changing the semantics of Integer (and Real) given by UML. >> Can the issue be that UnlimitedNatural is not really a subtype >> of Integer (Looking at the varied Real-Integer-UnlimitedNatural >> operations, it looks like there is some Liskov substitution >> principle violation smell)?. Are we again dealing with a >> conformance related issue ?. >> >> I don't understand your point. >> >> There is no problem with UnlimitedNatural having fewer values (no >> negatives). The problem is an extra positive value. >> >> >> >> Issue 18437: >> OclAny defines post conditions for their library operations. >> I see no point why this should be different for the new >> operations on OclVoid and OclInvalid >> >> The OclAny postconditions had somethjing to say. >> I dont'tsee the point in padding out " Evaluates to true." with >> post: result = true. >> >> >> Issue 18464: >> OCL is mainly founded on (first-order) predicate logic and >> set theory. Could you provide a reference supporting your >> affirmation about why the algorithm is correct and the text >> incorrect ?. >> >> I don't understand your point. >> This is a fix for inconsistency in the wording, not an algorithm change. >> >> >> >> Issue 6600: >> I must be missing/misunderstanding something. I see a table >> of contents in the beginning. What's wrong with OCL 2.3 ? >> >> An Index is not the TOC. It is generally at the end. There is no >> index in OCL 2.3.1. >> >> >> >> Issue 6879-6882: >> We could argue about if shorthands are convenient/readable or >> not, but rationale like "but avoids introducing a "?" syntax >> irregularity" doesn't seem convincing for discarding the syntax >> enhancement. What does syntax irregularity mean ?. >> In general, I find aligning OCL-QVT syntax as a good idea. So >> unless you identify real problems of adopting this alignment, I >> don't see the point of closing these issues as no change. >> Borrowing your comment to discard other proposals: "The >> 'problems' have not prevented QVT tool being built" >> >> Nobody has demonstrated that QVTo has no limitations over the full >> OCL syntax in particular UML qualifiers. >> I'm not comfortable with the QVTo syntax extensions and the drift to >> be a non-Java Java.. >> I don't see that usage by QVTo requires adoption by OCL. >> I figure that if Mariano had really wanted these changes he would >> have put them to a ballot for OCL 2.2. >> >> >> Issue 6894: >> Better solution = no change ?? >> >> An additional library routine is not a change to the OCL language. >> >> >> Issue 7466: >> Should not every "self.condition.type.oclIsKindOf(Primitive) >> and self.condition.type.name = 'Boolean'" be changed by >> "self.condition.type = Boolean" ? >> I guess this could be deferred until specification >> generation is done. >> >> Yes. That is why half the issues cannot be addressed very profitably >> at present. We still have only visual OCL checking. >> >> >> >> Issue 14985: >> Resolution keyword missing, so summary and resolution is >> mixed in the summary section. >> >> No. The summary is what the original submitter wrote. I often write >> solutions in the submissions. >> The missing Resolution paragraph will be added in Preview 2. >> >> Regards >> >> Ed Willink >> >> >> >> Regards, >> Adolfo. >> -- >> On 22/07/2013 07:23, Ed Willink wrote: >> >> >> Hi >> >> Attached: Preview 1 of the Issues resolved in Ballot 1. >> >> The one week preview lasts from now until voting starts on >> 29th July. >> >> The two week voting period lasts from 29th July to 11th August. >> >> More details may be found in the preamble to the attached. >> >> Regards >> >> Ed Willink >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: >> 07/22/13 >> >> >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >> 07/23/13 >> > >X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=33RrB3tuMlcA:10 a=IkcTkHD0fZMA:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=jb1_pgqOAAAA:8 a=KHpXyVWLAAAA:8 a=pGLkceISAAAA:8 a=8pif782wAAAA:8 a=yMhMjlubAAAA:8 a=oCcaPWc0AAAA:8 a=FB-9_eQJfLx-blfawekA:9 a=-3POhXY3779Wqi0k:21 a=0z3nRGnRcnIUq1xp:21 a=QEXdDO2ut3YA:10 a=WP4_USCxRkkA:10 a=MSl-tDqOz04A:10 a=-AOE9ft50oIA:10 Date: Wed, 24 Jul 2013 20:14:28 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 8bit Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities +of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14MLTC102.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -16 X-BigFish: VS-16(z21cRzbb2dI98dI9371Ic89bh936eI542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah8275dh1de097h1de096h18602eh84d07h8275bhz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: Ed Willink , "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdCAAAubAIAAEEYA Date: Wed, 24 Jul 2013 20:15:24 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r6OKIFBj023738 Content-Transfer-Encoding: 8bit Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: > I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. > >> Personally I really like using the OCL Integer and Real with the >> subtype/subset relationship > I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? > > -----Original Message----- > From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] > Sent: 24 July 2013 19:00 > To: Bran Selic > Cc: ocl2-rtf@omg.org > Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > > Am happy to take on board the opinion of any experts, was just trying to understand? > > > -----Original Message----- > From: Bran Selic [mailto:bran.selic@gmail.com] > Sent: 24 July 2013 17:59 > To: AKEHURST David > Cc: ocl2-rtf@omg.org > Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 > Preview 1) > > Just a clarification: > > Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. > > BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. > > Cheers... Bran > > On 2013-07-24, at 5:53 PM, AKEHURST David wrote: > >> http://en.wikipedia.org/wiki/Integer >> >> "The set of integers is a subset of the real numbers" >> >> >>> The desire for subtyping between these types is misplaced. It is unnecessary. >> that depends on your perspective, context, where your are coming from. >> I am not an expert in maths/algebra/formal computing/etc...so I shall >> leave the debate to those who are, >> >> My point was that I believe that OCL has its roots in formal maths, not in programming languages. >> >> >> The issue of IEEE floating point numbers etc, is a number >> representation issue, due to the underlying (platform specific) architecture of the processors we use. >> I thought that a key part of MDA, UML, OCL etc is that of Platform >> Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? >> The "programming language practical solutions" are platform specific issues are they not? >> >> >> Personally I really like using the OCL Integer and Real with the subtype/subset relationship. >> >> >> >> -----Original Message----- >> From: Steve Cook [mailto:Steve.Cook@microsoft.com] >> Sent: 24 July 2013 16:39 >> To: AKEHURST David; ocl2-rtf@omg.org >> Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >> Preview 1) >> >>> a subtype (subset) >> Subtype does not mean subset. It means algebraically substitutable. >> >> There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. >> >> The desire for subtyping between these types is misplaced. It is unnecessary. >> >> Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. >> >> -- Steve >> >> -----Original Message----- >> From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] >> Sent: 24 July 2013 16:08 >> To: ocl2-rtf@omg.org >> Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >> Preview 1) >> >>> we just need to have a look about what programming languages >> not sure that that is a good idea, >> >> My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. >> >> perhaps one should look at formal languages/mathematics to determine the solution! >> >> >> -----Original Message----- >> From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On >> Behalf Of Adolfo Sáhez-Barbudo Herrera >> Sent: 24 July 2013 15:29 >> To: Steve Cook >> Cc: Ed Willink; ocl2-rtf@omg.org >> Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >> Preview 1) >> >> Hi Ed, Steve. >> >> - I don't like A since OCL changes Integer/Real semantics given by UML. >> - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. >> - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. >> >> I believe that there is not wheel to invent here, we just need to >> have a look about what programming languages do (although traditional >> programming languages -I've seen so far- don't deal with that >> unbounded >> (*) value). >> >> As a side note, in java, Integer object is not a subtype of Real one. >> >> Regards, >> Adolfo. >> On 24/07/2013 14:53, Steve Cook wrote: >>> B2 seems the obvious choice to me. >>> >>>> Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. >>> Lots of programming languages do it between numeric types.These >>> types are not "unrelated", they are just not subtypes of one another. >>> >>>> it seems a bit odd to have plus-infinity without minus-infinity >>> What "*" means is that a collection has unbounded size.A collection >>> always has a non-negative size. >>> >>>> an early deprecation would avoid one source of user confusion >>> Deprecating UnlimitedNatural in UML is just not going to happen, and >>> taking OCL in a direction that widens the gap with UML is a poor strategy. >>> >>> -- Steve >>> >>> *From:*Ed Willink [mailto:ed@willink.me.uk] >>> *Sent:* 24 July 2013 11:53 >>> *To:* ocl2-rtf@omg.org >>> *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>> Preview 1) >>> >>> Hi >>> >>> It is certainly not the intention to require integer implementation >>> using floating point; just to require that the Integer and Real (as >>> well >>> UnlimitedNatural) have a special larger-than-anything-else >>> (infinity) value. How implementations choose to implement that >>> special value is not defined by the OCL specification. >>> >>> Currently implementations are required to check that every implicit >>> conversion from UnlimitedNatural to Integer converts * to /invalid/. >>> I suspect that many implementations are broken here already and so >>> allow the implementation convenience of -1 to become visible; we >>> certainly had to fix problems with Eclipse OCL here. >>> >>> Whether there is a minus-infinity is possibly a separate issue, but >>> it seems a bit odd to have plus-infinity without minus-infinity. >>> >>> I'm not clear what the relevance of your comment that Integers are >>> not closed under division is. OCL currently specifies the type >>> conversion to Real to guarantee a result (except divide by 0). There >>> is a separate div operator if you want the limited precision of an Integer result. >>> >>> Arithmetic is currently specified for UnlimitedNatural. 11.5.5 >>> defines >>> +,*,/, etc (no -). Conversion to Integer occurs when the >>> +capabilities of >>> UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. >>> >>> We have two main choices to resolve the contradictory subtyping >>> claims for UnlimitedNatural. See 11.4.1, 11.4.2. >>> >>> /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./ >>> >>> a) Make UnlimitedNatural a full subtype of Integer by introducing >>> plus-infinity to Integer and Real (the current resolution proposal) >>> >>> b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. >>> - require positive integers to be parsed as Integer rather than >>> UnlimitedNatural >>> - require use of toInteger() to convert non-unlimited >>> UnlimitedNatural to Integer >>> - introduce and require use of toUnlimitedNatural() to convert >>> non-negative Integer to UnlimitedNatural >>> - retract all UnlimitedNatural arithmetic capabilities >>> >>> b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. >>> - allow implicit conversion of non-unlimited UnlimitedNatural to >>> Integer >>> - allow implicit conversion of non-negative Integer to >>> UnlimitedNatural >>> >>> IMHO breaking the subtype contract will cause problems for programs >>> that currently exploit the free conversion since OCL currently has >>> numbers that grow in range/precision as required. Providing free >>> conversion between unrelated types is not something that I would >>> like to try to justify to the academics. >>> >>> The current specified arithmetic capabilities for UnlimitedNatural >>> allow >>> * to participate in comparisons and max/min operations without the >>> special casing that UML specification engages in to work around the >>> inadequacies of implementations that execute with -1 for *. >>> (Implementations are already broken.) >>> >>> Introducing *-is-infinity to Integer would allow UnlimitedNatural to >>> be eliminated altogether. UML need only specify that the lowerBound >>> is finite and non-negative. (Actual elimination of UnlimitedNatural >>> is probably out of the question for compatibility reasons, but an >>> early deprecation would avoid one source of user confusion.) >>> >>> Regards >>> >>> Ed Willink >>> >>> On 24/07/2013 10:46, Steve Cook wrote: >>> >>>> Can the issue be that UnlimitedNatural is not really a subtype of Integer? >>> Absolutely. These numeric types are not subtypes of each other >>> under any useful algebraic notion of substitutability. Integers are >>> not closed under division, as Reals are. UnlimitedNaturals are only >>> ever subject to comparison, and do not engage in arithmetic with >>> each other or with other numbers. There is no value and only >>> confusion in pretending that subtyping is going on. In practice, >>> Integer maps to whatever your computer counts in its words and adds >>> up in its CPU, and UnlimitedNatural is mapped to the same thing with >>> a special value (usually -1) to represent *. >>> >>> There may be coercions, even implicit ones, but that is not the same >>> thing. >>> >>> I see no value in introducing the idea of "minus unbounded" to OCL. >>> Requiring all of these types to be implemented as floating point >>> numbers, as is implied by the proposed resolution to 15780, will >>> presumably invalidate all existing implementations of UML and OCL, >>> and is a poor idea. >>> >>> -- Steve >>> >>> *From:*Ed Willink [mailto:ed@willink.me.uk] >>> *Sent:* 23 July 2013 23:04 >>> *To:* ocl2-rtf@omg.org >>> *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 >>> >>> On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: >>> >>> Hi Ed, >>> >>> Some feedback about your document. >>> >>> Issue 15009 : >>> Shorthand is used along OCL/QVT rather than shortform. >>> >>> Fixed in Preview 2 >>> >>> >>> Since the new subsection is related to object navigation, I'm >>> wondering if section 7.6 is more suitable for it. >>> >>> The idea was to get it in before navigation. Also one of the PAS >>> issues complians about no ./-> in 7.5.8. >>> >>> >>> >>> Issue 15780 : >>> 1. What does symbolic analysis mean? >>> >>> Analyzing an expression without evaluating it. >>> >>> >>> 2. IEEE 754 alignment sounds like a UML2 misalignment. Note >>> that UnlimitedNatural not only accommodates the need for an >>> unlimited upper bound multiplicity, but also the lower bound >>> value is constrained by not permitting the unbounded (or >>> infinite) one by using the Integer type. With this proposal OCL >>> is changing the semantics of Integer (and Real) given by UML. >>> Can the issue be that UnlimitedNatural is not really a subtype >>> of Integer (Looking at the varied Real-Integer-UnlimitedNatural >>> operations, it looks like there is some Liskov substitution >>> principle violation smell)?. Are we again dealing with a >>> conformance related issue ?. >>> >>> I don't understand your point. >>> >>> There is no problem with UnlimitedNatural having fewer values (no >>> negatives). The problem is an extra positive value. >>> >>> >>> >>> Issue 18437: >>> OclAny defines post conditions for their library operations. >>> I see no point why this should be different for the new >>> operations on OclVoid and OclInvalid >>> >>> The OclAny postconditions had somethjing to say. >>> I dont'tsee the point in padding out " Evaluates to true." with >>> post: result = true. >>> >>> >>> Issue 18464: >>> OCL is mainly founded on (first-order) predicate logic and >>> set theory. Could you provide a reference supporting your >>> affirmation about why the algorithm is correct and the text >>> incorrect ?. >>> >>> I don't understand your point. >>> This is a fix for inconsistency in the wording, not an algorithm change. >>> >>> >>> >>> Issue 6600: >>> I must be missing/misunderstanding something. I see a table >>> of contents in the beginning. What's wrong with OCL 2.3 ? >>> >>> An Index is not the TOC. It is generally at the end. There is no >>> index in OCL 2.3.1. >>> >>> >>> >>> Issue 6879-6882: >>> We could argue about if shorthands are convenient/readable or >>> not, but rationale like "but avoids introducing a "?" syntax >>> irregularity" doesn't seem convincing for discarding the syntax >>> enhancement. What does syntax irregularity mean ?. >>> In general, I find aligning OCL-QVT syntax as a good idea. So >>> unless you identify real problems of adopting this alignment, I >>> don't see the point of closing these issues as no change. >>> Borrowing your comment to discard other proposals: "The >>> 'problems' have not prevented QVT tool being built" >>> >>> Nobody has demonstrated that QVTo has no limitations over the full >>> OCL syntax in particular UML qualifiers. >>> I'm not comfortable with the QVTo syntax extensions and the drift to >>> be a non-Java Java.. >>> I don't see that usage by QVTo requires adoption by OCL. >>> I figure that if Mariano had really wanted these changes he would >>> have put them to a ballot for OCL 2.2. >>> >>> >>> Issue 6894: >>> Better solution = no change ?? >>> >>> An additional library routine is not a change to the OCL language. >>> >>> >>> Issue 7466: >>> Should not every "self.condition.type.oclIsKindOf(Primitive) >>> and self.condition.type.name = 'Boolean'" be changed by >>> "self.condition.type = Boolean" ? >>> I guess this could be deferred until specification >>> generation is done. >>> >>> Yes. That is why half the issues cannot be addressed very profitably >>> at present. We still have only visual OCL checking. >>> >>> >>> >>> Issue 14985: >>> Resolution keyword missing, so summary and resolution is >>> mixed in the summary section. >>> >>> No. The summary is what the original submitter wrote. I often write >>> solutions in the submissions. >>> The missing Resolution paragraph will be added in Preview 2. >>> >>> Regards >>> >>> Ed Willink >>> >>> >>> >>> Regards, >>> Adolfo. >>> -- >>> On 22/07/2013 07:23, Ed Willink wrote: >>> >>> >>> Hi >>> >>> Attached: Preview 1 of the Issues resolved in Ballot 1. >>> >>> The one week preview lasts from now until voting starts on >>> 29th July. >>> >>> The two week voting period lasts from 29th July to 11th August. >>> >>> More details may be found in the preamble to the attached. >>> >>> Regards >>> >>> Ed Willink >>> >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: >>> 07/22/13 >>> >>> >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >>> 07/23/13 >>> >> > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: > 07/24/13 From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "ocl2-rtf@omg.org" , "uml25-ftf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAP//pjsA Date: Wed, 24 Jul 2013 20:53:11 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6OKrKoO000787 I think that 15780 depends on resolving two problems with the PrimitiveTypes library from UML 2.4.1. 1) Real, which is inconsistently specified as the infinite set of mathematical real numbers but mapped to the finite set of double-precision floating-point arithmetic -- I.e., xsd:double. See http://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi A real is a primitive type representing the mathematical concept of real. The XMI mapping is inconsistent with the specification of PrimitiveTypes::Real. This can be easily fixed: PrimitiveTypes::Real can be mapped to owl:real, which is equivalently defined as the set of all real numbers (I.e., an infinite set) (see: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Real_Numbers.2C_Decimal _Numbers.2C_and_Integers) For backwards compatibility and practicality, it would make sense to define subtypes of PrimitiveTypes::Real and map them to practical representations of floating point numbers: PrimitiveTypes::Float and map it to xsd:float -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#float PrimitiveTypes::Double and map it to xsd:double -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double 2) UnlimitedNatural lacks a definition or mapping to an XML Schema 1.1 datatype The following definition conforms to both XML Schema 1.1 datatypes and the restrictions on the definition of datatype mappings for OWL2 (I.e., we can use it with OWL2 reasoners, SPARQL engines, etc.) * Should I raise an issue about this and propose the above as a resolution for ballot 8 of UML 2.5? - Nicolas. On 7/24/13 12:14 PM, "Ed Willink" wrote: >Hi > >The problem that concerns me is that without subtyping a >Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either >break existing programs or write in special case type conversion rules >that sort of do subtyping without calling it such. > >Presumably conformsTo is one place where the no-longer-subtype must be >re-instated, but if we modify conformsTo to allow compatibility is it >really the case that the subtype relationship does not exist? >conformsTo does not have access to the run-time values so cannot tell >whether an 'unlimited' value will be involved. > >I see a much greater mess than the current inaccuracy. > > Regards > > Ed Willink > > >On 24/07/2013 19:43, Steve Cook wrote: >> I am just as likely to be wrong as anybody on this or any other topic, >>so don't take my word for anything. But I do think that OCL is supposed >>to be a practical and economically implementable language that aligns >>with UML. >> >>> Personally I really like using the OCL Integer and Real with the >>>subtype/subset relationship >> I am interested in why. In particular, would you not get just as nice >>an experience with an implicit coercion scheme? >> >> -----Original Message----- >> From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] >> Sent: 24 July 2013 19:00 >> To: Bran Selic >> Cc: ocl2-rtf@omg.org >> Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>Preview 1) >> >> Am happy to take on board the opinion of any experts, was just trying >>to understand? >> >> >> -----Original Message----- >> From: Bran Selic [mailto:bran.selic@gmail.com] >> Sent: 24 July 2013 17:59 >> To: AKEHURST David >> Cc: ocl2-rtf@omg.org >> Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>Preview 1) >> >> Just a clarification: >> >> Platform independence does not mean platform ignorance. In practical >>terms, it means defining a boundary (envelope, if you like) of platforms >>that you are independent of. This point is much misunderstood. >> >> BTW, Steve may be to humble to mention it, but he is THE inventor of >>OCL. I would tend to take his word on what sits behind it. >> >> Cheers... Bran >> >> On 2013-07-24, at 5:53 PM, AKEHURST >>David wrote: >> >>> http://en.wikipedia.org/wiki/Integer >>> >>> "The set of integers is a subset of the real numbers" >>> >>> >>>> The desire for subtyping between these types is misplaced. It is >>>>unnecessary. >>> that depends on your perspective, context, where your are coming from. >>> I am not an expert in maths/algebra/formal computing/etc...so I shall >>> leave the debate to those who are, >>> >>> My point was that I believe that OCL has its roots in formal maths, >>>not in programming languages. >>> >>> >>> The issue of IEEE floating point numbers etc, is a number >>> representation issue, due to the underlying (platform specific) >>>architecture of the processors we use. >>> I thought that a key part of MDA, UML, OCL etc is that of Platform >>> Independence...(PIMs etc) why should they care about restrictions on >>>number representation caused by platform specific issues? >>> The "programming language practical solutions" are platform specific >>>issues are they not? >>> >>> >>> Personally I really like using the OCL Integer and Real with the >>>subtype/subset relationship. >>> >>> >>> >>> -----Original Message----- >>> From: Steve Cook [mailto:Steve.Cook@microsoft.com] >>> Sent: 24 July 2013 16:39 >>> To: AKEHURST David; ocl2-rtf@omg.org >>> Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>> Preview 1) >>> >>>> a subtype (subset) >>> Subtype does not mean subset. It means algebraically substitutable. >>> >>> There is no plausible implementation which will maintain correct >>>substitutability of integers of either limited or arbitrary size and >>>IEEE 754 floating point numbers, in a mathematically correct sense. >>>If the integers have limited size they can overflow and break the >>>substitutability; if they have arbitrary size they can exceed the >>>precision of the floats. The only way that these things could be made >>>to align mathematically would be to use floats for everything. >>> >>> The desire for subtyping between these types is misplaced. It is >>>unnecessary. >>> >>> Programming languages have acceptable practical solutions to these >>>problems: as long as when a program exceeds the limits of the >>>implementation an exception is thrown. >>> >>> -- Steve >>> >>> -----Original Message----- >>> From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] >>> Sent: 24 July 2013 16:08 >>> To: ocl2-rtf@omg.org >>> Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>> Preview 1) >>> >>>> we just need to have a look about what programming languages >>> not sure that that is a good idea, >>> >>> My understanding is that OCL has always had a much more mathematically >>>correct semantics than 'programming languages', especially w.r.t. >>>Integer being a subtype (subset) of Real. >>> >>> perhaps one should look at formal languages/mathematics to determine >>>the solution! >>> >>> >>> -----Original Message----- >>> From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On >>> Behalf Of Adolfo Sáhez-Barbudo Herrera >>> Sent: 24 July 2013 15:29 >>> To: Steve Cook >>> Cc: Ed Willink; ocl2-rtf@omg.org >>> Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>> Preview 1) >>> >>> Hi Ed, Steve. >>> >>> - I don't like A since OCL changes Integer/Real semantics given by UML. >>> - I don't like B1 since forcing to do explicit conversions sounds like >>>a very bad decision. >>> - B2 sounds the way to go on, although it deservers more than 5 >>>minutes of my thoughts regarding what occurs during parsing and how >>>conversions take place. >>> >>> I believe that there is not wheel to invent here, we just need to have >>> a look about what programming languages do (although traditional >>> programming languages -I've seen so far- don't deal with that >>> unbounded >>> (*) value). >>> >>> As a side note, in java, Integer object is not a subtype of Real one. >>> >>> Regards, >>> Adolfo. >>> On 24/07/2013 14:53, Steve Cook wrote: >>>> B2 seems the obvious choice to me. >>>> >>>>> Providing free conversion between unrelated types is not something >>>>>that I would like to try to justify to the academics. >>>> Lots of programming languages do it between numeric types.These types >>>> are not "unrelated", they are just not subtypes of one another. >>>> >>>>> it seems a bit odd to have plus-infinity without minus-infinity >>>> What "*" means is that a collection has unbounded size.A collection >>>> always has a non-negative size. >>>> >>>>> an early deprecation would avoid one source of user confusion >>>> Deprecating UnlimitedNatural in UML is just not going to happen, and >>>> taking OCL in a direction that widens the gap with UML is a poor >>>>strategy. >>>> >>>> -- Steve >>>> >>>> *From:*Ed Willink [mailto:ed@willink.me.uk] >>>> *Sent:* 24 July 2013 11:53 >>>> *To:* ocl2-rtf@omg.org >>>> *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>>> Preview 1) >>>> >>>> Hi >>>> >>>> It is certainly not the intention to require integer implementation >>>> using floating point; just to require that the Integer and Real (as >>>> well >>>> UnlimitedNatural) have a special larger-than-anything-else (infinity) >>>> value. How implementations choose to implement that special value is >>>> not defined by the OCL specification. >>>> >>>> Currently implementations are required to check that every implicit >>>> conversion from UnlimitedNatural to Integer converts * to /invalid/. >>>> I suspect that many implementations are broken here already and so >>>> allow the implementation convenience of -1 to become visible; we >>>> certainly had to fix problems with Eclipse OCL here. >>>> >>>> Whether there is a minus-infinity is possibly a separate issue, but >>>> it seems a bit odd to have plus-infinity without minus-infinity. >>>> >>>> I'm not clear what the relevance of your comment that Integers are >>>> not closed under division is. OCL currently specifies the type >>>> conversion to Real to guarantee a result (except divide by 0). There >>>> is a separate div operator if you want the limited precision of an >>>>Integer result. >>>> >>>> Arithmetic is currently specified for UnlimitedNatural. 11.5.5 >>>> defines >>>> +,*,/, etc (no -). Conversion to Integer occurs when the capabilities >>>> +of >>>> UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not >>>>available. >>>> >>>> We have two main choices to resolve the contradictory subtyping >>>> claims for UnlimitedNatural. See 11.4.1, 11.4.2. >>>> >>>> /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./ >>>> >>>> a) Make UnlimitedNatural a full subtype of Integer by introducing >>>> plus-infinity to Integer and Real (the current resolution proposal) >>>> >>>> b1) Make UnlimitedNatural unrelated to Integer with explicit >>>>conversion. >>>> - require positive integers to be parsed as Integer rather than >>>> UnlimitedNatural >>>> - require use of toInteger() to convert non-unlimited >>>> UnlimitedNatural to Integer >>>> - introduce and require use of toUnlimitedNatural() to convert >>>> non-negative Integer to UnlimitedNatural >>>> - retract all UnlimitedNatural arithmetic capabilities >>>> >>>> b2) Make UnlimitedNatural unrelated to Integer with implicit >>>>conversion. >>>> - allow implicit conversion of non-unlimited UnlimitedNatural to >>>> Integer >>>> - allow implicit conversion of non-negative Integer to >>>> UnlimitedNatural >>>> >>>> IMHO breaking the subtype contract will cause problems for programs >>>> that currently exploit the free conversion since OCL currently has >>>> numbers that grow in range/precision as required. Providing free >>>> conversion between unrelated types is not something that I would like >>>> to try to justify to the academics. >>>> >>>> The current specified arithmetic capabilities for UnlimitedNatural >>>> allow >>>> * to participate in comparisons and max/min operations without the >>>> special casing that UML specification engages in to work around the >>>> inadequacies of implementations that execute with -1 for *. >>>> (Implementations are already broken.) >>>> >>>> Introducing *-is-infinity to Integer would allow UnlimitedNatural to >>>> be eliminated altogether. UML need only specify that the lowerBound >>>> is finite and non-negative. (Actual elimination of UnlimitedNatural >>>> is probably out of the question for compatibility reasons, but an >>>> early deprecation would avoid one source of user confusion.) >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> On 24/07/2013 10:46, Steve Cook wrote: >>>> >>>>> Can the issue be that UnlimitedNatural is not really a subtype of >>>>>Integer? >>>> Absolutely. These numeric types are not subtypes of each other >>>> under any useful algebraic notion of substitutability. Integers >>>>are >>>> not closed under division, as Reals are. UnlimitedNaturals are >>>>only >>>> ever subject to comparison, and do not engage in arithmetic with >>>> each other or with other numbers. There is no value and only >>>> confusion in pretending that subtyping is going on. In practice, >>>> Integer maps to whatever your computer counts in its words and >>>>adds >>>> up in its CPU, and UnlimitedNatural is mapped to the same thing >>>>with >>>> a special value (usually -1) to represent *. >>>> >>>> There may be coercions, even implicit ones, but that is not the >>>>same >>>> thing. >>>> >>>> I see no value in introducing the idea of "minus unbounded" to >>>>OCL. >>>> Requiring all of these types to be implemented as floating point >>>> numbers, as is implied by the proposed resolution to 15780, will >>>> presumably invalidate all existing implementations of UML and OCL, >>>> and is a poor idea. >>>> >>>> -- Steve >>>> >>>> *From:*Ed Willink [mailto:ed@willink.me.uk] >>>> *Sent:* 23 July 2013 23:04 >>>> *To:* ocl2-rtf@omg.org >>>> *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 >>>> >>>> On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: >>>> >>>> Hi Ed, >>>> >>>> Some feedback about your document. >>>> >>>> Issue 15009 : >>>> Shorthand is used along OCL/QVT rather than shortform. >>>> >>>> Fixed in Preview 2 >>>> >>>> >>>> Since the new subsection is related to object navigation, >>>>I'm >>>> wondering if section 7.6 is more suitable for it. >>>> >>>> The idea was to get it in before navigation. Also one of the PAS >>>> issues complians about no ./-> in 7.5.8. >>>> >>>> >>>> >>>> Issue 15780 : >>>> 1. What does symbolic analysis mean? >>>> >>>> Analyzing an expression without evaluating it. >>>> >>>> >>>> 2. IEEE 754 alignment sounds like a UML2 misalignment. Note >>>> that UnlimitedNatural not only accommodates the need for an >>>> unlimited upper bound multiplicity, but also the lower bound >>>> value is constrained by not permitting the unbounded (or >>>> infinite) one by using the Integer type. With this proposal >>>>OCL >>>> is changing the semantics of Integer (and Real) given by UML. >>>> Can the issue be that UnlimitedNatural is not really a subtype >>>> of Integer (Looking at the varied >>>>Real-Integer-UnlimitedNatural >>>> operations, it looks like there is some Liskov substitution >>>> principle violation smell)?. Are we again dealing with a >>>> conformance related issue ?. >>>> >>>> I don't understand your point. >>>> >>>> There is no problem with UnlimitedNatural having fewer values (no >>>> negatives). The problem is an extra positive value. >>>> >>>> >>>> >>>> Issue 18437: >>>> OclAny defines post conditions for their library >>>>operations. >>>> I see no point why this should be different for the new >>>> operations on OclVoid and OclInvalid >>>> >>>> The OclAny postconditions had somethjing to say. >>>> I dont'tsee the point in padding out " Evaluates to true." with >>>> post: result = true. >>>> >>>> >>>> Issue 18464: >>>> OCL is mainly founded on (first-order) predicate logic and >>>> set theory. Could you provide a reference supporting your >>>> affirmation about why the algorithm is correct and the text >>>> incorrect ?. >>>> >>>> I don't understand your point. >>>> This is a fix for inconsistency in the wording, not an algorithm >>>>change. >>>> >>>> >>>> >>>> Issue 6600: >>>> I must be missing/misunderstanding something. I see a table >>>> of contents in the beginning. What's wrong with OCL 2.3 ? >>>> >>>> An Index is not the TOC. It is generally at the end. There is no >>>> index in OCL 2.3.1. >>>> >>>> >>>> >>>> Issue 6879-6882: >>>> We could argue about if shorthands are convenient/readable >>>>or >>>> not, but rationale like "but avoids introducing a "?" syntax >>>> irregularity" doesn't seem convincing for discarding the >>>>syntax >>>> enhancement. What does syntax irregularity mean ?. >>>> In general, I find aligning OCL-QVT syntax as a good idea. >>>>So >>>> unless you identify real problems of adopting this alignment, >>>>I >>>> don't see the point of closing these issues as no change. >>>> Borrowing your comment to discard other proposals: "The >>>> 'problems' have not prevented QVT tool being built" >>>> >>>> Nobody has demonstrated that QVTo has no limitations over the full >>>> OCL syntax in particular UML qualifiers. >>>> I'm not comfortable with the QVTo syntax extensions and the drift >>>>to >>>> be a non-Java Java.. >>>> I don't see that usage by QVTo requires adoption by OCL. >>>> I figure that if Mariano had really wanted these changes he would >>>> have put them to a ballot for OCL 2.2. >>>> >>>> >>>> Issue 6894: >>>> Better solution = no change ?? >>>> >>>> An additional library routine is not a change to the OCL language. >>>> >>>> >>>> Issue 7466: >>>> Should not every >>>>"self.condition.type.oclIsKindOf(Primitive) >>>> and self.condition.type.name = 'Boolean'" be changed by >>>> "self.condition.type = Boolean" ? >>>> I guess this could be deferred until specification >>>> generation is done. >>>> >>>> Yes. That is why half the issues cannot be addressed very >>>>profitably >>>> at present. We still have only visual OCL checking. >>>> >>>> >>>> >>>> Issue 14985: >>>> Resolution keyword missing, so summary and resolution is >>>> mixed in the summary section. >>>> >>>> No. The summary is what the original submitter wrote. I often >>>>write >>>> solutions in the submissions. >>>> The missing Resolution paragraph will be added in Preview 2. >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> >>>> >>>> Regards, >>>> Adolfo. >>>> -- >>>> On 22/07/2013 07:23, Ed Willink wrote: >>>> >>>> >>>> Hi >>>> >>>> Attached: Preview 1 of the Issues resolved in Ballot 1. >>>> >>>> The one week preview lasts from now until voting starts on >>>> 29th July. >>>> >>>> The two week voting period lasts from 29th July to 11th >>>>August. >>>> >>>> More details may be found in the preamble to the attached. >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3349 / Virus Database: 3204/6512 - Release >>>>Date: >>>> 07/22/13 >>>> >>>> >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >>>> 07/23/13 >>>> >>> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: >>07/24/13 > X-Virus-Scanned: OK From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" , "Ed Willink" , "ocl2-rtf@omg.org" , "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAP//pjsAgAAF2NA= Date: Wed, 24 Jul 2013 21:25:32 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.85.7] X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6OLPdPI003250 Nicolas -- I don't really think there is any issue with Real. The mapping to xsd:double is only for the purposes of model serialization, it's not a semantic definition. And the only Reals in a UML model that are serialized are the values of LiteralReals, which, given the textual syntax of Real literals in UML, will always be floating-point approximations of Reals. I am not sure that it is necessary to move to owl:real just because of the limited range of xsd:float, especially since we otherwise consistently use just the XSD type system. Even in the case of xsd:integer, in which the value space is nominally infinite, a processor can limit the number of digits allowed. The lack of mapping for UnlimitedNatural is an problem, but a much simpler solution (for the purposes of serialization) is to just map it to xsd:integer and specify that * maps to -1. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, July 24, 2013 4:53 PM To: Ed Willink; ocl2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I think that 15780 depends on resolving two problems with the PrimitiveTypes library from UML 2.4.1. 1) Real, which is inconsistently specified as the infinite set of mathematical real numbers but mapped to the finite set of double-precision floating-point arithmetic -- I.e., xsd:double. See http://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi A real is a primitive type representing the mathematical concept of real. The XMI mapping is inconsistent with the specification of PrimitiveTypes::Real. This can be easily fixed: PrimitiveTypes::Real can be mapped to owl:real, which is equivalently defined as the set of all real numbers (I.e., an infinite set) (see: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Real_Numbers.2C_Decimal _Numbers.2C_and_Integers) For backwards compatibility and practicality, it would make sense to define subtypes of PrimitiveTypes::Real and map them to practical representations of floating point numbers: PrimitiveTypes::Float and map it to xsd:float -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#float PrimitiveTypes::Double and map it to xsd:double -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double 2) UnlimitedNatural lacks a definition or mapping to an XML Schema 1.1 datatype The following definition conforms to both XML Schema 1.1 datatypes and the restrictions on the definition of datatype mappings for OWL2 (I.e., we can use it with OWL2 reasoners, SPARQL engines, etc©) * Should I raise an issue about this and propose the above as a resolution for ballot 8 of UML 2.5? - Nicolas. On 7/24/13 12:14 PM, "Ed Willink" wrote: >Hi > >The problem that concerns me is that without subtyping a >Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either >break existing programs or write in special case type conversion rules >that sort of do subtyping without calling it such. > >Presumably conformsTo is one place where the no-longer-subtype must be >re-instated, but if we modify conformsTo to allow compatibility is it >really the case that the subtype relationship does not exist? >conformsTo does not have access to the run-time values so cannot tell >whether an 'unlimited' value will be involved. > >I see a much greater mess than the current inaccuracy. > > Regards > > Ed Willink > > >On 24/07/2013 19:43, Steve Cook wrote: >> I am just as likely to be wrong as anybody on this or any other >>topic, so don't take my word for anything. But I do think that OCL is >>supposed to be a practical and economically implementable language >>that aligns with UML. >> >>> Personally I really like using the OCL Integer and Real with the >>>subtype/subset relationship >> I am interested in why. In particular, would you not get just as >>nice an experience with an implicit coercion scheme? >> >> -----Original Message----- >> From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] >> Sent: 24 July 2013 19:00 >> To: Bran Selic >> Cc: ocl2-rtf@omg.org >> Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>Preview 1) >> >> Am happy to take on board the opinion of any experts, was just trying >>to understand? >> >> >> -----Original Message----- >> From: Bran Selic [mailto:bran.selic@gmail.com] >> Sent: 24 July 2013 17:59 >> To: AKEHURST David >> Cc: ocl2-rtf@omg.org >> Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>Preview 1) >> >> Just a clarification: >> >> Platform independence does not mean platform ignorance. In practical >>terms, it means defining a boundary (envelope, if you like) of >>platforms that you are independent of. This point is much misunderstood. >> >> BTW, Steve may be to humble to mention it, but he is THE inventor of >>OCL. I would tend to take his word on what sits behind it. >> >> Cheers... Bran >> >> On 2013-07-24, at 5:53 PM, AKEHURST >>David wrote: >> >>> http://en.wikipedia.org/wiki/Integer >>> >>> "The set of integers is a subset of the real numbers" >>> >>> >>>> The desire for subtyping between these types is misplaced. It is >>>>unnecessary. >>> that depends on your perspective, context, where your are coming from. >>> I am not an expert in maths/algebra/formal computing/etc...so I >>> shall leave the debate to those who are, >>> >>> My point was that I believe that OCL has its roots in formal maths, >>>not in programming languages. >>> >>> >>> The issue of IEEE floating point numbers etc, is a number >>>representation issue, due to the underlying (platform specific) >>>architecture of the processors we use. >>> I thought that a key part of MDA, UML, OCL etc is that of Platform >>>Independence...(PIMs etc) why should they care about restrictions on >>>number representation caused by platform specific issues? >>> The "programming language practical solutions" are platform specific >>>issues are they not? >>> >>> >>> Personally I really like using the OCL Integer and Real with the >>>subtype/subset relationship. >>> >>> >>> >>> -----Original Message----- >>> From: Steve Cook [mailto:Steve.Cook@microsoft.com] >>> Sent: 24 July 2013 16:39 >>> To: AKEHURST David; ocl2-rtf@omg.org >>> Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot >>> 1 Preview 1) >>> >>>> a subtype (subset) >>> Subtype does not mean subset. It means algebraically substitutable. >>> >>> There is no plausible implementation which will maintain correct >>>substitutability of integers of either limited or arbitrary size and >>>IEEE 754 floating point numbers, in a mathematically correct sense. >>>If the integers have limited size they can overflow and break the >>>substitutability; if they have arbitrary size they can exceed the >>>precision of the floats. The only way that these things could be >>>made to align mathematically would be to use floats for everything. >>> >>> The desire for subtyping between these types is misplaced. It is >>>unnecessary. >>> >>> Programming languages have acceptable practical solutions to these >>>problems: as long as when a program exceeds the limits of the >>>implementation an exception is thrown. >>> >>> -- Steve >>> >>> -----Original Message----- >>> From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] >>> Sent: 24 July 2013 16:08 >>> To: ocl2-rtf@omg.org >>> Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot >>> 1 Preview 1) >>> >>>> we just need to have a look about what programming languages >>> not sure that that is a good idea, >>> >>> My understanding is that OCL has always had a much more >>>mathematically correct semantics than 'programming languages', especially w.r.t. >>>Integer being a subtype (subset) of Real. >>> >>> perhaps one should look at formal languages/mathematics to determine >>>the solution! >>> >>> >>> -----Original Message----- >>> From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On >>> Behalf Of Adolfo Sáhez-Barbudo Herrera >>> Sent: 24 July 2013 15:29 >>> To: Steve Cook >>> Cc: Ed Willink; ocl2-rtf@omg.org >>> Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot >>> 1 Preview 1) >>> >>> Hi Ed, Steve. >>> >>> - I don't like A since OCL changes Integer/Real semantics given by UML. >>> - I don't like B1 since forcing to do explicit conversions sounds >>>like a very bad decision. >>> - B2 sounds the way to go on, although it deservers more than 5 >>>minutes of my thoughts regarding what occurs during parsing and how >>>conversions take place. >>> >>> I believe that there is not wheel to invent here, we just need to >>> have a look about what programming languages do (although >>> traditional programming languages -I've seen so far- don't deal with >>> that unbounded >>> (*) value). >>> >>> As a side note, in java, Integer object is not a subtype of Real one. >>> >>> Regards, >>> Adolfo. >>> On 24/07/2013 14:53, Steve Cook wrote: >>>> B2 seems the obvious choice to me. >>>> >>>>> Providing free conversion between unrelated types is not something >>>>>that I would like to try to justify to the academics. >>>> Lots of programming languages do it between numeric types.These >>>> types are not "unrelated", they are just not subtypes of one another. >>>> >>>>> it seems a bit odd to have plus-infinity without minus-infinity >>>> What "*" means is that a collection has unbounded size.A collection >>>> always has a non-negative size. >>>> >>>>> an early deprecation would avoid one source of user confusion >>>> Deprecating UnlimitedNatural in UML is just not going to happen, >>>>and taking OCL in a direction that widens the gap with UML is a >>>>poor strategy. >>>> >>>> -- Steve >>>> >>>> *From:*Ed Willink [mailto:ed@willink.me.uk] >>>> *Sent:* 24 July 2013 11:53 >>>> *To:* ocl2-rtf@omg.org >>>> *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>>> Preview 1) >>>> >>>> Hi >>>> >>>> It is certainly not the intention to require integer implementation >>>> using floating point; just to require that the Integer and Real (as >>>> well >>>> UnlimitedNatural) have a special larger-than-anything-else >>>> (infinity) value. How implementations choose to implement that >>>> special value is not defined by the OCL specification. >>>> >>>> Currently implementations are required to check that every implicit >>>> conversion from UnlimitedNatural to Integer converts * to /invalid/. >>>> I suspect that many implementations are broken here already and so >>>> allow the implementation convenience of -1 to become visible; we >>>> certainly had to fix problems with Eclipse OCL here. >>>> >>>> Whether there is a minus-infinity is possibly a separate issue, but >>>> it seems a bit odd to have plus-infinity without minus-infinity. >>>> >>>> I'm not clear what the relevance of your comment that Integers are >>>>not closed under division is. OCL currently specifies the type >>>>conversion to Real to guarantee a result (except divide by 0). There >>>>is a separate div operator if you want the limited precision of an >>>>Integer result. >>>> >>>> Arithmetic is currently specified for UnlimitedNatural. 11.5.5 >>>> defines >>>> +,*,/, etc (no -). Conversion to Integer occurs when the >>>> +capabilities of >>>> UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not >>>>available. >>>> >>>> We have two main choices to resolve the contradictory subtyping >>>> claims for UnlimitedNatural. See 11.4.1, 11.4.2. >>>> >>>> /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./ >>>> >>>> a) Make UnlimitedNatural a full subtype of Integer by introducing >>>> plus-infinity to Integer and Real (the current resolution proposal) >>>> >>>> b1) Make UnlimitedNatural unrelated to Integer with explicit >>>>conversion. >>>> - require positive integers to be parsed as Integer rather than >>>>UnlimitedNatural >>>> - require use of toInteger() to convert non-unlimited >>>>UnlimitedNatural to Integer >>>> - introduce and require use of toUnlimitedNatural() to convert >>>>non-negative Integer to UnlimitedNatural >>>> - retract all UnlimitedNatural arithmetic capabilities >>>> >>>> b2) Make UnlimitedNatural unrelated to Integer with implicit >>>>conversion. >>>> - allow implicit conversion of non-unlimited UnlimitedNatural to >>>>Integer >>>> - allow implicit conversion of non-negative Integer to >>>>UnlimitedNatural >>>> >>>> IMHO breaking the subtype contract will cause problems for programs >>>> that currently exploit the free conversion since OCL currently has >>>> numbers that grow in range/precision as required. Providing free >>>> conversion between unrelated types is not something that I would >>>> like to try to justify to the academics. >>>> >>>> The current specified arithmetic capabilities for UnlimitedNatural >>>> allow >>>> * to participate in comparisons and max/min operations without the >>>> special casing that UML specification engages in to work around the >>>> inadequacies of implementations that execute with -1 for *. >>>> (Implementations are already broken.) >>>> >>>> Introducing *-is-infinity to Integer would allow UnlimitedNatural >>>> to be eliminated altogether. UML need only specify that the >>>> lowerBound is finite and non-negative. (Actual elimination of >>>> UnlimitedNatural is probably out of the question for compatibility >>>> reasons, but an early deprecation would avoid one source of user >>>> confusion.) >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> On 24/07/2013 10:46, Steve Cook wrote: >>>> >>>>> Can the issue be that UnlimitedNatural is not really a subtype of >>>>>Integer? >>>> Absolutely. These numeric types are not subtypes of each other >>>> under any useful algebraic notion of substitutability. >>>>Integers are >>>> not closed under division, as Reals are. UnlimitedNaturals are >>>>only >>>> ever subject to comparison, and do not engage in arithmetic with >>>> each other or with other numbers. There is no value and only >>>> confusion in pretending that subtyping is going on. In practice, >>>> Integer maps to whatever your computer counts in its words and >>>>adds >>>> up in its CPU, and UnlimitedNatural is mapped to the same thing >>>>with >>>> a special value (usually -1) to represent *. >>>> >>>> There may be coercions, even implicit ones, but that is not the >>>>same >>>> thing. >>>> >>>> I see no value in introducing the idea of "minus unbounded" to >>>>OCL. >>>> Requiring all of these types to be implemented as floating point >>>> numbers, as is implied by the proposed resolution to 15780, will >>>> presumably invalidate all existing implementations of UML and OCL, >>>> and is a poor idea. >>>> >>>> -- Steve >>>> >>>> *From:*Ed Willink [mailto:ed@willink.me.uk] >>>> *Sent:* 23 July 2013 23:04 >>>> *To:* ocl2-rtf@omg.org >>>> *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 >>>> >>>> On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: >>>> >>>> Hi Ed, >>>> >>>> Some feedback about your document. >>>> >>>> Issue 15009 : >>>> Shorthand is used along OCL/QVT rather than shortform. >>>> >>>> Fixed in Preview 2 >>>> >>>> >>>> Since the new subsection is related to object >>>>navigation, I'm >>>> wondering if section 7.6 is more suitable for it. >>>> >>>> The idea was to get it in before navigation. Also one of the PAS >>>> issues complians about no ./-> in 7.5.8. >>>> >>>> >>>> >>>> Issue 15780 : >>>> 1. What does symbolic analysis mean? >>>> >>>> Analyzing an expression without evaluating it. >>>> >>>> >>>> 2. IEEE 754 alignment sounds like a UML2 misalignment. Note >>>> that UnlimitedNatural not only accommodates the need for an >>>> unlimited upper bound multiplicity, but also the lower bound >>>> value is constrained by not permitting the unbounded (or >>>> infinite) one by using the Integer type. With this proposal >>>>OCL >>>> is changing the semantics of Integer (and Real) given by UML. >>>> Can the issue be that UnlimitedNatural is not really a subtype >>>> of Integer (Looking at the varied >>>>Real-Integer-UnlimitedNatural >>>> operations, it looks like there is some Liskov substitution >>>> principle violation smell)?. Are we again dealing with a >>>> conformance related issue ?. >>>> >>>> I don't understand your point. >>>> >>>> There is no problem with UnlimitedNatural having fewer values (no >>>> negatives). The problem is an extra positive value. >>>> >>>> >>>> >>>> Issue 18437: >>>> OclAny defines post conditions for their library >>>>operations. >>>> I see no point why this should be different for the new >>>> operations on OclVoid and OclInvalid >>>> >>>> The OclAny postconditions had somethjing to say. >>>> I dont'tsee the point in padding out " Evaluates to true." with >>>> post: result = true. >>>> >>>> >>>> Issue 18464: >>>> OCL is mainly founded on (first-order) predicate logic and >>>> set theory. Could you provide a reference supporting your >>>> affirmation about why the algorithm is correct and the text >>>> incorrect ?. >>>> >>>> I don't understand your point. >>>> This is a fix for inconsistency in the wording, not an >>>>algorithm change. >>>> >>>> >>>> >>>> Issue 6600: >>>> I must be missing/misunderstanding something. I see a table >>>> of contents in the beginning. What's wrong with OCL 2.3 ? >>>> >>>> An Index is not the TOC. It is generally at the end. There is no >>>> index in OCL 2.3.1. >>>> >>>> >>>> >>>> Issue 6879-6882: >>>> We could argue about if shorthands are >>>>convenient/readable or >>>> not, but rationale like "but avoids introducing a "?" syntax >>>> irregularity" doesn't seem convincing for discarding the >>>>syntax >>>> enhancement. What does syntax irregularity mean ?. >>>> In general, I find aligning OCL-QVT syntax as a good idea. >>>>So >>>> unless you identify real problems of adopting this >>>>alignment, I >>>> don't see the point of closing these issues as no change. >>>> Borrowing your comment to discard other proposals: "The >>>> 'problems' have not prevented QVT tool being built" >>>> >>>> Nobody has demonstrated that QVTo has no limitations over the full >>>> OCL syntax in particular UML qualifiers. >>>> I'm not comfortable with the QVTo syntax extensions and the >>>>drift to >>>> be a non-Java Java.. >>>> I don't see that usage by QVTo requires adoption by OCL. >>>> I figure that if Mariano had really wanted these changes he would >>>> have put them to a ballot for OCL 2.2. >>>> >>>> >>>> Issue 6894: >>>> Better solution = no change ?? >>>> >>>> An additional library routine is not a change to the OCL language. >>>> >>>> >>>> Issue 7466: >>>> Should not every >>>>"self.condition.type.oclIsKindOf(Primitive) >>>> and self.condition.type.name = 'Boolean'" be changed by >>>> "self.condition.type = Boolean" ? >>>> I guess this could be deferred until specification >>>> generation is done. >>>> >>>> Yes. That is why half the issues cannot be addressed very >>>>profitably >>>> at present. We still have only visual OCL checking. >>>> >>>> >>>> >>>> Issue 14985: >>>> Resolution keyword missing, so summary and resolution is >>>> mixed in the summary section. >>>> >>>> No. The summary is what the original submitter wrote. I often >>>>write >>>> solutions in the submissions. >>>> The missing Resolution paragraph will be added in Preview 2. >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> >>>> >>>> Regards, >>>> Adolfo. >>>> -- >>>> On 22/07/2013 07:23, Ed Willink wrote: >>>> >>>> >>>> Hi >>>> >>>> Attached: Preview 1 of the Issues resolved in Ballot 1. >>>> >>>> The one week preview lasts from now until voting starts on >>>> 29th July. >>>> >>>> The two week voting period lasts from 29th July to 11th >>>>August. >>>> >>>> More details may be found in the preamble to the attached. >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3349 / Virus Database: 3204/6512 - Release >>>>Date: >>>> 07/22/13 >>>> >>>> >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >>>> 07/23/13 >>>> >>> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: >>07/24/13 > X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=AeFP_lyPgAIA:10 a=33RrB3tuMlcA:10 a=IkcTkHD0fZMA:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=SSmOFEACAAAA:8 a=yMhMjlubAAAA:8 a=KHpXyVWLAAAA:8 a=jb1_pgqOAAAA:8 a=pGLkceISAAAA:8 a=8pif782wAAAA:8 a=oCcaPWc0AAAA:8 a=8JZJKxNzb_czq1-MlFgA:9 a=GshvLCKpzNoSiOxT:21 a=ODRU7C1Jcig62lxU:21 a=688ilHte9tHfSpQH:21 a=QEXdDO2ut3YA:10 a=_W_S_7VecoQA:10 a=WP4_USCxRkkA:10 a=MSl-tDqOz04A:10 a=-AOE9ft50oIA:10 a=bzZ5MqCpzDcA:10 a=0TQ4etErN9wA:10 a=tv8P9toP7WUA:10 a=NWVoK91CQyQA:10 Date: Thu, 25 Jul 2013 12:31:33 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). > arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=qnuTKOuUk0BqjUt+0hr13oMnIwO8hw494gwiKWj22Ak=; b=Pjm8jZQGjwqgWIRyOlsj4V2zXPYUKfbISg2ohccqYW3Wz92uYVIIbtWRvPDuyjFYkD I2uHyizDyNHe2LIDmCHoHxIyAUF4FpjEYcembedDcHtAdCekp5yGiYB2fRVKGySWE2Lo l3BzMqjeTsq77mwBQEnI9SXikpKMsDD5+y3wFDIpaghw3kvJRJyBZM8lyQkCeDSCHLTJ oejhaC1pPZOsc9//n0Gp336SKdA/ewg9ieSVp90181B+apHBt5yDDZXMnpWoYGdSAJ6r yhWwPlK6nHIS6Ka/IDtLqWriTRPKAaBAjLBvRKRX4ysNJqS1+k8Sz+yfBHf8n9aIZWvb RViQ== X-Received: by 10.182.232.225 with SMTP id tr1mr35585451obc.69.1374752844705; Thu, 25 Jul 2013 04:47:24 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 25 Jul 2013 07:46:44 -0400 X-Google-Sender-Auth: BYoTywSaEqKGKwuSylhTU_Ju4gQ Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) To: Ed Willink Cc: "ocl2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=AeFP_lyPgAIA:10 a=33RrB3tuMlcA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=pGLkceISAAAA:8 a=SSmOFEACAAAA:8 a=KHpXyVWLAAAA:8 a=jb1_pgqOAAAA:8 a=8pif782wAAAA:8 a=yMhMjlubAAAA:8 a=gzeOtzoaAAAA:8 a=oCcaPWc0AAAA:8 a=89FD1TAuRE0QYkwhBuIA:9 a=ctvdrRosIHBAtpsA:21 a=H2tEIW7-_F4liDeW:21 a=68DyZQdDox56TH3x:21 a=pILNOxqGKmIA:10 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=WP4_USCxRkkA:10 a=MSl-tDqOz04A:10 a=-AOE9ft50oIA:10 a=bzZ5MqCpzDcA:10 a=tv8P9toP7WUA:10 a=NWVoK91CQyQA:10 Date: Thu, 25 Jul 2013 13:20:37 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 CC: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi Bran You write "Why is unlimited natural being interpreted here as "infinity"?" If you really mean UnlimitedNatural then perhaps you are taking the view that there is only a single UnlimitedNatural value, which leads to a very different discussion. If you mean the unlimited UnlimitedNatural, aligning 'unlimited' with 'infinity' is partly pragmatic, but partly realistic. It is indeed unspecified, but it is also guaranteed to be larger than any finite number I think of, so it is to all intents and purposes infinite. Typical implementations may implement a dynamically sized collection that expands until memory is exhausted. Arbitrarily enlargeable with more memory towards infinity, which is what one might expect; infinity is the asymptotic limit. Regards Ed Willink On 25/07/2013 12:46, Bran Selic wrote: Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=AeFP_lyPgAIA:10 a=33RrB3tuMlcA:10 a=-CRmgG0JhlAA:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=SSmOFEACAAAA:8 a=vrshd3w6AAAA:8 a=KHpXyVWLAAAA:8 a=gUbaYAUbAAAA:8 a=jb1_pgqOAAAA:8 a=pGLkceISAAAA:8 a=8pif782wAAAA:8 a=yMhMjlubAAAA:8 a=oCcaPWc0AAAA:8 a=BII_KVcC-fgNDK2Ti_EA:9 a=9c1b2U1HnOwI1pVr:21 a=FNFvUtlTR7W_V1He:21 a=jpF3rQSZZIMmGdB4:21 a=jiObf9B0YAUA:10 a=_W_S_7VecoQA:10 a=WP4_USCxRkkA:10 a=MSl-tDqOz04A:10 a=-AOE9ft50oIA:10 a=bzZ5MqCpzDcA:10 a=0TQ4etErN9wA:10 a=tv8P9toP7WUA:10 a=NWVoK91CQyQA:10 Date: Thu, 25 Jul 2013 13:37:41 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 CC: "ocl2-rtf@omg.org" , "uml25-ftf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi Nicolas http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double includes: The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' so no problem for reals. -1 is a very reasonable serialization pragmatism for UnlimitedNatural's unlimited value, so no problem beyond a mention in the serialization spec. Regards Ed Willink On 24/07/2013 22:25, Ed Seidewitz wrote: Nicolas -- I don't really think there is any issue with Real. The mapping to xsd:double is only for the purposes of model serialization, it's not a semantic definition. And the only Reals in a UML model that are serialized are the values of LiteralReals, which, given the textual syntax of Real literals in UML, will always be floating-point approximations of Reals. I am not sure that it is necessary to move to owl:real just because of the limited range of xsd:float, especially since we otherwise consistently use just the XSD type system. Even in the case of xsd:integer, in which the value space is nominally infinite, a processor can limit the number of digits allowed. The lack of mapping for UnlimitedNatural is an problem, but a much simpler solution (for the purposes of serialization) is to just map it to xsd:integer and specify that * maps to -1. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, July 24, 2013 4:53 PM To: Ed Willink; ocl2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I think that 15780 depends on resolving two problems with the PrimitiveTypes library from UML 2.4.1. 1) Real, which is inconsistently specified as the infinite set of mathematical real numbers but mapped to the finite set of double-precision floating-point arithmetic -- I.e., xsd:double. See http://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi A real is a primitive type representing the mathematical concept of real. The XMI mapping is inconsistent with the specification of PrimitiveTypes::Real. This can be easily fixed: PrimitiveTypes::Real can be mapped to owl:real, which is equivalently defined as the set of all real numbers (I.e., an infinite set) (see: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Real_Numbers.2C_Decimal _Numbers.2C_and_Integers) For backwards compatibility and practicality, it would make sense to define subtypes of PrimitiveTypes::Real and map them to practical representations of floating point numbers: PrimitiveTypes::Float and map it to xsd:float -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#float PrimitiveTypes::Double and map it to xsd:double -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double 2) UnlimitedNatural lacks a definition or mapping to an XML Schema 1.1 datatype The following definition conforms to both XML Schema 1.1 datatypes and the restrictions on the definition of datatype mappings for OWL2 (I.e., we can use it with OWL2 reasoners, SPARQL engines, etc.) * Should I raise an issue about this and propose the above as a resolution for ballot 8 of UML 2.5? - Nicolas. On 7/24/13 12:14 PM, "Ed Willink" wrote: Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=AeFP_lyPgAIA:10 a=33RrB3tuMlcA:10 a=-CRmgG0JhlAA:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=SSmOFEACAAAA:8 a=vrshd3w6AAAA:8 a=KHpXyVWLAAAA:8 a=gUbaYAUbAAAA:8 a=jb1_pgqOAAAA:8 a=pGLkceISAAAA:8 a=8pif782wAAAA:8 a=yMhMjlubAAAA:8 a=oCcaPWc0AAAA:8 a=BII_KVcC-fgNDK2Ti_EA:9 a=9c1b2U1HnOwI1pVr:21 a=FNFvUtlTR7W_V1He:21 a=jpF3rQSZZIMmGdB4:21 a=jiObf9B0YAUA:10 a=_W_S_7VecoQA:10 a=WP4_USCxRkkA:10 a=MSl-tDqOz04A:10 a=-AOE9ft50oIA:10 a=bzZ5MqCpzDcA:10 a=0TQ4etErN9wA:10 a=tv8P9toP7WUA:10 a=NWVoK91CQyQA:10 Date: Thu, 25 Jul 2013 13:37:41 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 CC: "ocl2-rtf@omg.org" , "uml25-ftf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi Nicolas http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double includes: The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' so no problem for reals. -1 is a very reasonable serialization pragmatism for UnlimitedNatural's unlimited value, so no problem beyond a mention in the serialization spec. Regards Ed Willink On 24/07/2013 22:25, Ed Seidewitz wrote: Nicolas -- I don't really think there is any issue with Real. The mapping to xsd:double is only for the purposes of model serialization, it's not a semantic definition. And the only Reals in a UML model that are serialized are the values of LiteralReals, which, given the textual syntax of Real literals in UML, will always be floating-point approximations of Reals. I am not sure that it is necessary to move to owl:real just because of the limited range of xsd:float, especially since we otherwise consistently use just the XSD type system. Even in the case of xsd:integer, in which the value space is nominally infinite, a processor can limit the number of digits allowed. The lack of mapping for UnlimitedNatural is an problem, but a much simpler solution (for the purposes of serialization) is to just map it to xsd:integer and specify that * maps to -1. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, July 24, 2013 4:53 PM To: Ed Willink; ocl2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I think that 15780 depends on resolving two problems with the PrimitiveTypes library from UML 2.4.1. 1) Real, which is inconsistently specified as the infinite set of mathematical real numbers but mapped to the finite set of double-precision floating-point arithmetic -- I.e., xsd:double. See http://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi A real is a primitive type representing the mathematical concept of real. The XMI mapping is inconsistent with the specification of PrimitiveTypes::Real. This can be easily fixed: PrimitiveTypes::Real can be mapped to owl:real, which is equivalently defined as the set of all real numbers (I.e., an infinite set) (see: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Real_Numbers.2C_Decimal _Numbers.2C_and_Integers) For backwards compatibility and practicality, it would make sense to define subtypes of PrimitiveTypes::Real and map them to practical representations of floating point numbers: PrimitiveTypes::Float and map it to xsd:float -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#float PrimitiveTypes::Double and map it to xsd:double -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double 2) UnlimitedNatural lacks a definition or mapping to an XML Schema 1.1 datatype The following definition conforms to both XML Schema 1.1 datatypes and the restrictions on the definition of datatype mappings for OWL2 (I.e., we can use it with OWL2 reasoners, SPARQL engines, etc.) * Should I raise an issue about this and propose the above as a resolution for ballot 8 of UML 2.5? - Nicolas. On 7/24/13 12:14 PM, "Ed Willink" wrote: Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=z5fIqN2AXGvRMsGOEzLED23qDHeJPUAFjT0cfy80tJA=; b=X0OO0xKwr+1dorncYkxnJT/0+ZdLXahzpEk14FKU61ESYNkXEpCAAdvOBjj3MTUBVe 2A2Y86lBjpJMJfRUPEVi7isQ2ePeke2kis9xa+A0aauDJiCByjUlySv6XKKJwFR75PuG wRLEbGWLJasH543qlHxS7kiSTLJAtlp3gDPlcYA0+oIuZztoCnKqIYhbfzhMPmQwsRNh pYxQRtC3eL8JBBVnMCSD/YfWhWEJjL1kk2VVLqjEc9wJgK+fc/P04K+yjDy5ML5ieAxk 2DFc2v37YqXK3EoWIJPeD0vpqbWUvP7vh1GUx+j3KEz8ZQ2WxTI8XPEhjgjEI+mOH3M6 Z7KA== X-Received: by 10.182.120.132 with SMTP id lc4mr35888388obb.22.1374756182736; Thu, 25 Jul 2013 05:43:02 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 25 Jul 2013 08:42:22 -0400 X-Google-Sender-Auth: GHKIRBWxpuikbY8kI2mRxPVUDWg Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) To: Ed Willink Cc: "ocl2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org On Thu, Jul 25, 2013 at 8:20 AM, Ed Willink wrote: If you mean the unlimited UnlimitedNatural, aligning 'unlimited' with 'infinity' is partly pragmatic, but partly realistic. [bvs] Hmm. I thought I was the one who was trying to be pragmatic. It is indeed unspecified, but it is also guaranteed to be larger than any finite number I think of, so it is to all intents and purposes infinite. [bvs] I strongly disagree with this interpretation, although I note that it is fairly common among UML users. I am not sure where your "guarantee" comes in here. "Unspecified" does not necessarily imply a number that is "larger than any finite number you can think of". From a modeling perspective, I think it is important to NOT interpret "*" as infinity. We do not normally model infinite things with UML. However, if that is what we want, then we should add an explicit concept of infinity. These are quite different things. Typical implementations may implement a dynamically sized collection that expands until memory is exhausted. Arbitrarily enlargeable with more memory towards infinity, which is what one might expect; infinity is the asymptotic limit. [bvs] Just a pedantic nit: there is, BTW, nothing asymptotic about the progression of natural numbers. Cheers...Bran X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC103.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -17 X-BigFish: VS-17(z21cRzbb2dI98dI9371Ic89bh601I936eI146fI542Ic85dhdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h17326ah18c673h1de097h1de096h1954cbh18602eh84d07h18de19h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: Bran Selic , Ed Willink CC: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdCAAAubAIAAEEYAgAEAuICAAAQ+AIAACA8g Date: Thu, 25 Jul 2013 13:02:40 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.105] X-OriginatorOrg: microsoft.com X-Virus-Scanned: amavisd-new at omg.org My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 From: "Rouquette, Nicolas F (313K)" To: Steve Cook , Bran Selic , "Ed Willink" CC: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAIAAEQYAgAD/+ICAAAQ+AIAAFTcA//+USoA= Date: Thu, 25 Jul 2013 13:37:12 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-impleementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which cann be named, such as large Ackermann numbers . which willl not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, --1, 0, 1, 2.). arguably that includes iinfinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC101.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -17 X-BigFish: VS-17(z21cRzbb2dI98dI9371Ic89bh601I936eI146fI542Ic857hdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h17326ah18c673h1de097h1de096h1954cbh18602eh84d07h18de19h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: "Rouquette, Nicolas F (313K)" , Bran Selic , Ed Willink CC: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdCAAAubAIAAEEYAgAEAuICAAAQ+AIAACA8ggAAWzwCAAARP4A== Date: Thu, 25 Jul 2013 13:56:51 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-OriginatorOrg: microsoft.com X-Virus-Scanned: amavisd-new at omg.org Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.aand is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . soome of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivablle computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). < arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-IronPort-AV: E=Sophos;i="4.89,743,1367967600"; d="scan'208,217";a="63957519" From: AKEHURST David To: "ocl2-rtf@omg.org" Date: Thu, 25 Jul 2013 15:24:13 +0100 Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdCAAAubAIAAEEYAgAEAuICAAAQ+AIAACA8ggAAivhA= Accept-Language: en-US, en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB X-SpamInfo: helo-dns, X-Virus-Scanned: amavisd-new at omg.org My question is: Is OCL a) A programming language, and thus required to address issues of number representation, memory limits etc. or b) A specification language, and thus better off drawing from formal and mathematical definitions ? From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 25 July 2013 14:03 To: Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=9Et+6TFyDJ2SXM21nP0gYktU0BqaVkfdx7mZsN3FrnE=; b=ZGNmB1bGnq0FrfOfau8WYFyDJntaUpz+maDRiTpAUDgw++XpT/kQR6/8KbzCCmigLR ONtL/b2BvOfgqx5pnBsJXP9/P5ut9+WaviP4ETWDLwrJj7LuKYKQJo6NnUYdywAmkgGG TIwR+O+Dpx9GyPYi1qy9dfc2jBz9/1bTpyLKXzee9/Nxb3iyDzCu3Y2/blVHRdkap2p4 d+hNiGCt3buoVdYvQMU05iHTCx485+nfn+AzwNNiU7O6/r4umYpCMXb9EEjRmmyWDQKI dkgVPN9jaw0pXcMRYTwjOVCwvhLj1ilzCERQFeUbTSpT/iRBaj04Xuegq6eGcm27XnBt +KuQ== X-Received: by 10.182.241.101 with SMTP id wh5mr37413510obc.49.1374763882825; Thu, 25 Jul 2013 07:51:22 -0700 (PDT) Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 25 Jul 2013 10:50:42 -0400 X-Google-Sender-Auth: UP0YwXVjlg8NwLaOdDqreDltXUg Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) To: AKEHURST David Cc: "ocl2-rtf@omg.org" X-Virus-Scanned: amavisd-new at omg.org A good question to ask, and one that I am sure we are unlikely to agree on, no matter how long we discuss. Much as I desire to put software development on a solid formal foundation, I am not sure that OCL is the right vehicle for that. This is because when OCL was introduced it was adjusted to support UML, which, for better or worse, is far from being a good starting point for a formal foundation -- even with all the good work around fUML. As we can see, we are already running into problems because of the divergence between the two (which is quite possibly due to attempts to make OCL a formal specification language). Ergo, I think that it would not make sense to move OCL too far away from where UML is. There are plenty of other formal (computer) languages that can and should be used as specification languages in the sense that I think David is looking for. Bran On Thu, Jul 25, 2013 at 10:24 AM, AKEHURST David wrote: My question is: Is OCL a) A programming language, and thus required to address issues of number representation, memory limits etc. or b) A specification language, and thus better off drawing from formal and mathematical definitions ? From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 25 July 2013 14:03 To: Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14MLTC103.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -18 X-BigFish: VS-18(z21cRzbb2dI98dI9371Ic89bh601I936eI146fI542Ic85dh1418Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah18c673h1de097h1de096h1954cbh18602eh84d07h18de19h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: Bran Selic , AKEHURST David CC: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdCAAAubAIAAEEYAgAEAuICAAAQ+AIAACA8ggAAivhCAAAiaAIAAATpw Date: Thu, 25 Jul 2013 14:56:16 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.102] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org I agree. In any case the question poses a false dichotomy. OCL is intended to be an implementable specification language. As such it is required to address issues of number representation, memory limits etc. Where it draws logical conclusions from statements about numbers, those conclusions should be the same as those that would be drawn from the mathematical formalizations of those statements. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 15:51 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) A good question to ask, and one that I am sure we are unlikely to agree on, no matter how long we discuss. Much as I desire to put software development on a solid formal foundation, I am not sure that OCL is the right vehicle for that. This is because when OCL was introduced it was adjusted to support UML, which, for better or worse, is far from being a good starting point for a formal foundation -- even with all the good work around fUML. As we can see, we are already running into problems because of the divergence between the two (which is quite possibly due to attempts to make OCL a formal specification language). Ergo, I think that it would not make sense to move OCL too far away from where UML is. There are plenty of other formal (computer) languages that can and should be used as specification languages in the sense that I think David is looking for. Bran On Thu, Jul 25, 2013 at 10:24 AM, AKEHURST David wrote: My question is: Is OCL a) A programming language, and thus required to address issues of number representation, memory limits etc. or b) A specification language, and thus better off drawing from formal and mathematical definitions ? From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 25 July 2013 14:03 To: Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC107.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -17 X-BigFish: VS-17(z21cRzbb2dI98dI9371Ic89bh601I936eI146fI542Ic857hdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h17326ah18c673h1de097h1de096h1954cbh18602eh84d07h18de19h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: "Rouquette, Nicolas F (313K)" CC: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdCAAAubAIAAEEYAgAEAuICAAAQ+AIAACA8ggAAWzwCAAARP4IAABDYAgAAP+dA= Date: Thu, 25 Jul 2013 15:30:48 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.100] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of whichh can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Virus-Scanned: OK From: Ed Seidewitz To: Steve Cook CC: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAIAAEQYAgAD/+ICAAAQ+AIAAFTcA//+USoCAAHragP//ja6AgABrCwD//9OZwA== Date: Thu, 25 Jul 2013 17:54:25 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.85.7] X-Virus-Scanned: amavisd-new at omg.org Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implemenntation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC105.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -18 X-BigFish: VS-18(z21cRzbb2dI98dI9371Ic89bh601I936eI146fI542I1418Ic857hdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h17326ah18c673h1de097h1de096h1954cbh18602eh84d07h18de19h8275bh8275dhz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) From: Steve Cook To: Ed Seidewitz CC: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwpqucG8b8NpUCbSWj7eGYADJlz0hHggAARcwCAAAryAIAAA0AggAAGljCAABUegIAAEQaAgAAJRdCAAAubAIAAEEYAgAEAuICAAAQ+AIAACA8ggAAWzwCAAARP4IAABDYAgAAP+dCAAC9fgIAABuIg Date: Thu, 25 Jul 2013 18:23:17 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.104] X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Scanned: amavisd-new at omg.org I suppose we could cook up some kind of union type of integer and a restriction of string. But then we.d have to publish that somewhere and refer to it, which seems like a lot of overhead, especially considering the laxity otherwise of potential XSD validation which we have decided not to do. -- Steve From: Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] Sent: 25 July 2013 18:54 To: Steve Cook Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring innter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuriing inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which ccan be named, such as large Ackermann numbers . which wiill not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). br> arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 From: "Rouquette, Nicolas F (313K)" To: Ed Seidewitz , Steve Cook CC: "uml25-ftf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAIAAEQYAgAD/+ICAAAQ+AIAAFTcA//+USoCAAHragP//ja6AgACMkgCAACgggP//k6KA Date: Thu, 25 Jul 2013 18:26:36 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve . On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementation rreproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementaation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named,, such as large Ackermann numbers . which will not fit iinto the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2..). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-Virus-Scanned: OK From: Ed Seidewitz To: "Rouquette, Nicolas F (313K)" , "Steve Cook" CC: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAIAAEQYAgAD/+ICAAAQ+AIAAFTcA//+USoCAAHragP//ja6AgABrCwD//9OZwAALsK0AAAo3lDA= Date: Thu, 25 Jul 2013 18:39:04 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.85.7] X-Virus-Scanned: amavisd-new at omg.org I have excessively mixed feelings about this. On the one hand, it does capture exactly what we want in terms of both the value space and lexical space for UnlimitedNatural. On the other hand, it means we have to add a little XSD as a normative artifact to what were previously all XMI artifacts (and I wouldn.t call it PrimitiveType.xsd, because that makes it seem like it should be an XSD corresponding to PrimitiveTypes.xmi per the MOF spec, or something like that). On the other other hand (!), I believe that the XSD can be completely ignored during model interchange, unless the importing tool is actually doing XSD validation on the elements in question. I.m still not sure where I come down on this. -- Ed From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, July 25, 2013 2:27 PM To: Ed Seidewitz; Steve Cook Cc: uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Here's what I propose: The XML Schema 1.1 DataTypes spec shows an example that corresponds to our PrimitiveTypes::UnlimitedLiteral in 2.4.1.3: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list 2.4.1.3 Union datatypes Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. It will be observed that the ·lexical mapping· of a union, so defined, is not necessarily a function: a given ·literal· may map to one value or to several values of different ·primitive· datatypes, and it may be indeterminate which value is to be preferred in a particular context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that specification in section xsi:type can be used to indicate which value a ·literal· which is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may be employed to determine which value is to be used. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes. Example A prototypical example of a ·union· type is the maxOccurs attribute on the element element in XML Schema itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string "unbounded", as shown below. So, for UML 2.5, we can define our PrimitiveTypes.xsd in a similar way to reflect the UML spec: Then the PrimitiveTypes.xmi would include PrimitiveTypes.xsd and would have the tag: That way, the XMI mapping preserves both the semantics and the syntax specified in the UML spec. - Nicolas. From: Ed Seidewitz Date: Thursday, July 25, 2013 10:54 AM To: Steve Cook Cc: "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve .> On UnlimitedNatural, the reason not to use string is that same reason not to use string for any of the other primitive types: to allow the XSD type system to be used to do some syntax checking for us on the serialized values. However, looking again at samples of current XMI, I think that .*. is generally what is being currently used to serialize *, so we need to preserve that in order not to upset interchange. That means we pretty much have to use string, as you say. -- Ed From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, July 25, 2013 11:31 AM To: Rouquette, Nicolas F (313K) Cc: uml25-ftf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas In the beta 2.5 PrimitiveTypes.xmi we have elements at the end such as: We are missing one for UnlimitedNatural. I suggest it needs to be: And we need some words in Annex E to say that UnlimitedNatural values are mapped to the string representation of their integer value or .*.. I can.t really imagine that .-1. is a good idea. Do you agree? If so we can include this in the .mop-up. ballot where we handle all of the XMI related issues. I.m not sure that the Real issue is a significant problem, but we can discuss on next week.s call if we have time. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 15:08 To: issues@omg.org Cc: uml25-ftf@omg.org Subject: FW: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Juergen, Can you please assign two issue numbers for the following: --------------- Title: PrimitiveTypes::Real is inconsistently specified relative to its mapping to xsd:double Summary: UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true --------------- Title: PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value Summary: Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'. The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:56 AM To: Nicolas Rouquette , Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Nicolas I think you are effectively raising two good UML issues. I don.t think they have much directly to do with OCL. -- Steve From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 25 July 2013 14:37 To: Steve Cook; Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Steve, You've been silent about the issue of mapping or defining Real and UnlimitedNatural. The MOF/XMI tag org.omg.xmi.schemaType allows reusing existing definitions of datatypes; however, doing so requires being careful in making sure that the specification of the datatype in UML is consistent with what it is mapped to. For Real, there is definitely an inconsistency. UML says: An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will internally represent Real numbers using a floating point standard such as ISO/IEC/IEEE 60559:2011 (whose content is identical to the predecessor IEEE 754 standard). Mapping this to xsd:double is just wrong: xsd:double has finite cardinality; PrimitiveTypes::Real has infinite cardinality. xsd:double has both upper and lower limits; PrimitiveTypes::Real has no such limits. 3.3.5 double -- http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double [Definition:] The double datatype is patterned after the IEEE double-precision 64-bit floating point datatype [IEEE 754-2008]. Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between float and double are the three defining constants 53 (vs 24), .1074 (vs .149), and 971 (vs 104). 3.3.5.1 Value Space The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. In addition to these values, the ·value space· of double also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber. Note: As explained below, the ·lexical representation· of the double value notANumber is 'NaN'. Accordingly, in English text we generally use 'NaN' to refer to that value. Similarly, we use 'INF' and '.INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '.0' to refer to positiveZero and negativeZero. Equality and order for double are defined as follows: Equality is identity, except that 0 = .0 (although they are not identical) and NaN . NaN (although NaN is of course identical to itself). 0 and .0 are thus equivalent for purposes of enumerations, identity constraints, and minimum and maximum values. For the basic values, the order relation on double is the order relation for rational numbers. INF is greater than all other non-NaN values; .INF is less than all other non-NaN values. NaN is ·incomparable· with any value in the ·value space· including itself. 0 and .0 are greater than all the negative numbers and less than all the positive numbers. Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·. In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty. If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived using the pattern 'NaN'). Note: The Schema 1.0 version of this datatype did not differentiate between 0 and .0 and NaN was equal to itself. The changes were made to make the datatype more closely mirror [IEEE 754-2008]. 3.3.5.2 Lexical Mapping The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' Lexical Space [5] doubleRep ::= noDecimalPtNumeral | decimalPtNumeral | scientificNotationNumeral | numericalSpecialRep The doubleRep production is equivalent to this regular expression (after whitespace is eliminated from the expression): (\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)? |(\+|-)?INF|NaN The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-2008]. That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used. Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, is a function, satisfies the requirements of [IEEE 754-2008], and correctly handles the mapping of the literals 'INF', 'NaN', etc., to the ·special values·, satisfies the conformance requirements of this specification. Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·. The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible.and is thus usefuul for insuring inter-implementation reproducibility and inter-implementation round-tripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)]. Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)]. The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·. Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-2008]. 3.3.5.3 Facets The double datatype and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown: whiteSpace = collapse (fixed) Datatypes derived by restriction from double may also specify values for the following ·constraining facets·: pattern enumeration maxInclusive maxExclusive minInclusive minExclusive assertions The double datatype has the following values for its ·fundamental facets·: ordered = partial bounded = true cardinality = finite numeric = true There are several ways to fix this. If we want to retain the mapping to xsd:double, then PrimitiveTypes::Real should be changed to match what the XML Schema 1.1 Datatypes spec says. If we want to retain the ideal of "mathematical infinite set of real numbers", then we can't map PrimitiveTypes::Real to xsd:double. In this case, we could consider defining subtypes of Real that would semantically and syntactically correspond to their mapping into xsd:float and xsd:double. For UnlimitedNatural, it is really bad that UML specifies NO XML-compatible serialization. That is, some tools use "*" and some tools use "-1". This poses an interoperability problem. - Nicolas. From: Steve Cook Date: Thursday, July 25, 2013 6:02 AM To: Bran Selic , Ed Willink Cc: "ocl2-rtf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers .. some of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivvable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From:bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). argarguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-TCPREMOTEIP: 173.54.119.233 X-Authenticated-UID: tom@coastenterprises.com Date: Thu, 25 Jul 2013 20:19:13 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Steve Cook CC: Bran Selic , AKEHURST David , "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org On 7/25/2013 10:56 AM, Steve Cook wrote: I agree. In any case the question poses a false dichotomy. IEEE floating point has +- infitity as code points. Does OCL have a float type which maps to IEEE floating point Tom OCL is intended to be an implementable specification language. As such it is required to address issues of number representation, memory limits etc. Where it draws logical conclusions from statements about numbers, those conclusions should be the same as those that would be drawn from the mathematical formalizations of those statements. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 15:51 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) A good question to ask, and one that I am sure we are unlikely to agree on, no matter how long we discuss. Much as I desire to put software development on a solid formal foundation, I am not sure that OCL is the right vehicle for that. This is because when OCL was introduced it was adjusted to support UML, which, for better or worse, is far from being a good starting point for a formal foundation -- even with all the good work around fUML. As we can see, we are already running into problems because of the divergence between the two (which is quite possibly due to attempts to make OCL a formal specification language). Ergo, I think that it would not make sense to move OCL too far away from where UML is. There are plenty of other formal (computer) languages that can and should be used as specification languages in the sense that I think David is looking for. Bran On Thu, Jul 25, 2013 at 10:24 AM, AKEHURST David wrote: My question is: Is OCL a) A programming language, and thus required to address issues of number representation, memory limits etc. or b) A specification language, and thus better off drawing from formal and mathematical definitions ? From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 25 July 2013 14:03 To: Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=AeFP_lyPgAIA:10 a=33RrB3tuMlcA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=N0wMqbuEAAAA:8 a=yMhMjlubAAAA:8 a=pGLkceISAAAA:8 a=KHpXyVWLAAAA:8 a=jb1_pgqOAAAA:8 a=SSmOFEACAAAA:8 a=8pif782wAAAA:8 a=gzeOtzoaAAAA:8 a=oCcaPWc0AAAA:8 a=omOdbC7AAAAA:8 a=WKhHmJ3F_YaWq-DAUOAA:9 a=Lr6NWGNqnCkN_H5T:21 a=dTz-CxlKwf-Xfv3l:21 a=9P1i4MxD03Mkh5Gv:21 a=wPNLvfGTeEIA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=tXsnliwV7b4A:10 a=p9IarpkInBgA:10 a=MSl-tDqOz04A:10 a=WP4_USCxRkkA:10 a=-AOE9ft50oIA:10 a=tv8P9toP7WUA:10 a=NWVoK91CQyQA:10 Date: Fri, 26 Jul 2013 06:54:41 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 CC: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi I'm slightly surprised that after twenty years we are suddenly asking what OCL primitive types are. They are the implementable form of the very abstract primitive types specified by UML. UML imposes no requirement that Real is 64 bits, and so neither does OCL. OCL has no types that map to any concrete representation. Boolean and String are close but have null and invalid to consider. There is just the one Real type with no specified equivalence to float/double/... OCL 2.3.1 11.4.1: The standard type Real represents the mathematical concept of real. There is actually no mention of infinity in regard to Real, so perhaps the OCL abstract syntax supports infinity and it was an oversight, when in OCL 2.3, I defined the Real concrete syntax that I omitted infinity. Similarly: OCL 2.3.1 11.4.2: The standard type Integer represents the mathematical concept of integer. which I interpret as a cherry picking of the Real number space to provide a useful and efficient form of Reals with no fractional part. Everything that can be done with Reals can be done with Integers by reverting the cherry picking back to Real. OCL 2.3.1 11.4.5: The standard type UnlimitedNatural is used to encode the non-negative values of a multiplicity specification. This includes a special unlimited value (*) that encodes the upper value of a multiplicity specification. I interpret this as a further cherry picking to discard negative numbers, except that we add a special value. (We too can easily refer to this as unbounded, rather than unlimited; it's just a bit wierd changing the special value of UnlimitedNatural from unlimited to unbounded). We could unpick the OCL 2.3.1 subtype relationship by making UnlimitedNatural as orthogonal as String and Boolean and Integer are, but IMHO that would mandate explicit conversions, and probably a "u" suffix to distinguish 1u as UnlimitedNatural from 1 as Integer. I do not see the relevance of Steve's comment Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. I fully agree that the arithmetic of numbers with units adds additional complexity. However there is nothing in OCL to say that a size is a dimensional unit. Indeed comparing a size against 0.25 of a capacity is a standard test to determine whether it is appropriate to grow a dynamically sized hash table. ========= From an implementer's point of view, whenever I am dealing with concrete types, I need to identify the associated behavioural-type, so that the appropriate OCL operation signature is identified for use in the OCL AST. At run-time, the concrete values are converted from the concrete representation to a form that the OCL engine is able to work with for the specified signature. On completion of an OCL evaluation the result is converted to to the concrete represtation, potentially resulting in an invalid result if the result is not representable. Therefore using 32 bit concrete representations: (100000 * 100000) / 100000 is a calculation that does not overflow, since ultimately the arithmetic uses the mathematical concept of real. The only time where I find that unlimited precision is a specification problem for OCL is for division. What is the accuracy with which the result of 1 / 3 is calculated? Practical engines will probably opt for 'double'. From a hardware synthesizers's point of view I find the inability to specify fine grained precisions such as 7-bit accuracy very frustating. This could be done in Executable UML but it never made it into UML 2.x. It is necessary to use profiles to fully characterize UML data types, so an OCL engine should respect these. I haven't been synthesizing recently; I expect that MARTE provides what is required. Regards Ed Willink On 26/07/2013 01:19, Tom Rutt wrote: On 7/25/2013 10:56 AM, Steve Cook wrote: I agree. In any case the question poses a false dichotomy. IEEE floating point has +- infitity as code points. Does OCL have a float type which maps to IEEE floating point Tom OCL is intended to be an implementable specification language. As such it is required to address issues of number representation, memory limits etc. Where it draws logical conclusions from statements about numbers, those conclusions should be the same as those that would be drawn from the mathematical formalizations of those statements. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 15:51 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) A good question to ask, and one that I am sure we are unlikely to agree on, no matter how long we discuss. Much as I desire to put software development on a solid formal foundation, I am not sure that OCL is the right vehicle for that. This is because when OCL was introduced it was adjusted to support UML, which, for better or worse, is far from being a good starting point for a formal foundation -- even with all the good work around fUML. As we can see, we are already running into problems because of the divergence between the two (which is quite possibly due to attempts to make OCL a formal specification language). Ergo, I think that it would not make sense to move OCL too far away from where UML is. There are plenty of other formal (computer) languages that can and should be used as specification languages in the sense that I think David is looking for. Bran On Thu, Jul 25, 2013 at 10:24 AM, AKEHURST David wrote: My question is: Is OCL a) A programming language, and thus required to address issues of number representation, memory limits etc. or b) A specification language, and thus better off drawing from formal and mathematical definitions ? From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 25 July 2013 14:03 To: Bran Selic; Ed Willink Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) My position is this. There are three data types being discussed: Integer, Real and UnlimitedNatural. Integers are used for counting things. In any platform, there may or may not be a well-defined implementation limit on this set. Whether there is or not, there exists an infinite number of integers . some of which can be named, such as large Ackermann numbers . which will not fit into the memory of any conceivable computer. But for all practical purposes, users of OCL will only ever use small integers. There is no reason at all to have an explicit representation of .infinity., whatever that means (see Bran.s message) in the integers; any requirement to do so will increase the implementation overhead without any discernable benefit. Reals are floating point numbers. Please let.s not get into discussions about irrational and transcendental numbers, countability, or the continuum hypothesis. In practice, reals are represented by well-known standards and executed with limited precision using pre-existing algorithms. IEEE 754 has a notion of infinity, which actually just mean .too big.. My ex-colleague and IBM Fellow Mike Cowlishaw spent much of his working life sorting out how these things operate. Reusing this work is a good idea. Trying to improve on it (in the context of the OCL RTF) is not. UnlimitedNaturals are numbers that represent bounds on the size of collections. Clearly they cannot be negative. * means that no upper size is specified. It does not, of course, mean that the size of the collection is infinite, or ever could be. Trying to fit all of these three into a subtype hierarchy is problematical. Making a hierarchy implies that expressions involving all operators that operate on the supertypes will also be valid over subtype values. The relevant operators are the arithmetic and comparison ones: +, -, *, /, >, <, =. Some combinations make perfect sense: Int + Int -> Int, Int + Real ->Real, Int / Int -> Real, Unlimited < Unlimited -> Boolean, etc. Some combinations do not make sense, for example Real * Unlimited. It means nothing to multiply the bound of a collection by a real number. It.s as absurd as multiplying the voltage supply to my house by the number of trees in my garden. There could also be explicit operators that convert between one type and another: round, floor, truncate, etc. To resolve these conundrums, rather than trying to impose an unnatural type hierarchy in which the senseless becomes indistinguishable from the sensible, we need a scheme so that expressions that make sense are easy to express and those that do not will cause an informative error. This may perhaps be resolved by a set of implicit conversions, such as: - all integers can convert to reals - all non-negative integers can convert to UnlimitedNatural Or perhaps by simply enumerating all of the combinations that are allowed. Perhaps the two approaches are equivalent. Anyway, here is where the energy needs to be spent. -- Steve From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 25 July 2013 12:47 To: Ed Willink Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Again, I can't resist since people are starting to invoke some deep theory here: Why is unlimited natural being interpreted here as "infinity"? The latter is a dubious concept even in mathematics (viz the "constructivist" approach to math by Brouer et al.), let alone in something so down-to-Earth as OCL/UML. It really just means unspecified -- but finite -- upper limit, certainly not infinity. No need to respond...just had to get it off my chest. Bran On Thu, Jul 25, 2013 at 7:31 AM, Ed Willink wrote: Hi Steve OCL users who understand the difference between Integer and UnlimitedNatural may use Collection(UnlimitedNatural) wherever they know that the values are non-negative. This certainly breaks Eclipse OCL JUnit tests, but they are not realistic programs. The number of such users is probably small, and UnlimitedNatural is more typing than Integer so again the usage is probably small. ============================================================================ In OCL 2.0, UnlimitedNatural was totally unspecified. Graphically, an UnlimitedNaturalExp hosted an UnlimitedNatural with no accompanying words. There was something called UnlimitedInteger with only two lines of superficial description. The standard type UnlimitedInteger is used to encode the upper value of a multiplicity specification. UnlimitedInteger is itself an instance of the metatype UnlimitedIntegerType. In OCL 2.2, the UnlimitedInteger typo was corrected to UnlimitedNatural, but no editorial content was added. The two line spec was very unhelpful and could be read to imply that the UnlimitedNatural type comprised the singleton value unlimited. This would not support the UML requirement for UnlimitedNatural as a cardinailty; all non-negative integers and unlimited. In OCL 2.3, I tried to make UnlimitedNatural compatible with the UML number range and integrated with the rest of the OCL Numbers. The subtyping irregularity is noted in 11.4.5 by: Note that although UnlimitedNatural is a subclass of Integer, the unlimited value cannot be represented as an Integer. Any use of the unlimited value as an integer or real is replaced by the invalid value. So the detailed problems we're now addressing were not a problem prior to OCL 2.3 because anything that the user got was entirely implementation dependendent. This means that no valid program relying on Set(UnlimitedNatural) conformance could predate OCL 2.3. ============================================================================ Overall we have three options for the UnlimitedNatural/Integer relationship No change: retain OCL 2.3's irregular subtyping Regular subtyping: introduce +infinity No subtyping: revert OCL 2.3 and respecify UnlimitedNatural as an unrelated type, and then figure out how to specify an emulation of the missing relationship. ============================================================================ I fail to understand why introduction of +infinity causes such dismay. UML 2.5 Beta says in 21.2 An instance of Integer is a value in the (infinite) set of integers (.-2, -1, 0, 1, 2.). arguably that includes infinity. An instance of Real is a value in the (infinite) set of real numbers. Typically an implementation will represent Real numbers using a floating point standard such as IEEE 754. This strongly suggests that +/- infinity is supported by UML. So OCL's incompatibility with IEEE 754 (requiring all +/-infinity values to be converted to invalid) imposes a needless complexity for implementers who might otherwise just use IEEE 754 hardware/library routines as-is. (As a specification language, I see no utility in consistent implementation of infinity by OCL, I just see no reason for OCL to deviate unnecessarily from the de facto behaviours, particularly when conforming solves a problem for us). ============================================================================= As regard XMI serialisation, OCL uses http://www.w3.org/TR/xmlschema-2/#double where The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively. so there is full serialization support for *, -*, invalid. Not supporting these in OCL is arguably an unspecified limitation. ============================================================================= I must stress again that where I refer to IEEE 754 for OCL, I am not requiring OCL to be implemented with any particular precision. OCL as a specification language is unlimited, which if realized by implementations could be a burden. So the user's specification-to-code transformations must assign adequate precisions to all calculations. This might be a simple 32 bits everywhere, or a more intelligent determination from specified characteristics of datatypes and calculations. For instance, Ecore users may impose the stereotype to associate a specific numeric behaviour. Specific precisions may be very beneficial where code is inherently efficient. However, where there is a bit of polymorphism overhead anyway, OCL's unlimited Integers need not be costly; the new implementation of Eclipse OCL has integers that automatically grow from Integer to Long to BigInteger as required and overall they actually work faster than the old Eclipse OCL that maxed out at Long. Note that a benefit if OCL's unlimited calculations is that there is never an arithmetic overflow during addition or subtraction. Many implementation languages have a silent wraparound for 32 bit overflows. IMHO a specification language should never give wrong results in this way. Regards Ed Willink On 24/07/2013 21:15, Steve Cook wrote: Do you have a practically useful example of a Set(UnlimitedNatural)? How many existing programs are we talking about? -- Steve -----Original Message----- From: Ed Willink [mailto:ed@willink.me.uk] Sent: 24 July 2013 20:14 To: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6520 - Release Date: 07/25/13 X-Virus-Scanned: OK From: Ed Seidewitz To: Ed Willink CC: "ocl2-rtf@omg.org" , "uml25-ftf@omg.org" Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAryAIAACMKAgAAD7oCAABJDgIAAEQeAgAAMLQCAAAizAP//pjsAgAAF2NCAAVXegIABVVlw Date: Fri, 26 Jul 2013 14:02:01 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.178.85.7] X-Virus-Scanned: amavisd-new at omg.org Ed . The issue is that the value space of double has a limited range: The ·value space· of double contains the non-zero numbers m ×2e , where m is an integer whose absolute value is less than 253, and e is an integer between .1074 and 971, inclusive. Also, of course, floating point numbers are actually a subset of rational numbers, and can only provide approximations for irrational numbers (or rational numbers that require more than finite precision). However, as I noted to Nicolas, I don.t think this is a practical problem, since we the context here is defining the serialization of UML models, which is lexical/syntactic, not semantic. -- Ed From: Ed Willink [mailto:ed@willink.me.uk] Sent: Thursday, July 25, 2013 8:38 AM Cc: ocl2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Nicolas http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double includes: The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '+INF', '-INF', and 'NaN' so no problem for reals. -1 is a very reasonable serialization pragmatism for UnlimitedNatural's unlimited value, so no problem beyond a mention in the serialization spec. Regards Ed Willink On 24/07/2013 22:25, Ed Seidewitz wrote: Nicolas -- I don't really think there is any issue with Real. The mapping to xsd:double is only for the purposes of model serialization, it's not a semantic definition. And the only Reals in a UML model that are serialized are the values of LiteralReals, which, given the textual syntax of Real literals in UML, will always be floating-point approximations of Reals. I am not sure that it is necessary to move to owl:real just because of the limited range of xsd:float, especially since we otherwise consistently use just the XSD type system. Even in the case of xsd:integer, in which the value space is nominally infinite, a processor can limit the number of digits allowed. The lack of mapping for UnlimitedNatural is an problem, but a much simpler solution (for the purposes of serialization) is to just map it to xsd:integer and specify that * maps to -1. -- Ed -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, July 24, 2013 4:53 PM To: Ed Willink; ocl2-rtf@omg.org; uml25-ftf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) I think that 15780 depends on resolving two problems with the PrimitiveTypes library from UML 2.4.1. 1) Real, which is inconsistently specified as the infinite set of mathematical real numbers but mapped to the finite set of double-precision floating-point arithmetic -- I.e., xsd:double. See http://www.omg.org/spec/UML/20110701/PrimitiveTypes.xmi A real is a primitive type representing the mathematical concept of real. The XMI mapping is inconsistent with the specification of PrimitiveTypes::Real. This can be easily fixed: PrimitiveTypes::Real can be mapped to owl:real, which is equivalently defined as the set of all real numbers (I.e., an infinite set) (see: http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#Real_Numbers.2C_Decimal _Numbers.2C_and_Integers) For backwards compatibility and practicality, it would make sense to define subtypes of PrimitiveTypes::Real and map them to practical representations of floating point numbers: PrimitiveTypes::Float and map it to xsd:float -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#float PrimitiveTypes::Double and map it to xsd:double -- see: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#double 2) UnlimitedNatural lacks a definition or mapping to an XML Schema 1.1 datatype The following definition conforms to both XML Schema 1.1 datatypes and the restrictions on the definition of datatype mappings for OWL2 (I.e., we can use it with OWL2 reasoners, SPARQL engines, etc.) * Should I raise an issue about this and propose the above as a resolution for ballot 8 of UML 2.5? - Nicolas. On 7/24/13 12:14 PM, "Ed Willink" wrote: Hi The problem that concerns me is that without subtyping a Set(UnlimitedNatural) ceases to conform to a Set(Integer) so we either break existing programs or write in special case type conversion rules that sort of do subtyping without calling it such. Presumably conformsTo is one place where the no-longer-subtype must be re-instated, but if we modify conformsTo to allow compatibility is it really the case that the subtype relationship does not exist? conformsTo does not have access to the run-time values so cannot tell whether an 'unlimited' value will be involved. I see a much greater mess than the current inaccuracy. Regards Ed Willink On 24/07/2013 19:43, Steve Cook wrote: I am just as likely to be wrong as anybody on this or any other topic, so don't take my word for anything. But I do think that OCL is supposed to be a practical and economically implementable language that aligns with UML. Personally I really like using the OCL Integer and Real with the subtype/subset relationship I am interested in why. In particular, would you not get just as nice an experience with an implicit coercion scheme? -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 19:00 To: Bran Selic Cc: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Am happy to take on board the opinion of any experts, was just trying to understand? -----Original Message----- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: 24 July 2013 17:59 To: AKEHURST David Cc: ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Just a clarification: Platform independence does not mean platform ignorance. In practical terms, it means defining a boundary (envelope, if you like) of platforms that you are independent of. This point is much misunderstood. BTW, Steve may be to humble to mention it, but he is THE inventor of OCL. I would tend to take his word on what sits behind it. Cheers... Bran On 2013-07-24, at 5:53 PM, AKEHURST David wrote: http://en.wikipedia.org/wiki/Integer "The set of integers is a subset of the real numbers" The desire for subtyping between these types is misplaced. It is unnecessary. that depends on your perspective, context, where your are coming from. I am not an expert in maths/algebra/formal computing/etc...so I shall leave the debate to those who are, My point was that I believe that OCL has its roots in formal maths, not in programming languages. The issue of IEEE floating point numbers etc, is a number representation issue, due to the underlying (platform specific) architecture of the processors we use. I thought that a key part of MDA, UML, OCL etc is that of Platform Independence...(PIMs etc) why should they care about restrictions on number representation caused by platform specific issues? The "programming language practical solutions" are platform specific issues are they not? Personally I really like using the OCL Integer and Real with the subtype/subset relationship. -----Original Message----- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 24 July 2013 16:39 To: AKEHURST David; ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) a subtype (subset) Subtype does not mean subset. It means algebraically substitutable. There is no plausible implementation which will maintain correct substitutability of integers of either limited or arbitrary size and IEEE 754 floating point numbers, in a mathematically correct sense. If the integers have limited size they can overflow and break the substitutability; if they have arbitrary size they can exceed the precision of the floats. The only way that these things could be made to align mathematically would be to use floats for everything. The desire for subtyping between these types is misplaced. It is unnecessary. Programming languages have acceptable practical solutions to these problems: as long as when a program exceeds the limits of the implementation an exception is thrown. -- Steve -----Original Message----- From: AKEHURST David [mailto:David.Akehurst@uk.thalesgroup.com] Sent: 24 July 2013 16:08 To: ocl2-rtf@omg.org Subject: RE: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) we just need to have a look about what programming languages not sure that that is a good idea, My understanding is that OCL has always had a much more mathematically correct semantics than 'programming languages', especially w.r.t. Integer being a subtype (subset) of Real. perhaps one should look at formal languages/mathematics to determine the solution! -----Original Message----- From: Adolfo Sanchez Barbudo [mailto:adolfosbh@opencanarias.es] On Behalf Of Adolfo Sáhez-Barbudo Herrera Sent: 24 July 2013 15:29 To: Steve Cook Cc: Ed Willink; ocl2-rtf@omg.org Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not "unrelated", they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What "*" means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the +capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of "minus unbounded" to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = 'Boolean'" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6517 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=M7Z0dUAs c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=AeFP_lyPgAIA:10 a=33RrB3tuMlcA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=r-WHsdA3mwjKIuf0XGUA:9 a=JYNItmM-UMXnwKce:21 a=MMwaUWEFUzaaN00F:21 a=pILNOxqGKmIA:10 a=WP4_USCxRkkA:10 Date: Fri, 26 Jul 2013 18:58:18 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi Changing Eclipse OCL to remove the UnlimitedNatural / Integer subtyping relationship is quite interesting. The library modeling breaks because there is no conversion of integer literals parsed as UnlimitedNatural. If the parsing is changed the problems are largely where tests explicitly mention UnlimitedNatural. We really just need to go back to a much simpler time. In OCL 1.x there was only Real, Integer OCL 2.0 'caught up' with UML 1.x by mentioning but not specifying UnlimitedInteger OCL 2.2 'caught up' with UML 2.0 by mentioning but not specifying UnlimitedNatural OCL 2.3 specified UnlimitedNatural as part of a 'coherent' type system for numbers Nothing in the core of OCL uses UnlimitedNatural; all operations such as at(), substring(), indexOf() use Integer values. UnlimitedNatural need never exist for ordinary users but for the parsing specification. Positive integers have UnlimitedNatural type and so permit conversion to Integer or Real as required. So UnlimitedNatural is a "monstrous carbuncle on the face of a much-loved and elegant friend". We could treat it as such. It can be an orthogonal type useable only by Integer.toNatural() and UnlimitedNatural.toInteger(). It can have very limited arithmetic capabilities: addition, comparison, max/min. If users learn to avoid it then the inconvenience of explicit conversions will be limited to those rare occasions when complex calculations on cardinalities are required. I much prefer the requirement for explicit conversions for these unsafe conversions. I don't like allowing unsafe conversions to be implicit. However, if really necessary, we can make this less painful for existing OCL by only mandating the explicit conversion in the AST; the CS to AS conversion can automatically synthesize the operation just as is necessary for oclAsSet() and implicit collect(). Reverting UnlimitedNatural to a carbuncle requires two breaking changes (wrt OCL 2.3) - remove the UnlimitedNatural / Integer subtyping specification - specify that integer literals are parsed with Integer type The latter parsing specification is hardly a breakage, since Clause 9 is not yet clear enough to tell how literals are disambiguated at all. We can probably ensure that typical UnlimitedNatural usage such as in the UML OCL will be unaffected. It will only be OCL users that attempt to use UnlimitedNatural as a narrow arithmetic type that will have trouble. [NB. This discussion is now completely orthogonal to whether OCL supports infinity or not for Real or Integer.] Regards Ed Willink On 24/07/2013 15:53, Ed Willink wrote: HI Indeed more than 5 minutes thought. I'll see what happens to Eclipse OCL if we remove the subtyping relationship. If only a few eccentric unit tests need revision, I'll revise this resolution for Ballot 3. If the consequences are nastier we'll have to wait till we're more confident of a better direction than the status quo. It may just be necessary to carefully identify all the scenarios in which we need to specify an unrelated type conversion between Integer and UnlimitedNatural. Either way this resolution is withdrawn from Ballot 1. Regards Ed Willink On 24/07/2013 15:28, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not .unrelated., they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What .*. means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: >Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of .minus unbounded. to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = .Boolean." be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Topic: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Thread-Index: AQHOiFwVCkFYL6d9LkmqyxiEcOLYd5l0TwMAgAAJ2gCAAAbogIADWEYA//+hCYA= Date: Fri, 26 Jul 2013 19:18:26 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r6QJIZjf007745 Ed, I wrote a resolution for UML 2.5 issue 18831 that defines UnlimitedNatural by mapping to a new XML schema datatype, unlimitedNatural, defined as the xsd:union of xsd:nonNegativeInteger and of an xsd:enumeration consisting of the symbol "*". How could I use OCL to specify arithmetic operations for UnlimitedNatural and conversions to/from other datatypes given its mapping to an XML schema unlimitedNatural as described above? - Nicolas. On 7/26/13 10:58 AM, "Ed Willink" wrote: >Hi > >Changing Eclipse OCL to remove the UnlimitedNatural / Integer subtyping >relationship is quite interesting. The library modeling breaks because >there is no conversion of integer literals parsed as UnlimitedNatural. >If the parsing is changed the problems are largely where tests >explicitly mention UnlimitedNatural. > >We really just need to go back to a much simpler time. > >In OCL 1.x there was only Real, Integer >OCL 2.0 'caught up' with UML 1.x by mentioning but not specifying >UnlimitedInteger >OCL 2.2 'caught up' with UML 2.0 by mentioning but not specifying >UnlimitedNatural >OCL 2.3 specified UnlimitedNatural as part of a 'coherent' type system >for numbers > >Nothing in the core of OCL uses UnlimitedNatural; all operations such as >at(), substring(), indexOf() use Integer values. UnlimitedNatural need >never exist for ordinary users but for the parsing specification. >Positive integers have UnlimitedNatural type and so permit conversion to >Integer or Real as required. > >So UnlimitedNatural is a "monstrous carbuncle on the face of a >much-loved and elegant friend". We could treat it as such. It can be an >orthogonal type useable only by Integer.toNatural() and >UnlimitedNatural.toInteger(). It can have very limited arithmetic >capabilities: addition, comparison, max/min. If users learn to avoid it >then the inconvenience of explicit conversions will be limited to those >rare occasions when complex calculations on cardinalities are required. >I much prefer the requirement for explicit conversions for these unsafe >conversions. I don't like allowing unsafe conversions to be implicit. >However, if really necessary, we can make this less painful for existing >OCL by only mandating the explicit conversion in the AST; the CS to AS >conversion can automatically synthesize the operation just as is >necessary for oclAsSet() and implicit collect(). > >Reverting UnlimitedNatural to a carbuncle requires two breaking changes >(wrt OCL 2.3) >- remove the UnlimitedNatural / Integer subtyping specification >- specify that integer literals are parsed with Integer type > >The latter parsing specification is hardly a breakage, since Clause 9 is >not yet clear enough to tell how literals are disambiguated at all. > >We can probably ensure that typical UnlimitedNatural usage such as in >the UML OCL will be unaffected. It will only be OCL users that attempt >to use UnlimitedNatural as a narrow arithmetic type that will have >trouble. > >[NB. This discussion is now completely orthogonal to whether OCL >supports infinity or not for Real or Integer.] > > Regards > > Ed Willink > >On 24/07/2013 15:53, Ed Willink wrote: >> HI >> >> Indeed more than 5 minutes thought. >> >> I'll see what happens to Eclipse OCL if we remove the subtyping >> relationship. If only a few eccentric unit tests need revision, I'll >> revise this resolution for Ballot 3. If the consequences are nastier >> we'll have to wait till we're more confident of a better direction >> than the status quo. It may just be necessary to carefully identify >> all the scenarios in which we need to specify an unrelated type >> conversion between Integer and UnlimitedNatural. >> >> Either way this resolution is withdrawn from Ballot 1. >> >> Regards >> >> Ed Willink >> >> On 24/07/2013 15:28, Adolfo Sáhez-Barbudo Herrera wrote: >>> Hi Ed, Steve. >>> >>> - I don't like A since OCL changes Integer/Real semantics given by UML. >>> - I don't like B1 since forcing to do explicit conversions sounds >>> like a very bad decision. >>> - B2 sounds the way to go on, although it deservers more than 5 >>> minutes of my thoughts regarding what occurs during parsing and how >>> conversions take place. >>> >>> I believe that there is not wheel to invent here, we just need to >>> have a look about what programming languages do (although traditional >>> programming languages -I've seen so far- don't deal with that >>> unbounded (*) value). >>> >>> As a side note, in java, Integer object is not a subtype of Real one. >>> >>> Regards, >>> Adolfo. >>> On 24/07/2013 14:53, Steve Cook wrote: >>>> B2 seems the obvious choice to me. >>>> >>>>> Providing free conversion between unrelated types is not something >>>>> that I would like to try to justify to the academics. >>>> >>>> Lots of programming languages do it between numeric types.These types >>>> are not ³unrelated², they are just not subtypes of one another. >>>> >>>>> it seems a bit odd to have plus-infinity without minus-infinity >>>> >>>> What ³*² means is that a collection has unbounded size.A collection >>>> always has a non-negative size. >>>> >>>>> an early deprecation would avoid one source of user confusion >>>> >>>> Deprecating UnlimitedNatural in UML is just not going to happen, and >>>> taking OCL in a direction that widens the gap with UML is a poor >>>> strategy. >>>> >>>> -- Steve >>>> >>>> *From:*Ed Willink [mailto:ed@willink.me.uk] >>>> *Sent:* 24 July 2013 11:53 >>>> *To:* ocl2-rtf@omg.org >>>> *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 >>>> Preview 1) >>>> >>>> Hi >>>> >>>> It is certainly not the intention to require integer implementation >>>> using floating point; just to require that the Integer and Real (as >>>> well >>>> UnlimitedNatural) have a special larger-than-anything-else (infinity) >>>> value. How implementations choose to implement that special value is >>>> not >>>> defined by the OCL specification. >>>> >>>> Currently implementations are required to check that every implicit >>>> conversion from UnlimitedNatural to Integer converts * to /invalid/. I >>>> suspect that many implementations are broken here already and so allow >>>> the implementation convenience of -1 to become visible; we certainly >>>> had >>>> to fix problems with Eclipse OCL here. >>>> >>>> Whether there is a minus-infinity is possibly a separate issue, but it >>>> seems a bit odd to have plus-infinity without minus-infinity. >>>> >>>> I'm not clear what the relevance of your comment that Integers are not >>>> closed under division is. OCL currently specifies the type >>>> conversion to >>>> Real to guarantee a result (except divide by 0). There is a separate >>>> div >>>> operator if you want the limited precision of an Integer result. >>>> >>>> Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines >>>> +,*,/, etc (no -). Conversion to Integer occurs when the >>>> capabilities of >>>> UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not >>>> available. >>>> >>>> We have two main choices to resolve the contradictory subtyping claims >>>> for UnlimitedNatural. See 11.4.1, 11.4.2. >>>> >>>> /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./ >>>> >>>> a) Make UnlimitedNatural a full subtype of Integer by introducing >>>> plus-infinity to Integer and Real (the current resolution proposal) >>>> >>>> b1) Make UnlimitedNatural unrelated to Integer with explicit >>>> conversion. >>>> - require positive integers to be parsed as Integer rather than >>>> UnlimitedNatural >>>> - require use of toInteger() to convert non-unlimited UnlimitedNatural >>>> to Integer >>>> - introduce and require use of toUnlimitedNatural() to convert >>>> non-negative Integer to UnlimitedNatural >>>> - retract all UnlimitedNatural arithmetic capabilities >>>> >>>> b2) Make UnlimitedNatural unrelated to Integer with implicit >>>> conversion. >>>> - allow implicit conversion of non-unlimited UnlimitedNatural to >>>> Integer >>>> - allow implicit conversion of non-negative Integer to >>>>UnlimitedNatural >>>> >>>> IMHO breaking the subtype contract will cause problems for programs >>>> that >>>> currently exploit the free conversion since OCL currently has numbers >>>> that grow in range/precision as required. Providing free conversion >>>> between unrelated types is not something that I would like to try to >>>> justify to the academics. >>>> >>>> The current specified arithmetic capabilities for UnlimitedNatural >>>> allow >>>> * to participate in comparisons and max/min operations without the >>>> special casing that UML specification engages in to work around the >>>> inadequacies of implementations that execute with -1 for *. >>>> (Implementations are already broken.) >>>> >>>> Introducing *-is-infinity to Integer would allow UnlimitedNatural to >>>>be >>>> eliminated altogether. UML need only specify that the lowerBound is >>>> finite and non-negative. (Actual elimination of UnlimitedNatural is >>>> probably out of the question for compatibility reasons, but an early >>>> deprecation would avoid one source of user confusion.) >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> On 24/07/2013 10:46, Steve Cook wrote: >>>> >>>> >Can the issue be that UnlimitedNatural is not really a subtype of >>>> Integer? >>>> >>>> Absolutely. These numeric types are not subtypes of each other >>>> under any useful algebraic notion of substitutability. Integers >>>>are >>>> not closed under division, as Reals are. UnlimitedNaturals are >>>>only >>>> ever subject to comparison, and do not engage in arithmetic with >>>> each other or with other numbers. There is no value and only >>>> confusion in pretending that subtyping is going on. In practice, >>>> Integer maps to whatever your computer counts in its words and >>>>adds >>>> up in its CPU, and UnlimitedNatural is mapped to the same thing >>>> with >>>> a special value (usually -1) to represent *. >>>> >>>> There may be coercions, even implicit ones, but that is not the >>>> same >>>> thing. >>>> >>>> I see no value in introducing the idea of ³minus unbounded² to >>>>OCL. >>>> Requiring all of these types to be implemented as floating point >>>> numbers, as is implied by the proposed resolution to 15780, will >>>> presumably invalidate all existing implementations of UML and OCL, >>>> and is a poor idea. >>>> >>>> -- Steve >>>> >>>> *From:*Ed Willink [mailto:ed@willink.me.uk] >>>> *Sent:* 23 July 2013 23:04 >>>> *To:* ocl2-rtf@omg.org >>>> *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 >>>> >>>> On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: >>>> >>>> Hi Ed, >>>> >>>> Some feedback about your document. >>>> >>>> Issue 15009 : >>>> Shorthand is used along OCL/QVT rather than shortform. >>>> >>>> Fixed in Preview 2 >>>> >>>> >>>> Since the new subsection is related to object navigation, >>>> I'm >>>> wondering if section 7.6 is more suitable for it. >>>> >>>> The idea was to get it in before navigation. Also one of the PAS >>>> issues complians about no ./-> in 7.5.8. >>>> >>>> >>>> >>>> Issue 15780 : >>>> 1. What does symbolic analysis mean? >>>> >>>> Analyzing an expression without evaluating it. >>>> >>>> >>>> 2. IEEE 754 alignment sounds like a UML2 misalignment. Note >>>> that UnlimitedNatural not only accommodates the need for an >>>> unlimited upper bound multiplicity, but also the lower bound >>>> value is constrained by not permitting the unbounded (or >>>> infinite) one by using the Integer type. With this proposal >>>>OCL >>>> is changing the semantics of Integer (and Real) given by UML. >>>> Can the issue be that UnlimitedNatural is not really a subtype >>>> of Integer (Looking at the varied >>>>Real-Integer-UnlimitedNatural >>>> operations, it looks like there is some Liskov substitution >>>> principle violation smell)?. Are we again dealing with a >>>> conformance related issue ?. >>>> >>>> I don't understand your point. >>>> >>>> There is no problem with UnlimitedNatural having fewer values (no >>>> negatives). The problem is an extra positive value. >>>> >>>> >>>> >>>> Issue 18437: >>>> OclAny defines post conditions for their library >>>>operations. >>>> I see no point why this should be different for the new >>>> operations on OclVoid and OclInvalid >>>> >>>> The OclAny postconditions had somethjing to say. >>>> I dont'tsee the point in padding out " Evaluates to true." with >>>> post: result = true. >>>> >>>> >>>> Issue 18464: >>>> OCL is mainly founded on (first-order) predicate logic and >>>> set theory. Could you provide a reference supporting your >>>> affirmation about why the algorithm is correct and the text >>>> incorrect ?. >>>> >>>> I don't understand your point. >>>> This is a fix for inconsistency in the wording, not an algorithm >>>> change. >>>> >>>> >>>> >>>> Issue 6600: >>>> I must be missing/misunderstanding something. I see a table >>>> of contents in the beginning. What's wrong with OCL 2.3 ? >>>> >>>> An Index is not the TOC. It is generally at the end. There is no >>>> index in OCL 2.3.1. >>>> >>>> >>>> >>>> Issue 6879-6882: >>>> We could argue about if shorthands are >>>> convenient/readable or >>>> not, but rationale like "but avoids introducing a "?" syntax >>>> irregularity" doesn't seem convincing for discarding the >>>>syntax >>>> enhancement. What does syntax irregularity mean ?. >>>> In general, I find aligning OCL-QVT syntax as a good >>>> idea. So >>>> unless you identify real problems of adopting this alignment, >>>>I >>>> don't see the point of closing these issues as no change. >>>> Borrowing your comment to discard other proposals: "The >>>> 'problems' have not prevented QVT tool being built" >>>> >>>> Nobody has demonstrated that QVTo has no limitations over the full >>>> OCL syntax in particular UML qualifiers. >>>> I'm not comfortable with the QVTo syntax extensions and the >>>> drift to >>>> be a non-Java Java.. >>>> I don't see that usage by QVTo requires adoption by OCL. >>>> I figure that if Mariano had really wanted these changes he would >>>> have put them to a ballot for OCL 2.2. >>>> >>>> >>>> Issue 6894: >>>> Better solution = no change ?? >>>> >>>> An additional library routine is not a change to the OCL language. >>>> >>>> >>>> Issue 7466: >>>> Should not every >>>> "self.condition.type.oclIsKindOf(Primitive) >>>> and self.condition.type.name = ¹Boolean¹" be changed by >>>> "self.condition.type = Boolean" ? >>>> I guess this could be deferred until specification >>>> generation is done. >>>> >>>> Yes. That is why half the issues cannot be addressed very >>>> profitably >>>> at present. We still have only visual OCL checking. >>>> >>>> >>>> >>>> Issue 14985: >>>> Resolution keyword missing, so summary and resolution is >>>> mixed in the summary section. >>>> >>>> No. The summary is what the original submitter wrote. I often >>>>write >>>> solutions in the submissions. >>>> The missing Resolution paragraph will be added in Preview 2. >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> >>>> >>>> Regards, >>>> Adolfo. >>>> -- >>>> On 22/07/2013 07:23, Ed Willink wrote: >>>> >>>> >>>> Hi >>>> >>>> Attached: Preview 1 of the Issues resolved in Ballot 1. >>>> >>>> The one week preview lasts from now until voting starts on >>>> 29th July. >>>> >>>> The two week voting period lasts from 29th July to 11th >>>> August. >>>> >>>> More details may be found in the preamble to the attached. >>>> >>>> Regards >>>> >>>> Ed Willink >>>> >>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3349 / Virus Database: 3204/6512 - Release >>>> Date: >>>> 07/22/13 >>>> >>>> >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >>>> 07/23/13 >>>> >>> >>> >>> ----- >>> No virus found in this message. >>> Checked by AVG - www.avg.com >>> Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: >>> 07/23/13 >>> >>> >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: >>07/24/13 >> >> >X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=f8pxWoCM c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=AeFP_lyPgAIA:10 a=33RrB3tuMlcA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=kh6BKfk9auYA:10 a=SSmOFEACAAAA:8 a=KHpXyVWLAAAA:8 a=oCcaPWc0AAAA:8 a=x_Mkz0FI-bE9wtbSR1sA:9 a=dkAkGA0DxCGSluhq:21 a=z_uBRnztFviTluL_:21 a=wPNLvfGTeEIA:10 a=WP4_USCxRkkA:10 Date: Sat, 27 Jul 2013 07:21:23 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "ocl2-rtf@omg.org" Subject: Re: Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) X-Virus-Scanned: amavisd-new at omg.org Hi Nicholas Not sure quite what you're asking, but some examples follow context UnlimitedNatural def: toXMLSchemaString() : String = if self = '*' then '*' else self.toInteger().toString() endif which is just a re-implementation of UnlimitedNatural::toString() whose specification is: toString() : String Converts self to a string value, using the canonical form as defined by http://www.w3.org/TR/xmlschema-2/ #nonNegativeInteger. If self is unlimited the result is '*'. Similarly the OCL 2.3.1 spec provides max(u : UnlimitedNatural) : UnlimitedNatural The maximum of self and u. post: if self = * or u = * then result = * else if self >= u then result = self else result = u endif endif An example requiring reverse conversion context MyHashTable def: capacity : UnlimitedNatural = 256 def: size : UnlimitedNatural = 0 def: maxCapacity = '*' def: newCapacity() : UnlimitedNatural = let threshold : UnlimitedNatural = (0.25 * capacity.toInteger()).toNatural() in min(maxCapacity, max(size + size, threshold)) All the above example could have the toInteger() / toNatural() automatically deduced by the CS to AS conversion. [I would discourage use of UnlimitedNatural to implement collections, since no practical implementation will ever realise an unbounded capacity.] Regards Ed Willink On 26/07/2013 20:18, Rouquette, Nicolas F (313K) wrote: Ed, I wrote a resolution for UML 2.5 issue 18831 that defines UnlimitedNatural by mapping to a new XML schema datatype, unlimitedNatural, defined as the xsd:union of xsd:nonNegativeInteger and of an xsd:enumeration consisting of the symbol "*". How could I use OCL to specify arithmetic operations for UnlimitedNatural and conversions to/from other datatypes given its mapping to an XML schema unlimitedNatural as described above? - Nicolas. On 7/26/13 10:58 AM, "Ed Willink" wrote: Hi Changing Eclipse OCL to remove the UnlimitedNatural / Integer subtyping relationship is quite interesting. The library modeling breaks because there is no conversion of integer literals parsed as UnlimitedNatural. If the parsing is changed the problems are largely where tests explicitly mention UnlimitedNatural. We really just need to go back to a much simpler time. In OCL 1.x there was only Real, Integer OCL 2.0 'caught up' with UML 1.x by mentioning but not specifying UnlimitedInteger OCL 2.2 'caught up' with UML 2.0 by mentioning but not specifying UnlimitedNatural OCL 2.3 specified UnlimitedNatural as part of a 'coherent' type system for numbers Nothing in the core of OCL uses UnlimitedNatural; all operations such as at(), substring(), indexOf() use Integer values. UnlimitedNatural need never exist for ordinary users but for the parsing specification. Positive integers have UnlimitedNatural type and so permit conversion to Integer or Real as required. So UnlimitedNatural is a "monstrous carbuncle on the face of a much-loved and elegant friend". We could treat it as such. It can be an orthogonal type useable only by Integer.toNatural() and UnlimitedNatural.toInteger(). It can have very limited arithmetic capabilities: addition, comparison, max/min. If users learn to avoid it then the inconvenience of explicit conversions will be limited to those rare occasions when complex calculations on cardinalities are required. I much prefer the requirement for explicit conversions for these unsafe conversions. I don't like allowing unsafe conversions to be implicit. However, if really necessary, we can make this less painful for existing OCL by only mandating the explicit conversion in the AST; the CS to AS conversion can automatically synthesize the operation just as is necessary for oclAsSet() and implicit collect(). Reverting UnlimitedNatural to a carbuncle requires two breaking changes (wrt OCL 2.3) - remove the UnlimitedNatural / Integer subtyping specification - specify that integer literals are parsed with Integer type The latter parsing specification is hardly a breakage, since Clause 9 is not yet clear enough to tell how literals are disambiguated at all. We can probably ensure that typical UnlimitedNatural usage such as in the UML OCL will be unaffected. It will only be OCL users that attempt to use UnlimitedNatural as a narrow arithmetic type that will have trouble. [NB. This discussion is now completely orthogonal to whether OCL supports infinity or not for Real or Integer.] Regards Ed Willink On 24/07/2013 15:53, Ed Willink wrote: HI Indeed more than 5 minutes thought. I'll see what happens to Eclipse OCL if we remove the subtyping relationship. If only a few eccentric unit tests need revision, I'll revise this resolution for Ballot 3. If the consequences are nastier we'll have to wait till we're more confident of a better direction than the status quo. It may just be necessary to carefully identify all the scenarios in which we need to specify an unrelated type conversion between Integer and UnlimitedNatural. Either way this resolution is withdrawn from Ballot 1. Regards Ed Willink On 24/07/2013 15:28, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Steve. - I don't like A since OCL changes Integer/Real semantics given by UML. - I don't like B1 since forcing to do explicit conversions sounds like a very bad decision. - B2 sounds the way to go on, although it deservers more than 5 minutes of my thoughts regarding what occurs during parsing and how conversions take place. I believe that there is not wheel to invent here, we just need to have a look about what programming languages do (although traditional programming languages -I've seen so far- don't deal with that unbounded (*) value). As a side note, in java, Integer object is not a subtype of Real one. Regards, Adolfo. On 24/07/2013 14:53, Steve Cook wrote: B2 seems the obvious choice to me. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. Lots of programming languages do it between numeric types.These types are not ³unrelated², they are just not subtypes of one another. it seems a bit odd to have plus-infinity without minus-infinity What ³*² means is that a collection has unbounded size.A collection always has a non-negative size. an early deprecation would avoid one source of user confusion Deprecating UnlimitedNatural in UML is just not going to happen, and taking OCL in a direction that widens the gap with UML is a poor strategy. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 24 July 2013 11:53 *To:* ocl2-rtf@omg.org *Subject:* Issue 15780 Unlimited/Infinity (was Re: OCL 2.4 Ballot 1 Preview 1) Hi It is certainly not the intention to require integer implementation using floating point; just to require that the Integer and Real (as well UnlimitedNatural) have a special larger-than-anything-else (infinity) value. How implementations choose to implement that special value is not defined by the OCL specification. Currently implementations are required to check that every implicit conversion from UnlimitedNatural to Integer converts * to /invalid/. I suspect that many implementations are broken here already and so allow the implementation convenience of -1 to become visible; we certainly had to fix problems with Eclipse OCL here. Whether there is a minus-infinity is possibly a separate issue, but it seems a bit odd to have plus-infinity without minus-infinity. I'm not clear what the relevance of your comment that Integers are not closed under division is. OCL currently specifies the type conversion to Real to guarantee a result (except divide by 0). There is a separate div operator if you want the limited precision of an Integer result. Arithmetic is currently specified for UnlimitedNatural. 11.5.5 defines +,*,/, etc (no -). Conversion to Integer occurs when the capabilities of UnlimitedNatural op UnlimitedNatural => UnlimitedNatural are not available. We have two main choices to resolve the contradictory subtyping claims for UnlimitedNatural. See 11.4.1, 11.4.2. /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./ a) Make UnlimitedNatural a full subtype of Integer by introducing plus-infinity to Integer and Real (the current resolution proposal) b1) Make UnlimitedNatural unrelated to Integer with explicit conversion. - require positive integers to be parsed as Integer rather than UnlimitedNatural - require use of toInteger() to convert non-unlimited UnlimitedNatural to Integer - introduce and require use of toUnlimitedNatural() to convert non-negative Integer to UnlimitedNatural - retract all UnlimitedNatural arithmetic capabilities b2) Make UnlimitedNatural unrelated to Integer with implicit conversion. - allow implicit conversion of non-unlimited UnlimitedNatural to Integer - allow implicit conversion of non-negative Integer to UnlimitedNatural IMHO breaking the subtype contract will cause problems for programs that currently exploit the free conversion since OCL currently has numbers that grow in range/precision as required. Providing free conversion between unrelated types is not something that I would like to try to justify to the academics. The current specified arithmetic capabilities for UnlimitedNatural allow * to participate in comparisons and max/min operations without the special casing that UML specification engages in to work around the inadequacies of implementations that execute with -1 for *. (Implementations are already broken.) Introducing *-is-infinity to Integer would allow UnlimitedNatural to be eliminated altogether. UML need only specify that the lowerBound is finite and non-negative. (Actual elimination of UnlimitedNatural is probably out of the question for compatibility reasons, but an early deprecation would avoid one source of user confusion.) Regards Ed Willink On 24/07/2013 10:46, Steve Cook wrote: Can the issue be that UnlimitedNatural is not really a subtype of Integer? Absolutely. These numeric types are not subtypes of each other under any useful algebraic notion of substitutability. Integers are not closed under division, as Reals are. UnlimitedNaturals are only ever subject to comparison, and do not engage in arithmetic with each other or with other numbers. There is no value and only confusion in pretending that subtyping is going on. In practice, Integer maps to whatever your computer counts in its words and adds up in its CPU, and UnlimitedNatural is mapped to the same thing with a special value (usually -1) to represent *. There may be coercions, even implicit ones, but that is not the same thing. I see no value in introducing the idea of ³minus unbounded² to OCL. Requiring all of these types to be implemented as floating point numbers, as is implied by the proposed resolution to 15780, will presumably invalidate all existing implementations of UML and OCL, and is a poor idea. -- Steve *From:*Ed Willink [mailto:ed@willink.me.uk] *Sent:* 23 July 2013 23:04 *To:* ocl2-rtf@omg.org *Subject:* Re: OCL 2.4 Ballot 1 Preview 1 On 23/07/2013 14:14, Adolfo Sáhez-Barbudo Herrera wrote: Hi Ed, Some feedback about your document. Issue 15009 : Shorthand is used along OCL/QVT rather than shortform. Fixed in Preview 2 Since the new subsection is related to object navigation, I'm wondering if section 7.6 is more suitable for it. The idea was to get it in before navigation. Also one of the PAS issues complians about no ./-> in 7.5.8. Issue 15780 : 1. What does symbolic analysis mean? Analyzing an expression without evaluating it. 2. IEEE 754 alignment sounds like a UML2 misalignment. Note that UnlimitedNatural not only accommodates the need for an unlimited upper bound multiplicity, but also the lower bound value is constrained by not permitting the unbounded (or infinite) one by using the Integer type. With this proposal OCL is changing the semantics of Integer (and Real) given by UML. Can the issue be that UnlimitedNatural is not really a subtype of Integer (Looking at the varied Real-Integer-UnlimitedNatural operations, it looks like there is some Liskov substitution principle violation smell)?. Are we again dealing with a conformance related issue ?. I don't understand your point. There is no problem with UnlimitedNatural having fewer values (no negatives). The problem is an extra positive value. Issue 18437: OclAny defines post conditions for their library operations. I see no point why this should be different for the new operations on OclVoid and OclInvalid The OclAny postconditions had somethjing to say. I dont'tsee the point in padding out " Evaluates to true." with post: result = true. Issue 18464: OCL is mainly founded on (first-order) predicate logic and set theory. Could you provide a reference supporting your affirmation about why the algorithm is correct and the text incorrect ?. I don't understand your point. This is a fix for inconsistency in the wording, not an algorithm change. Issue 6600: I must be missing/misunderstanding something. I see a table of contents in the beginning. What's wrong with OCL 2.3 ? An Index is not the TOC. It is generally at the end. There is no index in OCL 2.3.1. Issue 6879-6882: We could argue about if shorthands are convenient/readable or not, but rationale like "but avoids introducing a "?" syntax irregularity" doesn't seem convincing for discarding the syntax enhancement. What does syntax irregularity mean ?. In general, I find aligning OCL-QVT syntax as a good idea. So unless you identify real problems of adopting this alignment, I don't see the point of closing these issues as no change. Borrowing your comment to discard other proposals: "The 'problems' have not prevented QVT tool being built" Nobody has demonstrated that QVTo has no limitations over the full OCL syntax in particular UML qualifiers. I'm not comfortable with the QVTo syntax extensions and the drift to be a non-Java Java.. I don't see that usage by QVTo requires adoption by OCL. I figure that if Mariano had really wanted these changes he would have put them to a ballot for OCL 2.2. Issue 6894: Better solution = no change ?? An additional library routine is not a change to the OCL language. Issue 7466: Should not every "self.condition.type.oclIsKindOf(Primitive) and self.condition.type.name = ¹Boolean¹" be changed by "self.condition.type = Boolean" ? I guess this could be deferred until specification generation is done. Yes. That is why half the issues cannot be addressed very profitably at present. We still have only visual OCL checking. Issue 14985: Resolution keyword missing, so summary and resolution is mixed in the summary section. No. The summary is what the original submitter wrote. I often write solutions in the submissions. The missing Resolution paragraph will be added in Preview 2. Regards Ed Willink Regards, Adolfo. -- On 22/07/2013 07:23, Ed Willink wrote: Hi Attached: Preview 1 of the Issues resolved in Ballot 1. The one week preview lasts from now until voting starts on 29th July. The two week voting period lasts from 29th July to 11th August. More details may be found in the preamble to the attached. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6512 - Release Date: 07/22/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3204/6515 - Release Date: 07/23/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6518 - Release Date: 07/24/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3349 / Virus Database: 3209/6523 - Release Date: 07/26/13