Extra precision or range for fixed point representations AI-00341/15 1 89-09-26 BI WI | !standard 03.05.09 (09) 89-09-26 AI-00341/15 !standard 13.02 (12) | !class binding interpretation 85-06-18 (provisional classification) | !status work-item 89-02-27 | !status failed letter ballot (7-6-0) 89-02-27 !status ARG-approved 89-01-30 (reviewed) (pending letter ballot) !status ARG-approved (11-0-2) 88-01-19 (pending editorial review; ballot) !status work-item 87-12-28 !status returned to ARG by WG9 87-12-07 !status approved by Ada Board 87-07-30 !status panel/committee-approved 87-03-16 (reviewed) !status panel/committee-approved (6-0-0) 86-11-14 (pending editorial review) !status work-item 86-07-24 !status returned to committee by WG9 86-05-09 !status committee-approved (8-0-1) 85-11-20 !status work-item 85-10-31 !status received 85-06-18 | !references AI-00099 !topic Extra precision or range for fixed point representations | !summary 88-12-07 (DRAFT) When T is declared by a fixed point type declaration and no length clause specifying SMALL is given for T, then T'BASE'SMALL can be less than T'SMALL, i.e., in this case, a fixed point base type can have more precision than that required by the fixed point constraint. If a length clause specifying SMALL is given for T, however, then T'SMALL = T'BASE'SMALL and T'SMALL is the value of the base type's least significant bit. The value of MANTISSA for a fixed point base type can be greater than the value required by the fixed point constraint in a type declaration and any length clause defining SMALL. If no length clause is given, any extra bits can be used to provide extra precision or extra range (or both). If a length clause specifying SMALL is given, the extra bits can only be used to provide extra range for the base type. | !question 86-12-23 (DRAFT) Consider a type declaration of the form: type T is delta D range L .. R; Can T'BASE'SMALL be less than T'SMALL, i.e., can T's base type have more precision than is required by the fixed point constraint? Can T'BASE'SMALL be less than T'SMALL, even when an explicit length clause for T'SMALL is specified? Can T'BASE'MANTISSA be greater than T'MANTISSA, i.e, can T's base type have more model numbers than are required by the fixed point constraint (and length clause for SMALL, if any)? DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 2 89-09-26 BI WI | !recommendation 89-09-26 (DRAFT) For a fixed point type declared with a real type definition, the value of | SMALL for the base type is the value given by a length clause that defines the value of SMALL for the type; otherwise the value of SMALL for the base type can be less than the value required by the fixed point constraint. The value of MANTISSA for a fixed point base type can be greater than the value required by the fixed point constraint in a type declaration and any length clause defining SMALL. | !discussion 88-12-07 (DRAFT) 3.5.9(9) states that a fixed point type declaration of the form: type T is delta D range L .. R; is, "by definition," equivalent to the following declarations: type %fixed_point_type% is new predefined_fixed_point_type; subtype T is %fixed_point_type% range %fixed_point_type%(L) .. %fixed_point_type%(R); If this equivalence is taken literally, then subtype T has THE SAME model numbers as %fixed_point_type% (see 3.5.9(14), noting that the subtype indication in the equivalence is a range constraint, not a fixed point constraint). But 3.5.9(10) says the model numbers of the predefined_fixed_ point_type "include the model numbers defined by the fixed point constraint (... and possibly by a length clause defining SMALL)." There would be no need to use the word "include" unless it was intended that the predefined fixed point type be allowed to have greater precision and/or range (and hence more model numbers). The equivalence stated in 3.5.9(9, 10) is not formulated as intended since it does not allow base types to have other than the required set of model numbers. It was intended to allow an implementation to choose a base type with finer precision or greater range than that required by 3.5.9(5). However, it was also intended that a specified value of SMALL completely determine the precision of the base type. 13.2(12) says: The effect of the length clause is to use this value of SMALL for the representation of values of the fixed point base type. That is, the value of T'SMALL = T'BASE'SMALL when such a length clause is given, and this value is the value of the base type's least significant bit. This means an implementation is not allowed to provide additional accuracy. If a specification of SMALL is given for a derived fixed point type, the specification can only be accepted if the parent type and the derived (base) type have the same model numbers (see AI-00099). DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 3 89-09-26 BI WI | !appendix 89-09-26 | | ***************************************************************************** | | !section 03.05.09 (07) R.P. Wehrum/Siemens AG Munich 85-01-17 83-00552 | !version 1983 | !topic Attributes of anonymous predefined fixed-point types. | | LRM 03.05.09(7) states that "The model numbers of each predefined fixed | point type comprise...numbers for which mantissa...has the number of | binary digits returned by the attribute MANTISSA, and for which the number | small has the value returned by the sttribute SMALL." | | However, the predefined fixed-point types are anonymous and it is | therefore impossible to employ these attributes directly. What is | (probably) meant is the following: | | Let F be any fixed-point subtype. Then one can get the values for the attributes | MANTISSA and SMALL of the underlying predefined type by using | F'BASE'MANTISSA and F'BASE'SMALL, resp. If this interpretation is | correct, then it should be expressed like this in the LRM. | | If 03.05.09 (9) is taken literally - what is not self-evident, | remember the discussions on the staticness of subtypes - then one can | deduce that the underlying predefined type must always have the same | value for small as the subtype under consideration (provided that a | subtype that does not specify a new delta inherits the delta from its parent). | However, according to 03.05.09 (10) one can get the impression that | the predefined type may possess a finer small (what would be not | unreasonable to allow). A clarification is needed. | | | ***************************************************************************** | | !section 03.05.09 (07) J. Goodenough 86-08-08 | !version 1983 | !topic relation to AI-00099 | | !reference AI-00341/04 | | This version of AI-00341 allows a base type to have more precision than that | specified for the declared type. Is this conclusion also true if a length | clause for SMALL has been given, i.e., is it the intent that an explicit | length clause define SMALL for the base type, or can the base type's least | significant bit have a value that is even less than the specified SMALL? | | The wording of the recommendation should address this point explicitly. | DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 4 89-09-26 BI WI | ***************************************************************************** | | !section 03.05.09 (09) M. Woodger 86-09-16 83-00804 | !version 1983 | !topic representation of base type of a fixed point type | | !reference AI-00341/05 | | The discussion section of this commentary has overlooked the | possibility that T'SMALL can be specified by a length clause; | this is explicitly mentioned in 3.5.9(14). In such a case the | delta given in the fixed point constraint is not used to define | the model numbers of T, so the argument breaks down. Use of the | word "include" in 3.5.9(10) can now be explained as covering | precisely this case where T'SMALL is specified. | | Perhaps the following should be appended to the summary: | | "This only happens when T'SMALL is specified by a length | clause." | | | ***************************************************************************** | | !section 03.05.09 (16) Terry Froggatt 86-12-02 83-00881 | !version 1983 | !topic Left-Justification of Fixed-Point | | Ada's fixed-point arithmetic is intended as an approximation to real | arithmetic: consequently, there are never "spare bits", just better and | worse approximations. So numbers should always be as far left-justified | within the chosen wordlength as the range permits, subject to Ada's | constraint that the "small" (whether a default power of two or that | given by a small representation clause) is mapped exactly onto some bit. | | To me, this statement is as self-evident for | accuracy as the statement that a compiler should not generate | spurious NOPs is for time and space. | This matter is discussed in some more detail in my paper, | "Fixed-Point Conversion, Multiplication, & Division, in Ada(R)", | to appear shortly in Ada Letters. | | Unfortunately, the majority of people who read 3.5.9 seem to jump to | the conclusion that Ada expects "small" to be mapped onto unity: | i.e. Right Justification. In fact "small" only determines what | the model numbers and minimum legal accuracy are. | | I believe that the Notes in the LRM (not just the Implementor's guide) | should make it clear that "Left Justification" is permitted | by the language and is the most desirable form of implementation. | DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 5 89-09-26 BI WI | ***************************************************************************** | | !section 03.05.09 (09) John Goodenough 87-12-28 | !version 1983 | !topic returned to ARG | | WG9 returned this commentary to the ARG to consider further whether the | specification of SMALL with a representation clause should not be considered | to dictate the value of the least significant bit of the base type. The | recommendation of the returned version (version 10) specifies: | | For a fixed point type declared by a type declaration, the value of | SMALL for the base type can be less than the value required by the | fixed point constraint and any length clause defining SMALL. | Similarly, the value of MANTISSA for the base type can be greater | than the value required by the fixed point constraint and any length | clause defining SMALL. | | | ***************************************************************************** | | !section 13.02 (12) M. Woodger 88-02-10 83-00960 | !version 1983 | !topic Precision of fixed point value representation | | !reference AI-00341/11 | | I have discussed this with Jean-Loup Gailly and looked again at the papers | by Froggatt and Hilfinger, and AI-99/11. | | The situation we have is the specification of small, as described in | 13.2(12), also specifies the representation of values of the base type to | use the least significant bits for the mantissa. If we could change the | language, it would be preferable to separate these two things and to allow | specification of small (for use as an arbitrary scale factor) without | prejudice to its representation, which would allow extra precision as | advocated by Froggatt, and would make Ada's fixed point more useful in the | opinion of J-LG. Version 11 of AI-341 was doing just that! I am surprised | that WG9 sent it back to be "less useful" (I did not attend the December | meeting). | | The proposed new conclusion of AI-341 is not a disaster, however, and I will | support it. But it does mean that representation with specified small is | entirely different from the default binary case (which retains freedom of | representation). In particular, when small is specified for a derived type | (AI-99/11) and not for the parent type, the compiler has to treat the values | of the derived base type as of an entirely different type - although | nominally "a copy of the set of possible values for the parent type" | (3.4(4)). It certainly seems that AI-99/11 now violates 3.4(4), since only | the model numbers get "copied" but there can be other values of the parent | type. | | The new wording of AI-341 should emphasize the difference between the DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 6 89-09-26 BI WI | effects of the default small and specified small. The original wording was | fine up to the last sentence. Only when small is specified does one | necessarily get T'SMALL = T'BASE'SMALL. Then there are no values other than | the model numbers, and small corresponds to the least significant bit of the | word. | | A final point: neither J-LG nor I understand what PNH meant by requiring | intermediate results to have no extra precision. Section 4.5.5(11) | requires explicit conversion of the result of multiplication or division of | two fixed point operands. For one integer operand the representation does | not change, but why say this here? | | | ***************************************************************************** | | !section 03.05.09 (09) Terry Froggatt 88-05-25 83-00977 | !version 1983 | !topic Comment on AI-00341 | | I am worried that we are moving away from viewing fixed point numbers in Ada | as "real" towards "dollars and cents". | | The way the language is at present, SMALL is a power of two by default, and | the only way to get range-related scales is to use a 'SMALL rep. spec. | | It's a bad idea to give 'SMALL rep.specs the additional semantics of forcing | the compiler to remove any accuracy which it can offer at no cost in time and | space. AI-00341 presently requires the compiler to remove extra accuracy that | can be provided. | | (It won't be long before someone suggests that real arithmetic in the compiler | should emulate the inaccuracies of the target!) | | I would strongly recommend that this change to 'SMALL be deferred, UNTIL the | language offers a better way to get range-related scalings. | | Whilst it's probably too late to change the default powers-of-2, perhaps Ada | 9X could offer a simple "for FIXED_TYPE use range;"? | | | ***************************************************************************** | | !section 03.05.09 (09) J. Goodenough 88-12-08 | !version 1983 | !topic Inconsistency with AI-99 | | The recommendation of AI-00341/13 says that a specification of SMALL | determines the value of the least significant bit of the base fixed point | type. This recommendation is inconsistent with the assumption of AI-99. | AI-99 considers when a specification is SMALL is allowed for a derived fixed | point type, and what specified values are allowed. It considers the example: | | type F1 is delta 1.0 range -15.0 .. 15.0; -- F1'SMALL = 1.0 DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 7 89-09-26 BI WI | type DF1 is new F1 delta 4.0; | for DF1'SMALL use ...; | | The response in AI-99 says: | | 3.4(4) says the set of values of a derived type is a copy of the set of | values for the parent type. 3.5.6(3) says an implementation of a real type | must include the model numbers of the type and represent them exactly. The | effect of specifying SMALL for a fixed point type is to help establish | the model numbers of the type. Since the model numbers must be | representable values of the type, and since the values of a derived type | are determined by the parent type, no representation clause is allowed for | a derived fixed point type unless the model numbers determined by the | clause are representable values. (In addition, 13.2(12) requires that the | specified value of SMALL not exceed the delta of the type.) | | With respect to the example, DF1'DELTA is 4.0, so a value specified for | DF1'SMALL must not exceed 4.0. In addition, the values of DF1 include at | least the model numbers of parent subtype F1. These model numbers are | -15.0, -14.0, ..., 14.0, 15.0. If DF1'SMALL is specified to be 4.0, the | mantissa for DF1 must be 2, so the model numbers for DF1 will be -12.0, | -8.0, -4.0, 0.0, 4.0, 8.0, and 12.0. Since these are all values of type | F1, such a specification of SMALL is allowed. If the specified value | of SMALL is 3.0, the mantissa for DF1 must be 3 (to ensure the bounds | of the subtype are within SMALL of model numbers), so the model numbers | for DF1 will be -21.0, -18.0, ..., 18.0, 21.0. If the chosen base type for | F1 includes these values (see AI-00341), then the representation clause is | allowed. On the other hand, if the base type for F1 has only four mantissa | bits, then the range of representable values is just -15.0 .. 15.0, and the | representation clause for SMALL would not be allowed. | | If the representation clause for DF1'SMALL specifies 0.1, then the mantissa | of DF1 must be 8 and the model numbers for DF1 will be -25.5, -25.4, ..., | 25.4, 25.5. If these model numbers are not represented exactly in the | value set for F1's base type, such a representation clause must be | rejected. | | These arguments are not affected by the presence of an explicit (or | implicit) representation clause for the parent type (see AI-00138). | | These arguments are no longer consistent with AI-00341. Since AI-341/13 says | that the specification of SMALL exactly determines the derived base type's | precision, the only allowed value that can be specified for a derived fixed | point type is the parent type's value of SMALL; otherwise, the set of values | for the derived (base) type would not be a copy of the parent (base) type's | set of values. For the example given in AI-99, this means that any value of | SMALL that is allowed for the parent type is allowed for the base type (since | SMALL has not been specified for the parent type), but no other values are | allowed. In particular, the specified value of SMALL must be less than 1.0, | the delta of the parent type. | | The basic reason for the position in AI-341/13 is that an explicit | specification of SMALL was intended to determine the base type's accuracy. It DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 8 89-09-26 BI WI | is inconsistent with this intent to allow an implementation to provide more | accuracy. | | | ***************************************************************************** | | !section 03.05.09 (09) Mike Woodger 88-01-13 | !version 1983 | !topic comments on version 13 | | My opinion remains as in the appendix (83-00960), but without support for this | AI. The present version is just "rubbing salt into the wound" that was caused | when the language design team, at the last moment, introduced specification of | small _as a representation matter_. (The number of places at which the effect | of this specification on the model numbers has been overlooked in the wording | of the Standard bears witness to the rush with which it was done.) | | Given that we cannot undo the damage done by 13.2(12) - until Ada 9X - we | should not make matters worse by forcing compilers to remove any accuracy they | can offer at no cost in time or space (to quote Terry Froggatt). I believe | that we should both abandon this AI and revoke AI-099/11, which has gained WG9 | approval but violates 3.4(4). | | Now is the time to make a strong case for a change for Ada 9X, to try to meet | the Ironman requirement for range-related scalings (Froggatt), a "poor man's | floating point" (Wichmann), and to separate this from the "dollars and cents" | treatment which is of so little use. | | | ***************************************************************************** | | !section 03.05.09 (09) John Goodenough 89-09-26 | !version 1983 | !topic Extract from minutes of February 1989 ARG meeting | | No one appeared to disagree with the substance of the commentary, namely, | that an explicit specification of SMALL determines the value of SMALL for a | fixed point base type, and hence, the accuracy of operations for that type. | But several members were concerned about the effect of this recommendation on | AI-00099, an approved commentary. The concern was expressed using the | following example: | | type F1 is delta 0.5 range 0.0 .. 1.0; -- 1 | type DF1 is new F1; -- 2 | for DF1'SMALL use 0.125; -- 3 | XDF1 : DF1; -- 4 | | Analysis of this example: | | - After line 1, F1'BASE'SMALL has not been determined. | | - The derivation at line 2 does not determine F1'BASE'SMALL. | DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 9 89-09-26 BI WI | - According to AI-00341, the length clause at line 3 determines | DF1'BASE'SMALL. However, 3.4(4) says that the set of values of the | derived (base) type is a copy of the set of values of the parent | (base) type. The set of values for a base type depends on the base | type's value of SMALL, so F1'BASE'SMALL apparently must equal | DF1'BASE'SMALL. Therefore, it would appear that the specification | of SMALL for DF1, if accepted, implicitly specifies the value of | SMALL for F1's base type, contradicting the discussion of AI-00099. | More important, such an implicit "retroactive" specification of | SMALL for a parent type is unexpected and potentially awkward for | an implementation. | | - The object declaration at line 4 is a forcing occurrence for DF1, | but is not considered to be a forcing occurrence for the parent | type, F1. | | A straw vote was taken on whether it was considered useful (i.e., desirable) | to have two fixed point types related by derivation whose base types had | different values of SMALL. The vote was (7-2-4) in favor, although the | reasoning for the above example apparently does not allow such a result. | | In trying to find a viewpoint that allowed the desired capability, it was | suggested that perhaps one could consider that every fixed point type's | values are the values of type UNIVERSAL_FIXED, but the accuracy of operations | on these values would be dictated by the value of SMALL for the base type. | This would allow types related by derivation to have the same set of values | but would allow different values of SMALL for the base types. | | One objection to this possibility was the potential complexity of conversions | between values having different SMALL values. For example, consider: | | package P is | type F2 is delta 1.0/13 range 0.0 .. 1.0; | for F2'SMALL use 1.0/13; | procedure P (X : in out F2); | end P; | | with P; | package Q is | type DF2 is new F2 delta 1.0/12; | -- subprogram P is derived. | for DF2'SMALL use 1.0/12; | end; | | Calls to P must convert between values with a SMALL of 1/12 and values with a | SMALL of 1/13. Such a conversion in general requires a division, a more | time-consuming implicit change of representation than is generally considered | consistent with the intent of implicit conversions applied when calling a | derived subprogram. Moreover, such implicit conversions are dangerous | because accuracy could be lost implicitly. For example: | | X : Q.DF2 := 1.0/12; | ... DRAFT DRAFT DRAFT Extra precision or range for fixed point representations AI-00341/15 10 89-09-26 BI WI | P (X); | | Suppose P does not actually assign a new value to X. Because of the implicit | conversion to type F2, the value of X after the call will not necessarily be | equal to X's value before the call -- an unexpected and potentially dangerous | result. This result occurs only because the model numbers of the derived | type, DF2, are not a subset of the model numbers of its parent type, F2. | | It was then suggested that a specification of SMALL not be allowed for a | parent type after a type derivation. This would allow an implementation to | choose the parent type's SMALL at the place of the type derivation. Robert | Dewar was asked to consider the issue for further discussion at the next | day's meeting. | | ----------- | | Discussion of AI-00341 was continued from the previous day. Robert Dewar | proposed that derivation of a fixed point type be considered to determine the | size and SMALL of the parent (base) type (if not already determined). The | effect of determining these aspects of the type's representation is to | determine the base type's set of values. The reason for suggesting that | derivation be considered to determine the base type's size was illustrated by | the following example: | | type F3 is delta 0.5 range 0.0 .. 1.0; | type NF3 is new F3; | for F3'SIZE use 32; | | If F3 and NF3 are to have the same set of values, then the size of NF3's base | type must be determined by the size specification for its parent type, even | though the size specification occurs after the type derivation. | | Paul Hilfinger suggested that it should be possible to change the size of a | derived type without implying a change in the set of values: | | type F4 is delta ...; | for F4'SIZE use 32; | | type NF4 is new F4; | for NF4'SIZE use 16; | | A straw vote was taken to see how many people thought it would be acceptable | to forbid a specification of both the size and the value of SMALL for a | parent type after the parent type is used in a type derivation. Although | there was general sentiment that it was probably desirable to forbid a | specification of SMALL for a parent type after its use in a derivation, there | was no agreement on whether the specification of 'SIZE should also be | restricted. Robert Dewar agreed to prepare a further discussion of the | issues. DRAFT DRAFT DRAFT