Issue 15987: The fUML Foundational Model Library should support the new UML 2.4 Real primitive type (fuml-rtf) Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com) Nature: Uncategorized Issue Severity: Summary: Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14) UML 2.4 has introduced a new Real primitive type. This should be supported by a new package of primitive functions in the fUML Foundational Model Library. Resolution: The UML 2.4.1 Infrastructure specification states that “A real is a primitive type representing the mathematical concept of real” and that “An instance of Real is an element in the infinite set of real numbers.” However, some care needs to be taken in defining the fUML execution semantics of the Real type and supporting primitive functions, so that it is possible for a real implementation to conform to those semantics. The UML specification also says that “An instance of Integer is an element in the (infinite) set of integers…”. And the base semantics for buml:Integer in Subclause 10.3.1.2 of the fUML 1.0 specification does, indeed, include the mathematical axioms necessary to define this infinite set. However, Subclause 9.1 includes the permission that “…a conforming implementation may limit the supported values [of Integer] to a finite set.” Similarly, fUML should allow conforming implementations to limit the supported values of Real to a finite set. However, for Real numbers, this means more than just limiting the upper and lower bounds of the supported range of Real numbers. It also means dealing with the fact that Real numbers can only be represented to finite precision in an actual implementation. Generally, programming languages provide floating-point representations that approximate Real numbers. However, this is an implementation representation, and the most commonly used standard reference on floating-point numbers, IEEE 754, is a standard for the implementation of floating-point computation. For fUML, it is necessary to provide a precise semantic specification for Real numbers that is implementation independent but that provides clear criteria for the conformance of actual implementations. This should allow implementations based on a floating-point standard such as IEEE 754 but also allow implementations using, e.g., fixed-point computation or exact rational number computation. This can be achieved in three steps. 1. Axioms for the Real type need to be added to the fUML base semantics in Clause 10. 2. Criteria are needed in Clause 9 for conformance to the Real type as it is to be provided in the fUML Foundational Model Library. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). So, some permission is needed to allow for the conformance of implementations using, e.g., finite-precision floating-point representations. In addition, IEEE 754 requires some additional special values be represented in the floating-point formats it defines. Since it is expected that it will be common that the fUML Real type will be implemented using a floating-point representation based on IEEE 754, it is necessary to allow for the inclusion of such values in an implementation of Real. 3. Criteria are needed in Clause 9 for conformance to the semantics of the primitive functions for Real to be provided in the Foundational Model Library. The specification of the primitive functions for Real in the Foundational Model Library will define the exact real number result of applying those functions. It is then necessary to define how these exact results may be represented in a conforming implementation that takes advantage of some or all of the permissions allowed relative to the representation of Real numbers. This resolution also presumes the resolution of Issue 15986, “fUML 1.1 should be based on UML 2.4”. For simplicity, all revisions related to the new Real type have been included here. This includes changes to Clause 7 Abstract Syntax, Clause 8 Execution Model and Annex A Java to UML Activity Mapping, as well as the changes to Clauses 9 and 10 discussed above. Revised Text: Revised Text: Clause 7 Abstract Syntax In Figure 7.6 Expressions, add LiteralReal as a subclass of LiteralSpecification, with one attribute: • + value : Real After Subclause 7.2.2.17 LiteralNull, add the following subclause: LiteralReal Generalizations • “LiteralSpecification” on page xx Attributes • value : Real Associations None Additional Constraints None Clause 8 Execution Model In Subclause 8.2.2.2, under “Primitive Behaviors and Primitive Types”, in the last sentence of the last paragraph, change “…Boolean, Integer, String, and UnlimitedNatural…” to “…Boolean, Integer, Real, String, and UnlimitedNatural…”. In Figure 8.11, add the following class as a subclass of PrimitiveValue: RealValue + value : Real + specify ( ) : ValueSpecification + equals ( otherValue : Value ) : Boolean + copy ( ) : Value # new_ ( ) : Value + toString ( ) : String In Figure 8.13, add the following class as a subclass of LiteralEvaluation: LiteralRealEvaluation + evaluate ( ) : Value [0..1] After Subclause 8.3.2.2.15, add the subclause LiteralRealEvaluation A literal real evaluation is an evaluation whose specification is a literal real. Generalizations • “LiteralEvaluation” on page 138 Attributes None Associations None Operations [1] evaluate ( ) : Value [0..1] // Evaluate a real integer, producing a real value. LiteralReal literal = (LiteralReal)specification; RealValue realValue = new RealValue(); realValue.type = this.getType("Real"); realValue.value = literal.value; return realValue; After Subclause 8.3.2.2.19, add the subclause RealValue A real value is a primitive value whose type is Real. Generalizations • “PrimitiveValue” on page 143 Attributes • value : Real? The actual Real value. Associations None Operations [1] copy ( ) : Value // Create a new real value with the same value as this real value. RealValue newValue = (RealValue)(super.copy()); newValue.value = this.value; return newValue; [2] equals ( in otherValue : Value ) : Boolean // Test if this real value is equal to the otherValue.? // To be equal, the otherValue must have the same value as this real value. boolean isEqual = false; if (otherValue instanceof RealValue) {? isEqual = ((RealValue)otherValue).value == this.value; } return isEqual; [3] new_ ( ) : Value // Create a new real value with no value. return new RealValue(); [4] specify ( ) : ValueSpecification // Return a literal real with the value of this real value. LiteralReal literal = new LiteralReal(); literal.type = this.type; literal.value = this.value; return literal;? [5] toString ( ) : String String stringValue = ""; if (this.value == 0) { stringValue = "0"; } else {? float positiveValue = this.value; if (positiveValue < 0) { positiveValue = -positiveValue; } int exponent = 0; if (postiveValue < .1) { while (positiveValue < .1) { positiveValue = positiveValue * 10; exponent = exponent - 1; } else if (positiveValue > 1) { while (positiveValue > 1) { positiveValue = positiveValue / 10; exponent = exponent + 1; } } // This gives 10 significant digits in the mantissa. for (int i=0; i<10; i++) { positiveValue = positiveValue * 10; } IntegerValue integerValue = new IntegerValue(); integerValue.value = (int)positiveValue; stringValue = “0.” + integerValue.toString(); integerValue.value = exponent; stringValue = stringValue + “E” + integerValue.toString; if (this.value < 0) {? stringValue = "-" + stringValue; } } return stringValue; Clause 9 Foundational Model Library In Subclause 9.1 Primitive Types, Table 9.1, add the following row after the row for Integer: Real The Real type has literal values in the infinite, continuous set of real numbers. However, a conforming implementation may limit the support values to a finite subset (see 9.2.3 for further discussion of this). In Subclause 9.2 Primitive Behaviors, add a RealFunctions package to Figure 9.2. In the first paragraph of Subclause 9.2.2 Integer Functions, remove the sentence: The OCL “/” operation is not included, since this returns a Real value, and the Foundational Model Library does not support a Real primitive type. In Table 9.3, add the following row, after the row for the “*” function: /(x: Integer, y: Integer): Real[0..1] The value of the division of x by y. Pre: y<>0 Post: result = ToReal(x) / ToReal(y) NOTE: The ToReal and “/” functions used here are those from the RealFunctions package (see 9.2.3). Add the following subclause and renumber subsequent subclauses and tables appropriately: 9.2.3 Real Functions Table 9.4 lists the function behaviors that are included in the package RealFunctions. The naming is consistent with OCL, including the use of the conventional symbols for arithmetic functions, except that the negation function is named “Neg”, rather than overloading the symbol “-”, and alphabetic names are capitalized, per the usual convention for behaviors (as kinds of classes). The Foundation Model Library also provides ToString and ToInteger functions not found in OCL 2.0. The ToReal function does correspond to an OCL operation, though, in OCL, it is a String operation. Table 9.4 – Foundation Model Library Real Functions Function Signature Description Neg(x: Real): Real The negative value of x. +(x: Real, y: Real): Real The value of the addition of x and y. -(x: Real, y: Real): Real The value of the subtraction of x and y. Post: result + y = x Inv(x: Real): Real The inverse (reciprocal) value of x. *(x: Real, y: Real): Real The value of the multiplication of x and y. /(x: Real, y: Real): Real[0..1] The value of the division of x by y. Pre: y<>0 Post: result * y = x Abs(x: Real): Real The absolute value of x. Post: if x < 0 then result = Neg(x) else result = x endif Floor(x: Real): Integer The largest integer that is less than or equal to x. Post: result <= x And result + 1 > x Round(x: Real): Integer The integer that is closest to x. When there are two such integers, the largest one. Post: (Abs(x - result) < 0.5) Or ((Abs(x - result) = 0.5) And result > x) Max(x: Real, y: Real): Real The maximum of x and y. Post: if x >= y then result = x else result = y endif Min(x: Real, y: Real): Real The minimum of x and y. Post: if x <= y then result = x else result = y endif <(x: Real, y: Real): Boolean True if x is less than y. >(x: Real, y: Real): Boolean True if x is greater than y. Post: result = Not(x <= y) <=(x: Real, y: Real): Boolean True if x is less than or equal to y. Post: result = (x = y) Or (x < y) >=(x: Real, y: Real): Boolean True if x is greater than or equal to y. Post: result = (x = y) Or (x > y) ToString(x: Real): String Converts x to a String value. Post: ToReal(result) = x ToInteger(x: Real): Integer Converts x to an Integer value, truncating towards zero. Post: if x >= 0 then Floor(x) else Neg(Floor(Neg(x)) endif ToReal(x: String): Real[0..1] Converts x to a Real value. Pre: x has the form of a legal Real value. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). Therefore, implementations are given the following permissions for representing Real numbers and performing computations on them, while still conforming to this specification. NOTE: The permissions below are intended, in particular, to allow the conformance of implementations using finite-precision floating-point representations for Real numbers (such as those based on the popular IEEE 754 standard), while still allowing for other implementations that may not need to take advantage of all the allowed permissions. 1. A conforming implementation may support only a limited range of Real values, such that the absolute value of any supported value is less than or equal to a specified maximum value. If the implementation limits the range of values support for Integer, then the maximum value specified for Real must be no less than the greatest absolute value of any supported Integer value. 2. A conforming implementation may support only a restricted value set for Real, defined as a non-dense subset of the infinite set of rational numbers (such that any bounded interval of this value set contains only a finite set of values) including zero and with no upper or lower bound. If the implementation limits the range of values supported for Integer, then the smallest positive value in the restricted value set shall be at least as small as the reciprocal of the largest supported Integer value. 3. A conforming implementation may provide distinct representations for Real positive zero and Real negative zero. These values shall be considered equal for the purposes of all comparison functions. However, they may be distinguished in certain arithmetic computations (see below). 4. A conforming implementation may include additional special values that are instances of the Real type but are not numeric values (such as infinite values and “not a number” values). Note that, even if included in an implementation of the Real type, none of these special values have any standard literal representation in UML. The functions in the RealFunctions package are specified in Table 9.4 in terms of the semantics for mathematical Real numbers, as defined in Subclause 10.3.1. However, an implementation that takes advantage of some or all of the above permissions may not be able to produce exact results for some computations using these functions. Therefore, conformance to the function behaviors given in Table 9.4 shall be interpreted as follows. • Since a restricted value set is non-dense and unbounded, any exact value that is not in such a set will be between two values that are in the set. If a conforming implementation supports only a restricted value set, and the result of a computation is not a member of this set, then the implementation may implement the computation as resulting in one of the two values in the restricted value set that the exact result is between. (If the exact value of the computation is non-zero, but the chosen value in the restricted value set is zero, then the computation is said to underflow.) • If a conforming implementation supports only a limited range of values, then a computation that results in an exact value that is outside that range is said to overflow. The implementation may implement an overflowing computation as resulting in a special value (e.g., positive or negative infinity). If not, an overflowing computation shall be implemented as having an empty result. • If a numeric result is not defined for a call to a primitive function resulting in a Real value, because one of the arguments is a special value or because a precondition is violated, then a conforming implementation may produce a special value for its result. Otherwise, the computation shall be implemented as having an empty result. • If a conforming implementation supports signed zero, then multiplication of a numeric value by positive zero shall result in positive zero, while multiplication of a numeric value by negative zero shall result in negative zero. A conforming implementation shall not otherwise distinguish between positive and negative zero in any call to a primitive function that is specified as resulting in a numeric result. However, it may distinguish between them if the result is implemented as a special value (e.g., division by negative zero may result in negative infinity). • Other than as given above, this specification does not define the result of calling a primitive function in which one or more of the arguments is a special value. Clause 10 Base Semantics Replace the contents of Subclause 10.3.1.2 Numbers with The less-than relation. (forall (x y) (if (buml:less-than x y) (and (buml:Real x) (buml:Real y)))) (forall (x y) (if (buml:less-than x y) (and (not (buml:less-than y x)) (not (= x y))))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (or (form:less-than x y) (form:less-than y x) (= y x)))) (forall (x y) (iff (buml:less-than x y) (and (buml:Real x) (buml:Real y) (not (buml:less-than y x)) (not (= x y))))) (forall (x y z) (if (and (buml:less-than x y) (buml:less-than y z)) (buml:less-than x z))) (forall (x z) (if (buml:less-than x z) (exists (y) (and (buml:less-than x y) (buml:less-than y z))))) The add relation. (forall (x y z) (if (buml:add x y z) (and (buml:Real x) (buml:Real y) (buml:Real z)))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (exists (z) (buml:add x y z)))) (forall (x y z1 z2) (if (and (buml:add x y z1) (buml:add x y z2)) (= z1 z2))) (forall (x y zxy zyx) (if (and (buml:add x y zxy) (buml:add y x zyx)) (= zxy zyx))) (forall (x y z xy yz rxy ryz) (if (and (buml:add x y xy) (buml:add xy z rxy) (buml:add y z yz) (buml:add x yz ryz)) (= rxy ryz))) (forall (x y xz yz) (if (and (buml:add x z xz) (buml:add y z yz) (buml:less-than x y)) (buml:less-than xz yz))) (buml:Real form:0) (forall (x x0) (if (buml:add x form:0 x0) (= x x0))) (forall (x y) (iff (buml:neg x y) (buml:add x y form:0))) (forall (x) (if (buml:Real x) (exists (nx) (buml:neg x nx)))) The mult relation. (forall (x y z) (if (buml:mult x y z) (and (buml:Real x) (buml:Real y) (buml:Real z)))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (exists (z) (buml:mult x y z)))) (forall (x y z1 z2) (if (and (buml:mult x y z1) (buml:mult x y z2)) (= z1 z2))) (forall (x y zxy zyx) (if (and (buml:mult x y zxy) (buml:mult y x zyx)) (= zxy zyx))) (forall (x y z xy yz rxy ryz) (if (and (buml:mult x y xy) (buml:mult xy z rxy) (buml:mult y z yz) (buml:mult x yz ryz)) (= rxy ryz))) (forall (x y xy) (if (and (buml:mult x y xy) (buml:less-than form:0 x) (buml:less-than form:0 y)) (buml:less-than form:0 xy))) (buml:Real form:1) (forall (x x1) (if (buml:mult x form:1 x1) (= x x1))) (forall (x y) (iff (buml:inv x y) (buml:mult x y form:1))) (forall (x) (if (and (buml:Real x) (not (= x form:0))) (exists (ix) (buml:inv x ix)))) (forall (x y z yz rxyz xy xz xyxz) (if (and (add y z yz) (mult x yz xyz) (mult x y xy) (mult x z xz) (add xy xz xyxz)) (= xyz xyxz))) (less-than form:0 form:1) Rational, integer, natural, unlimited natural, and whole numbers. (forall (x) (if (form:RationalNumber x) (buml:Real x))) (forall (x z) (if (and (form:Rational x) (form:Rational z) (buml:less-than x z)) (exists (y) (and (form:Rational y) (buml:less-than x y) (buml:less-than y z))))) (forall (x z) (if (and (form:Rational x) (form:Rational z) (buml:less-than x z)) (exists (y) (and (buml:Real y) (not (form:Rational y)) (buml:less-than x y) (buml:less-than y z))))) (forall (y) (if (and (buml:Real y) (not (form:Rational y))) (and (not (exists (xu) (and (form:Rational xu) (forall (x) (and (Rational x) (buml:less-than x y) (or (buml:less-than x xu) (= x xu))))))) (not (exists (zl) (and (form:Rational zl) (forall (z) (and (Rational z) (buml:less-than y z) (or (buml:less-than zl z) (= zl z)))))))))) (forall (x) (if (buml:Integer x) (form:Rational x))) (forall (x y) (iff (form:add-one x y) (form:add x form:1 y))) (forall (x) (iff (buml:Integer x) (or (= x form:0) (exists (y) (and (buml:Integer y) (or (form:add-one y x) (form:add-one x y))))))) (forall (x) (iff (form:NaturalNumber x) (and (buml:Integer x) (or (= x form:0) (buml:less-than form:0 x))))) (forall (x) (iff (buml:UnlimitedNatural x) (or (form:NaturalNumber x) (= x buml:*)))) (forall (x) (iff (form:WholeNumber x) (and (form:NaturalNumber x) (not (= x form:0))))) Annex A Java to UML Activity Mapping In Table A.1, after the row for type “int”, add the following row: float Real Change the title of Subclause A.4.13 from “Type Cast” to “Type Cast (non-primitive)”. After Subclause A.4.13, add the following subclause: A.4.14 Type Cast (Numeric) Java (<type>)<expression> • The type must be int or float. • The expression being cast must be of type int or float. UML • A type cast from int to int, float to float or int to float is mapped as the expression being cast. The cast itself is ignored, other than that the result pin for the expression being mapped is always given the UML type corresponding to the type of the cast. • A type cast from float to int maps to a call behavior action for the ToInteger behavior. The result output pin becomes the result pin for the mapping. The argument input pin of the call behavior action is connected by an object flow to the result pin of the mapping of the expression being cast. Note • In the base semantics, an integers is a kind of real number (see 10.3.1.2), so no actual operation is needed to cast an integer to a real. Actions taken: January 26, 2011: received issue January 7, 2013: closed issue Discussion: End of Annotations:===== ubject: The fUML Foundational Model Library should support the new UML 2.4 Real primitive type Date: Wed, 26 Jan 2011 12:13:15 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The fUML Foundational Model Library should support the new UML 2.4 Real primitive type thread-index: Acu9fFFNg5Rm1gWFSZCs5lha1Zqz0A== From: "Ed Seidewitz" To: Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14) UML 2.4 has introduced a new Real primitive type. This should be supported by a new package of primitive functions in the fUML Foundational Model Library. From: Ed Seidewitz To: "fuml-rtf@omg.org" Date: Thu, 1 Mar 2012 13:56:22 -0500 Subject: Proposed approach for Real type in fUML 1.1 Thread-Topic: Proposed approach for Real type in fUML 1.1 Thread-Index: Acz33P7EqJKqRPESRPWhrVzARibArA== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|-0.994051|0.878582|0|white|ugly|5028|15|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.878582 p=-0.994051 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-Mailprotector-ID: 8d422398-e4e3-4b24-aeec-d9cbb974ab83 fUML RTFers . One goal for fUML 1.1, expressed in Issue 15986, is to move the fUML subset from UML 2.3 to UML 2.4. Besides some metamodel changes, UML 2.4 also adds a new primitive type, Real. Issue 15987 asks for support for this new type to be added to the fUML Foundation Model Library. Now, clearly, we want to provide the expected library functions for Real arithmetic, etc. However, we need to take some care. No real implementation can really implement true infinite-precision Real computation. So we need to be careful to specify the execution semantics for Real functions in fUML in a way that is precise and platform independent . but is still possible to implement in a conformant way! In the attached I have written up a proposed approach for this, as a draft resolution for Issue 15986. Please take a look and let me know what you think. This is probably one of the more important issues we need to handle in the RTF, as part of the overall transition to UML 2.4! We will also have an opportunity to discuss this further during the RTF meeting in Reston. Once we have agreement on the approach, I will complete the resolution with the exact revised text, including actual list of Real primitive functions to be provided (and some of the current draft resolution description text will probably move to the revised text, too). Thanks. -- Ed From: Ed Seidewitz To: "fuml-rtf@omg.org" Date: Mon, 2 Apr 2012 17:58:49 -0400 Subject: Revised draft resolution for Issue 15987 on adding Real to fUML Thread-Topic: Revised draft resolution for Issue 15987 on adding Real to fUML Thread-Index: Ac0RG1fZarzfvXB8R5+cdcTBAf79tw== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|-0.994259|0.850283|0|white|ugly|3821|11|0|0 X-Mailprotector-Results: null_ptr subject_50_chars clean X-Mailprotector-Score: 60 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0.850283 p=-0.994259 Source White X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-Mailprotector-ID: 9e3873ca-173c-4046-a256-4aefc0a304a4 Per my action from the fUML RTF meeting in Reston, attached is a revised draft resolution for Issue 15987, .The fUML Foundational Model Library should support the new UML 2.4 Real primitive type.. This revision incorporates changes previously discussed, and it also fills in the Revised Text section, at least for revision to Clause 9. I am still waiting for Conrad to provide a proposed revision to Clause 10 for the base semantics of Real. Conrad: When can we expect a draft axiomatization for Real? Thanks. -- Ed Issue-15987-Resolution-evs.doc OMG Issue No: 15987 Title: The fUML Foundational Model Library should support the new UML 2.4 Real primitive type Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s@modeldriven.com seidewitz@acm.org) Summary: UML 2.4 has introduced a new Real primitive type. This should be supported by a new package of primitive functions in the fUML Foundational Model Library. Resolution: The UML 2.4.1 Infrastructure specification states that .A real is a primitive type representing the mathematical concept of real. and that .An instance of Real is an element in the infinite set of real numbers.. However, some care needs to be taken in defining the fUML execution semantics of the Real type and supporting primitive functions, such that it is actually possible for a real implementation to conform to those semantics. Now, the UML specification also says that .An instance of Integer is an element in the (infinite) set of integers... And the base semantics for buml:Integer in Subclause 10.3.1.2 of the fUML 1.0 specification does, indeed, include the mathematical axioms necessary to define this infinite set. However, Subclause 9.1 includes the permission that ..a conforming implementation may limit the supported values [of Integer] to a finite set.. Similarly, fUML should allow conforming implementations to limit the supported values of Real to a finite set. However, for Real numbers, this means more than just limiting the upper and lower bounds of the supported range of Real numbers. It also means dealing with the fact that Real numbers can only be represented to finite precision in an actual implementation. Generally, programming languages provide floating-point representations that approximate Real numbers. However, this is really an implementation representation, and the most commonly used standard referenced on floating-point numbers, IEEE 754, is actually a standard for the implementation of floating-point computation. For fUML, it is necessary to provide a precise semantic specification for Real numbers that is implementation independent but that provides clear criteria for the conformance of actual implementations. This should allow implementations based on a floating-point standard such as IEEE 754 but also allow implementations using, e.g., fixed-point computation or exact rational number computation. This can be achieved in three steps. 1. Axioms for the Real type need to be added to the fUML base semantics in Clause 10. 2. Criteria are needed in Clause 9 for conformance to the Real type as it is to be provided in the fUML Foundational Model Library. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). So, some permission is needed to allow for the conformance of implementations using, e.g., finite-precision floating-point representations. In addition, IEEE 754 requires some additional special values be represented in the floating-point formats it defines. Since it is expected that it will be common that the fUML Real type will be implemented using a floating-point representation based on IEEE 754, it is necessary to allow for the inclusion of such values in an implementation of Real. 3. Criteria are needed in Clause 9 for conformance to the semantics of the primitive functions for Real to be provided in the Foundational Model Library. The specification of the primitive functions for Real in the Foundational Model Library will define the exact real number result of applying those functions. It is then necessary to define how these exact results may be represented in a conforming implementation that takes advantage of some or all of the permissions allowed relative to the representation of Real numbers. Revised Text: (NOTE: This resolution presumes the resolution of Issue 15986, .fUML 1.1 should be based on UML 2.4..) In Subclause 9.1 Primitive Types, Table 9.1, add the following row after the row for Integer: Real The Real type has literal values in the infinite, continuous set of real numbers. However, a conforming implementation may limit the support values to a finite subset (see 9.2.3 for further discussion of this). In Subclause 9.2 Primitive Behaviors, add a RealFunctions package to Figure 9.2. In the first paragraph of Subclause 9.2.2 Integer Functions, remove the sentence: The OCL ./. operation is not included, since this returns a Real value, and the Foundational Model Library does not support a Real primitive type. In Table 9.3, add the following row, after the row for the .*. function: /(x: Integer, y: Integer): Real[0..1] The value of the division of x by y. Pre: y<>0 Post: result = ToReal(x) / ToReal(y) NOTE: The ToReal and ./. functions used here are those from the RealFunctions package (see 9.2.3). Add the following subclause and renumber subsequent subclauses and tables appropriately: 9.2.3 Real Functions Table 9.4 lists the function behaviors that are included in the package RealFunctions. The naming is consistent with OCL, including the use of the conventional symbols for arithmetic functions, except that the negation function is named .Neg., rather than overloading the symbol .-., and alphabetic names are capitalized, per the usual convention for behaviors (as kinds of classes). The Foundation Model Library also provides ToString and ToInteger functions not found in OCL . The ToReal function does correspond to an OCL operation, though, in OCL, it is a String operation. Table 9.4 . Foundation Model Library Real Functions Function Signature Description Neg(x: Real): Real The negative value of x. +(x: Real, y: Real): Real The value of the addition of x and y. -(x: Real, y: Real): Real The value of the subtraction of x and y. Post: result + y = x *(x: Real, y: Real): Real The value of the multiplication of x and y. /(x: Real, y: Real): Real[0..1] The value of the division of x by y. Pre: y<>0 Post: result * y = x Abs(x: Real): Real The absolute value of x. Post: if x < 0 then result = Neg(x) else result = x endif Floor(x: Real): Integer The largest integer that is less than or equal to x. Post: result <= x And result + 1 > x Round(x: Real): Integer The integer that is closest to x. When there are two such integers, the largest one. Post: (Abs(x - result) < 0.5) Or ((Abs(x - result) = 0.5) And result > x) Max(x: Real, y: Real): Real The maximum of x and y. Post: if x >= y then result = x else result = y endif Min(x: Real, y: Real): Real The minimum of x and y. Post: if x <= y then result = x else result = y endif <(x: Real, y: Real): Boolean True if x is less than y. >(x: Real, y: Real): Boolean True if x is greater than y. Post: result = Not(x <= y) <=(x: Real, y: Real): Boolean True if x is less than or equal to y. Post: result = (x = y) Or (x < y) >=(x: Real, y: Real): Boolean True if x is greater than or equal to y. Post: result = (x = y) Or (x > y) ToString(x: Real): String Converts x to a String value. Post: ToReal(result) = x ToInteger(x: Real): Integer Converts x to an Integer value, truncating towards zero. Post: if x >= 0 then Floor(x) else Neg(Floor(Neg(x)) endif ToReal(x: String): Real[0..1] Converts x to a Real value. Pre: x has the form of a legal Real value. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). Therefore, implementations are given the following permissions for representing Real numbers and performing computations on them, while still conforming to this specification. NOTE: The permissions below are intended, in particular, to allow the conformance of implementations using finite-precision floating-point representations for Real numbers (such as those based on the popular IEEE 754 standard), while still allowing for other implementations that may not need to take advantage of all the allowed permissions. 1. A conforming implementation may support only a limited range of Real values, such that the absolute value of any supported value is less than or equal to a specified maximum value. If the implementation limits the range of values support for Integer, then the maximum value specified for Real must be no less than the greatest absolute value of any supported Integer value. 2. A conforming implementation may support only a restricted value set for Real, defined as a non-dense subset of the infinite set of rational numbers (such that any bounded interval of this value set contains only a finite set of values) including zero and with no upper or lower bound. If the implementation limits the range of values supported for Integer, then the smallest positive value in the restricted value set shall be at least as small as the reciprocal of the largest supported Integer value. 3. A conforming implementation may provide distinct representations for Real positive zero and Real negative zero. These values shall be considered equal for the purposes of all comparison functions. However, they may be distinguished in certain arithmetic computations (see below). 4. A conforming implementation may include additional special values that are instances of the Real type but are not numeric values (such as infinite values and .not a number. values). Note that, even if included in an implementation of the Real type, none of these special values have any standard literal representation in UML. The functions in the RealFunctions package are specified in Table 9.4 in terms of the semantics for mathematical Real numbers, as defined in Clause 10. However, an implementation that takes advantage of some or all of the above permissions may not be able to produce exact results for some computations using these functions. Therefore, conformance to the function behaviors given in Table 9.4 shall be interpreted as follows. . Since a restricted value set is non-dense and unbounded, any exact value that is not in such a set will be between two values that are in the set. If a conforming implementation supports only a restricted value set, and the result of a computation is not a member of this set, then the implementation may implement the computation as resulting in one of the two values in the restricted value set that the exact result is between. (If the exact value of the computation is non-zero, but the chosen value in the restricted value set is zero, then the computation is said to underflow.) . If a conforming implementation supports only a limited range of values, then a computation that results in an exact value that is outside that range is said to overflow. The implementation may implement an overflowing computation as resulting in a special value (e.g., positive or negative infinity). If not, an overflowing computation shall be implemented as having an empty result. . If a numeric result is not defined for a call to a primitive function resulting in a Real value, because one of the arguments is a special value or because a precondition is violated, then a conforming implementation may produce a special value for its result. Otherwise, the computation shall be implemented as having an empty result. . If a conforming implementation supports signed zero, then multiplication of a numeric value by positive zero shall result in positive zero, while multiplication of a numeric value by negative zero shall result in negative zero. A conforming implementation shall not otherwise distinguish between positive and negative zero in any call to a primitive function that is specified as resulting in a numeric result. However, it may distinguish between them if the result is implemented as a special value (e.g., division by negative zero may result in negative infinity). . Other than as given above, this specification does not define the result of calling a primitive function in which one or more of the arguments that is a special value. In Subclause 10.3.1 Primitive Types, add. TBD Disposition: Resolved From: Ed Seidewitz To: "fuml-rtf@omg.org" Date: Thu, 7 Jun 2012 09:00:17 -0400 Subject: Draft Resolution to Issue 15987 on Real Thread-Topic: Draft Resolution to Issue 15987 on Real Thread-Index: Ac1ErS9qp0mGndmnRLycJIR0LOQqFg== Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-32767-c X-Mailprotector-ID: 12e5184a-99d5-40e7-8346-a142b9d3250f Attached is a complete draft resolution to Issue 15987 .The fUML Foundational Model Library should support the new UML 2.4 Real primitive type.. This includes the proposed update to the base semantics in Clause 10 with axioms for real numbers, which was provided by Conrad. I am still working on the resolution to Issue 15986 on moving fUML 1.1 to UML 2.4, which the attached resolution presumes. However, I am hoping to get both out on a ballot next week, before the Cambridge meeting. So if you have any further questions on the attached resolution, let me know as soon as possible. Thanks. -- Ed Issue-15987-Resolution.doc OMG Issue No: 15987 Title: The fUML Foundational Model Library should support the new UML 2.4 Real primitive type Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s@modeldriven.com seidewitz@acm.org) Summary: UML 2.4 has introduced a new Real primitive type. This should be supported by a new package of primitive functions in the fUML Foundational Model Library. Resolution: The UML 2.4.1 Infrastructure specification states that .A real is a primitive type representing the mathematical concept of real. and that .An instance of Real is an element in the infinite set of real numbers.. However, some care needs to be taken in defining the fUML execution semantics of the Real type and supporting primitive functions, such that it is actually possible for a real implementation to conform to those semantics. Now, the UML specification also says that .An instance of Integer is an element in the (infinite) set of integers... And the base semantics for buml:Integer in Subclause 10.3.1.2 of the fUML 1.0 specification does, indeed, include the mathematical axioms necessary to define this infinite set. However, Subclause 9.1 includes the permission that ..a conforming implementation may limit the supported values [of Integer] to a finite set.. Similarly, fUML should allow conforming implementations to limit the supported values of Real to a finite set. However, for Real numbers, this means more than just limiting the upper and lower bounds of the supported range of Real numbers. It also means dealing with the fact that Real numbers can only be represented to finite precision in an actual implementation. Generally, programming languages provide floating-point representations that approximate Real numbers. However, this is really an implementation representation, and the most commonly used standard referenced on floating-point numbers, IEEE 754, is actually a standard for the implementation of floating-point computation. For fUML, it is necessary to provide a precise semantic specification for Real numbers that is implementation independent but that provides clear criteria for the conformance of actual implementations. This should allow implementations based on a floating-point standard such as IEEE 754 but also allow implementations using, e.g., fixed-point computation or exact rational number computation. This can be achieved in three steps. 1. Axioms for the Real type need to be added to the fUML base semantics in Clause 10. 2. Criteria are needed in Clause 9 for conformance to the Real type as it is to be provided in the fUML Foundational Model Library. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). So, some permission is needed to allow for the conformance of implementations using, e.g., finite-precision floating-point representations. In addition, IEEE 754 requires some additional special values be represented in the floating-point formats it defines. Since it is expected that it will be common that the fUML Real type will be implemented using a floating-point representation based on IEEE 754, it is necessary to allow for the inclusion of such values in an implementation of Real. 3. Criteria are needed in Clause 9 for conformance to the semantics of the primitive functions for Real to be provided in the Foundational Model Library. The specification of the primitive functions for Real in the Foundational Model Library will define the exact real number result of applying those functions. It is then necessary to define how these exact results may be represented in a conforming implementation that takes advantage of some or all of the permissions allowed relative to the representation of Real numbers. Revised Text: (NOTE: This resolution presumes the resolution of Issue 15986, .fUML 1.1 should be based on UML 2.4..) In Subclause 9.1 Primitive Types, Table 9.1, add the following row after the row for Integer: Real The Real type has literal values in the infinite, continuous set of real numbers. However, a conforming implementation may limit the support values to a finite subset (see 9.2.3 for further discussion of this). In Subclause 9.2 Primitive Behaviors, add a RealFunctions package to Figure 9.2. In the first paragraph of Subclause 9.2.2 Integer Functions, remove the sentence: The OCL ./. operation is not included, since this returns a Real value, and the Foundational Model Library does not support a Real primitive type. In Table 9.3, add the following row, after the row for the .*. function: /(x: Integer, y: Integer): Real[0..1] The value of the division of x by y. Pre: y<>0 Post: result = ToReal(x) / ToReal(y) NOTE: The ToReal and ./. functions used here are those from the RealFunctions package (see 9.2.3). Add the following subclause and renumber subsequent subclauses and tables appropriately: 9.2.3 Real Functions Table 9.4 lists the function behaviors that are included in the package RealFunctions. The naming is consistent with OCL, including the use of the conventional symbols for arithmetic functions, except that the negation function is named .Neg., rather than overloading the symbol .-., and alphabetic names are capitalized, per the usual convention for behaviors (as kinds of classes). The Foundation Model Library also provides ToString and ToInteger functions not found in OCL 2.0. The ToReal function does correspond to an OCL operation, though, in OCL, it is a String operation. Table 9.4 . Foundation Model Library Real Functions Function Signature Description Neg(x: Real): Real The negative value of x. +(x: Real, y: Real): Real The value of the addition of x and y. -(x: Real, y: Real): Real The value of the subtraction of x and y. Post: result + y = x Inv(x: Real): Real The inverse (reciprocal) value of x. *(x: Real, y: Real): Real The value of the multiplication of x and y. /(x: Real, y: Real): Real[0..1] The value of the division of x by y. Pre: y<>0 Post: result * y = x Abs(x: Real): Real The absolute value of x. Post: if x < 0 then result = Neg(x) else result = x endif Floor(x: Real): Integer The largest integer that is less than or equal to x. Post: result <= x And result + 1 > x Round(x: Real): Integer The integer that is closest to x. When there are two such integers, the largest one. Post: (Abs(x - result) < 0.5) Or ((Abs(x - result) = 0.5) And result > x) Max(x: Real, y: Real): Real The maximum of x and y. Post: if x >= y then result = x else result = y endif Min(x: Real, y: Real): Real The minimum of x and y. Post: if x <= y then result = x else result = y endif <(x: Real, y: Real): Boolean True if x is less than y. >(x: Real, y: Real): Boolean True if x is greater than y. Post: result = Not(x <= y) <=(x: Real, y: Real): Boolean True if x is less than or equal to y. Post: result = (x = y) Or (x < y) >=(x: Real, y: Real): Boolean True if x is greater than or equal to y. Post: result = (x = y) Or (x > y) ToString(x: Real): String Converts x to a String value. Post: ToReal(result) = x ToInteger(x: Real): Integer Converts x to an Integer value, truncating towards zero. Post: if x >= 0 then Floor(x) else Neg(Floor(Neg(x)) endif ToReal(x: String): Real[0..1] Converts x to a Real value. Pre: x has the form of a legal Real value. The set of Real numbers includes values that cannot be represented in finite precision (e.g., irrational numbers and those rational numbers with infinite repeating digit representations in the base being used). Therefore, implementations are given the following permissions for representing Real numbers and performing computations on them, while still conforming to this specification. NOTE: The permissions below are intended, in particular, to allow the conformance of implementations using finite-precision floating-point representations for Real numbers (such as those based on the popular IEEE 754 standard), while still allowing for other implementations that may not need to take advantage of all the allowed permissions. 1. A conforming implementation may support only a limited range of Real values, such that the absolute value of any supported value is less than or equal to a specified maximum value. If the implementation limits the range of values support for Integer, then the maximum value specified for Real must be no less than the greatest absolute value of any supported Integer value. 2. A conforming implementation may support only a restricted value set for Real, defined as a non-dense subset of the infinite set of rational numbers (such that any bounded interval of this value set contains only a finite set of values) including zero and with no upper or lower bound. If the implementation limits the range of values supported for Integer, then the smallest positive value in the restricted value set shall be at least as small as the reciprocal of the largest supported Integer value. 3. A conforming implementation may provide distinct representations for Real positive zero and Real negative zero. These values shall be considered equal for the purposes of all comparison functions. However, they may be distinguished in certain arithmetic computations (see below). 4. A conforming implementation may include additional special values that are instances of the Real type but are not numeric values (such as infinite values and .not a number. values). Note that, even if included in an implementation of the Real type, none of these special values have any standard literal representation in UML. The functions in the RealFunctions package are specified in Table 9.4 in terms of the semantics for mathematical Real numbers, as defined in Subclause 10.3.1. However, an implementation that takes advantage of some or all of the above permissions may not be able to produce exact results for some computations using these functions. Therefore, conformance to the function behaviors given in Table 9.4 shall be interpreted as follows. . Since a restricted value set is non-dense and unbounded, any exact value that is not in such a set will be between two values that are in the set. If a conforming implementation supports only a restricted value set, and the result of a computation is not a member of this set, then the implementation may implement the computation as resulting in one of the two values in the restricted value set that the exact result is between. (If the exact value of the computation is non-zero, but the chosen value in the restricted value set is zero, then the computation is said to underflow.) . If a conforming implementation supports only a limited range of values, then a computation that results in an exact value that is outside that range is said to overflow. The implementation may implement an overflowing computation as resulting in a special value (e.g., positive or negative infinity). If not, an overflowing computation shall be implemented as having an empty result. . If a numeric result is not defined for a call to a primitive function resulting in a Real value, because one of the arguments is a special value or because a precondition is violated, then a conforming implementation may produce a special value for its result. Otherwise, the computation shall be implemented as having an empty result. . If a conforming implementation supports signed zero, then multiplication of a numeric value by positive zero shall result in positive zero, while multiplication of a numeric value by negative zero shall result in negative zero. A conforming implementation shall not otherwise distinguish between positive and negative zero in any call to a primitive function that is specified as resulting in a numeric result. However, it may distinguish between them if the result is implemented as a special value (e.g., division by negative zero may result in negative infinity). . Other than as given above, this specification does not define the result of calling a primitive function in which one or more of the arguments is a special value. Replace the contents of Subclause 10.3.1.2 (Numbers) with The less-than relation. (forall (x y) (if (buml:less-than x y) (and (buml:Real x) (buml:Real y)))) (forall (x y) (if (buml:less-than x y) (and (not (buml:less-than y x)) (not (= x y))))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (or (form:less-than x y) (form:less-than y x) (= y x)))) (forall (x y) (iff (buml:less-than x y) (and (buml:Real x) (buml:Real y) (not (buml:less-than y x)) (not (= x y))))) (forall (x y z) (if (and (buml:less-than x y) (buml:less-than y z)) (buml:less-than x z))) (forall (x z) (if (buml:less-than x z) (exists (y) (and (buml:less-than x y) (buml:less-than y z))))) The add relation. (forall (x y z) (if (buml:add x y z) (and (buml:Real x) (buml:Real y) (buml:Real z)))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (exists (z) (buml:add x y z)))) (forall (x y z1 z2) (if (and (buml:add x y z1) (buml:add x y z2)) (= z1 z2))) (forall (x y zxy zyx) (if (and (buml:add x y zxy) (buml:add y x zyx)) (= zxy zyx))) (forall (x y z xy yz rxy ryz) (if (and (buml:add x y xy) (buml:add xy z rxy) (buml:add y z yz) (buml:add x yz ryz)) (= rxy ryz))) (forall (x y xz yz) (if (and (buml:add x z xz) (buml:add y z yz) (buml:less-than x y)) (buml:less-than xz yz))) (buml:Real form:0) (forall (x x0) (if (buml:add x form:0 x0) (= x x0))) (forall (x y) (iff (buml:neg x y) (buml:add x y form:0))) (forall (x) (if (buml:Real x) (exists (nx) (buml:neg x nx)))) The mult relation. (forall (x y z) (if (buml:mult x y z) (and (buml:Real x) (buml:Real y) (buml:Real z)))) (forall (x y) (if (and (buml:Real x) (buml:Real y)) (exists (z) (buml:mult x y z)))) (forall (x y z1 z2) (if (and (buml:mult x y z1) (buml:mult x y z2)) (= z1 z2))) (forall (x y zxy zyx) (if (and (buml:mult x y zxy) (buml:mult y x zyx)) (= zxy zyx))) (forall (x y z xy yz rxy ryz) (if (and (buml:mult x y xy) (buml:mult xy z rxy) (buml:mult y z yz) (buml:mult x yz ryz)) (= rxy ryz))) (forall (x y xy) (if (and (buml:mult x y xy) (buml:less-than form:0 x) (buml:less-than form:0 y)) (buml:less-than form:0 xy))) (buml:Real form:1) (forall (x x1) (if (buml:mult x form:1 x1) (= x x1))) (forall (x y) (iff (buml:inv x y) (buml:mult x y form:1))) (forall (x) (if (and (buml:Real x) (not (= x form:0))) (exists (ix) (buml:inv x ix)))) (forall (x y z yz rxyz xy xz xyxz) (if (and (add y z yz) (mult x yz xyz) (mult x y xy) (mult x z xz) (add xy xz xyxz)) (= xyz xyxz))) (less-than form:0 form:1) Rational, integer, natural, unlimited natural, and whole numbers. (forall (x) (if (form:RationalNumber x) (buml:Real x))) (forall (x z) (if (and (form:Rational x) (form:Rational z) (buml:less-than x z)) (exists (y) (and (form:Rational y) (buml:less-than x y) (buml:less-than y z))))) (forall (x z) (if (and (form:Rational x) (form:Rational z) (buml:less-than x z)) (exists (y) (and (buml:Real y) (not (form:Rational y)) (buml:less-than x y) (buml:less-than y z))))) (forall (y) (if (and (buml:Real y) (not (form:Rational y))) (and (not (exists (xu) (and (form:Rational xu) (forall (x) (and (Rational x) (buml:less-than x y) (or (buml:less-than x xu) (= x xu))))))) (not (exists (zl) (and (form:Rational zl) (forall (z) (and (Rational z) (buml:less-than y z) (or (buml:less-than zl z) (= zl z)))))))))) (forall (x) (if (buml:Integer x) (form:Rational x))) (forall (x y) (iff (form:add-one x y) (form:add x form:1 y))) (forall (x) (iff (buml:Integer x) (or (= x form:0) (exists (y) (and (buml:Integer y) (or (form:add-one y x) (form:add-one x y))))))) (forall (x) (iff (form:NaturalNumber x) (and (buml:Integer x) (or (= x form:0) (buml:less-than form:0 x))))) (forall (x) (iff (buml:UnlimitedNatural x) (or (form:NaturalNumber x) (= x buml:*)))) (forall (x) (iff (form:WholeNumber x) (and (form:NaturalNumber x) (not (= x form:0))))) Disposition: Resolved