Extra precision or range for fixed point representations AI00341/15 1
890926 BI WI
 !standard 03.05.09 (09) 890926 AI00341/15
!standard 13.02 (12)
 !class binding interpretation 850618 (provisional classification)
 !status workitem 890227
 !status failed letter ballot (760) 890227
!status ARGapproved 890130 (reviewed) (pending letter ballot)
!status ARGapproved (1102) 880119 (pending editorial review; ballot)
!status workitem 871228
!status returned to ARG by WG9 871207
!status approved by Ada Board 870730
!status panel/committeeapproved 870316 (reviewed)
!status panel/committeeapproved (600) 861114 (pending editorial review)
!status workitem 860724
!status returned to committee by WG9 860509
!status committeeapproved (801) 851120
!status workitem 851031
!status received 850618
 !references AI00099
!topic Extra precision or range for fixed point representations
 !summary 881207 (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 861223 (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 AI00341/15 2
890926 BI WI
 !recommendation 890926 (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 881207 (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 AI00099).
DRAFT DRAFT DRAFT
Extra precision or range for fixed point representations AI00341/15 3
890926 BI WI
 !appendix 890926

 *****************************************************************************

 !section 03.05.09 (07) R.P. Wehrum/Siemens AG Munich 850117 8300552
 !version 1983
 !topic Attributes of anonymous predefined fixedpoint 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 fixedpoint types are anonymous and it is
 therefore impossible to employ these attributes directly. What is
 (probably) meant is the following:

 Let F be any fixedpoint 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 selfevident,
 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 860808
 !version 1983
 !topic relation to AI00099

 !reference AI00341/04

 This version of AI00341 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 AI00341/15 4
890926 BI WI
 *****************************************************************************

 !section 03.05.09 (09) M. Woodger 860916 8300804
 !version 1983
 !topic representation of base type of a fixed point type

 !reference AI00341/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 861202 8300881
 !version 1983
 !topic LeftJustification of FixedPoint

 Ada's fixedpoint 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 leftjustified
 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 selfevident 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,
 "FixedPoint 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 AI00341/15 5
890926 BI WI
 *****************************************************************************

 !section 03.05.09 (09) John Goodenough 871228
 !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 880210 8300960
 !version 1983
 !topic Precision of fixed point value representation

 !reference AI00341/11

 I have discussed this with JeanLoup Gailly and looked again at the papers
 by Froggatt and Hilfinger, and AI99/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 JLG. Version 11 of AI341 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 AI341 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
 (AI99/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 AI99/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 AI341 should emphasize the difference between the
DRAFT DRAFT DRAFT
Extra precision or range for fixed point representations AI00341/15 6
890926 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 JLG 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 880525 8300977
 !version 1983
 !topic Comment on AI00341

 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 rangerelated 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. AI00341 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 rangerelated scalings.

 Whilst it's probably too late to change the default powersof2, perhaps Ada
 9X could offer a simple "for FIXED_TYPE use range;"?


 *****************************************************************************

 !section 03.05.09 (09) J. Goodenough 881208
 !version 1983
 !topic Inconsistency with AI99

 The recommendation of AI00341/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 AI99.
 AI99 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 AI00341/15 7
890926 BI WI
 type DF1 is new F1 delta 4.0;
 for DF1'SMALL use ...;

 The response in AI99 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 AI00341), 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 AI00138).

 These arguments are no longer consistent with AI00341. Since AI341/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 AI99, 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 AI341/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 AI00341/15 8
890926 BI WI
 is inconsistent with this intent to allow an implementation to provide more
 accuracy.


 *****************************************************************************

 !section 03.05.09 (09) Mike Woodger 880113
 !version 1983
 !topic comments on version 13

 My opinion remains as in the appendix (8300960), 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 AI099/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 rangerelated 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 890926
 !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
 AI00099, 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 AI00341/15 9
890926 BI WI
  According to AI00341, 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 AI00099.
 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 (724) 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
 timeconsuming 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 AI00341/15 10
890926 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 AI00341 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