An underflowed value need not be equal to 0.0 AI00543/03 1
890620 co WI
 !standard 13.07.03 (09) 890620 AI00543/03
 !class confirmation 870915 (provisional classification)
 !status workitem 890616
 !status returned to the ARG by WG9 890616
!status ARGapproved 890130 (reviewed)
!status ARGapproved (1105) 870915 (pending editorial review)
!status ALMPapproved (600) 870915 (pending editorial review)
 !status received 870805
 !topic An underflowed value need not be equal to 0.0

 !summary 890620 (DRAFT)

 If the smallest normalized machine representable value is divided by a real
 number greater than one, the underflowed result need not be exactly equal to
 zero.

 !question 890620 (DRAFT)

 Suppose T'MACHINE_RADIX is 2. Consider the following expression which is the
 smallest normalized machine representable value, since 2#0.1# is the smallest
 normalized value, and 2.0**T'MACHINE_EMIN is the smallest machine
 representable exponent value:

 (T'(2#0.1#)*2.0**T'MACHINE_EMIN)

 Suppose this value is divided by 2.0 and compared with zero:

 (T'(2#0.1#)*2.0**T'MACHINE_EMIN)/2.0 = 0.0
Is this expression required to have the value TRUE?
 !response 890620 (DRAFT)
13.7.3(5) says:
For floating point types, the following attributes provide
characteristics of the underlying machine representation, in
terms of the canonical form defined in section 3.5.7.
13.7.3(9) defines T'MACHINE_EMIN as follows:
Yields the smallest (most negative) value of EXPONENT for the
machine representation of the base type of T. The value of this
attribute is of the type universal_integer.
A note, 13.7.3(11) says:
[For many machines] the smallest positive representable number is
F'MACHINE_RADIX ** (F'MACHINE_EMIN  1)
For example, if F'MACHINE_RADIX is 2 and F'MACHINE_EMIN is 128, then
 2#0.1#E128 is the above value since 2.0**129 is the same as (2.0**1)*
(2.0*2.0**129). Let us call this value MIN. The value of:
DRAFT DRAFT DRAFT
An underflowed value need not be equal to 0.0 AI00543/03 2
890620 co WI
MIN/2.0 = 0.0
can be either TRUE or FALSE. To see this, first note that the value of MIN
must be less than or equal to the smallest positive safe number, F'SAFE_
SMALL, since if MIN were larger than F'SAFE_SMALL, F'SAFE_SMALL's canonical
representation would have an exponent whose value is less than 128, contrary
to the definition of MACHINE_EMIN. Suppose MIN is less than F'SAFE_SMALL.
Then MIN lies in the model interval 0 .. F'SAFE_SMALL. MIN/2.0 then lies in
the same interval. In accordance with 4.5.7(10), the quotient can therefore
be any value in the interval, including 0.0, so MIN/2.0 = 0.0 can yield TRUE
or FALSE. If MIN is equal to F'SAFE_SMALL, then MIN/2.0 still falls in the
interval 0 .. F'SAFE_SMALL, and the result of the equality relation still
need not be TRUE.
 !appendix 890617

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

 !section 13.07.03 (09) J. Goodenough 870721 8300935
 !version 1983
 !topic The meaning of floating point machine attributes

 The following messages were sent regarding certain tests in ACVC Version 1.9.

 

 Date: 25 Jun 1987 17:04PDT

 ANALYSIS OF OBJECTION TO ACVC 1.9 TESTS

 TESTS: C45524A..Z (26 tests)

 CODE IN QUESTION: (Simplified sample)

 VAL := 1.0;
 RADIX_INVERSE := 1.0 / F(F'MACHINE_RADIX);
 FOR I IN F'MACHINE_EMIN .. 0 LOOP
 VAL := VAL * RADIX_INVERSE;
 END LOOP;
 IF VAL = 0.0 THEN
 FAILED ("UNDERFLOW OCCURED...");
 END IF;

 OBJECTION: The above code attempts to assign to VAL the value of
 the expression F'Machine_Radix ** (F'Machine_Emin  1), and
 calls FAILED if the calculated value is 0.0. The LRM does
 not require that the abstract value of this expression be
 represented; the subject implementation uses the bit pattern
 corresponding to the value to represent 0.0.

 LRM REFERENCES: 3.5.7/7, 3.5.7/9, 13.7.3

 DISCUSSION:
DRAFT DRAFT DRAFT
An underflowed value need not be equal to 0.0 AI00543/03 3
890620 co WI
 Is it required that, for a floating point type F, the value

 F'Machine_Radix ** ( F'Machine_Emin  1 )

 be representable (distinguishable from zero)?

 The following analysis is based on the implementer's question only to the
 extent that their implementation represents the value 0.0 in the same way
 as the scheme given below.

 Summary:

 Using a "hidden bit" mantissa in order to minimize storage,
 it is reasonable to represent zero using the bit pattern which
 would ordinarily represent the value in question. Moreover,
 this representation scheme meets the requirements of the LRM.

 Discussion:

 Let us attempt to discover a representation scheme which meets
 the LRM requirements for DIGITS 5, but nevertheless results in a
 call to the FAILED procedure in the above code.

 We propose the following 32bit representation scheme:

 Bit 31 : Sign (1 ==> negative, 0 ==> nonnegative)
 Bits 30 .. 8 : Mantissa, suppressing the leftmost bit (which
 is required to be 1)
 Bits 7 .. 0 : (Unsigned) Exponent + 128

 This scheme yields the value 24 (including the suppressed bit) for
 the constant B of LRM 3.5.7, and the value 127 for the constant
 E of the same section.

 According to LRM 3.5.7/7, the model numbers are zero and all numbers
 whose binary mantissa has 24 digits with the leftmost digit equal to
 1 and whose exponent is in the range 96 .. 96.

 LRM 3.5.7/9 then requires that the safe numbers have the same number
 of mantissa digits as the model numbers and that the exponents be in
 the range  E .. E, where E is implementationdefined and at least
 equal to 96. Thus, having taken E as large as possible (127), we
 are required to represent all numbers with 24 digit binary mantissas
 and exponents in the range 127 .. 127. The smallest positive
 number which we are required to represent (F'Safe_Small), then, is

 Sign : 0
 Actual mantissa : 1000 0000 0000 0000 0000 0000
 Stored mantissa : 000 0000 0000 0000 0000 0000
 Actual exponent :  111 1111 (  127 decimal )
 Stored exponent : 0000 0001
 Stored number : 0000 0000 0000 0000 0000 0000 0000 0001
 Decimal value : 0.5 * ( 2.0 ** 127 ) = 2.0 ** (128)
DRAFT DRAFT DRAFT
An underflowed value need not be equal to 0.0 AI00543/03 4
890620 co WI
 We will represent smaller numbers than F'Safe_Small using the same
 scheme; our smallest representable positive number is

 Sign : 0
 Actual mantissa : 1000 0000 0000 0000 0000 0001
 Stored mantissa : 000 0000 0000 0000 0000 0001
 Actual exponent : 1000 0000 ( 128 decimal )
 Stored exponent : 0000 0000
 Decimal value : (2.0 ** 129) + (2.0 ** 152)

 The smallest actual exponent used in the machine representation is
 128; thus F'Machine_Emin = 128. The number whose representation
 was originally questioned, then, is 2.0 ** (129), which we do not
 represent.

 A question remains: How are we to represent 0.0?

 The only bit pattern remaining to us is (32 .. 0 => 0), which,
 interpreted according to the scheme for positive numbers, would
 represent the value 2.0 ** (129). We choose this representation
 for 0.0, and note in passing that machine tests for a zero word will
 recognize this representation as zero.

 We would then expect that execution of the questioned code would
 result in a call to the FAILED procedure, since it is equivalent to
 the assignment

 VAL := F'(0.5) * F'(0.5) * F'(2.0 ** (127));

 which is abstractly equivalent to VAL := 2.0 ** (129);

 RECOMMENDATION:

 Declare these tests inapplicable to any implementation whose
 representation scheme can be shown to yield results similar to the
 above. The burden would have to be on the implementer, and the
 decision would have to be made on a casebycase basis. Most
 implementations should pass this test; for example, DEC uses
 essentially the same representation scheme as above, but recognizes
 any floating point value with exponent 128 as 0.0, no matter what
 the mantissa. Thus, their value of F'Machine_Emin is 127; the
 value in question is 2 ** ( 128 ), which is represented with
 mantissa 0.5 (stored as 23 binary zeroes) and exponent 127.

 QUESTION FOR INTERPRETATION (re above dispute):

 The test in question depends heavily upon the description of the
 attribute 'MACHINE_EMIN as given in LRM 13.7.3/9: "Yields the
 smallest (most negative) value of exponent for the machine
 representation of the base type of T."

 This is preceded in LRM 13.7.3/5 by the following: "For floating
 point types, the following attributes provide characteristics of
DRAFT DRAFT DRAFT
An underflowed value need not be equal to 0.0 AI00543/03 5
890620 co WI
 the underlying machine representation, in terms of the canonical
 form defined in section 3.5.7:"

 We interpret this to mean that in trying to determine the correct
 value of 'MACHINE_EMIN, we consider only those values of exponent
 used with normalized mantissas; that is, mantissas in which the
 first digit is not zero.

 However, the following arises:
 For illustrative purposes, suppose we use a 6bit mantissa, with
 all 6 bits stored, and an 8bit exponent, storing the actual
 exponent + 128. The smallest positive number which is actually
 stored in the canonical form would have mantissa 10 0000 and
 exponent 128 (stored as 0000 0000). Under the above interpret
 ation, the value of 'MACHINE_EMIN would be 128. However, this
 representation allows us to store positive numbers as small as
 2.0 ** 134 (stored as mantissa 00 0001, exponent 0000 0000).
 The abstract binary canonical form for this number is mantissa 0.1,
 exponent 133. Do we ignore this exponent value when determining
 the value of 'MACHINE_EMIN (as we have done above), or do we use
 133 as the value, since the canonical form is distinct from the
 actual machine representation?

 

 Date: Fri, 26 Jun 87 17:01:18 edt
 From: Goodenough@sei.cmu.edu

 C45524A..Z (underflow and MACHINE_EMIN definition)

 The test assumes that .5 * 2**F'MACHINE_EMIN is a representable, nonzero
 value when MACHINE_RADIX is 2.0, i.e., that this is the smallest positive
 value. In the implementation's representation, this assumption is shown to
 be untrue. Because of the canonical form requirements, the Standard actually
 requires only that the smallest positive value satisfy:

 .5 * 2**F'MACHINE_EMIN <= smallest < .5 * 2**(F'MACHINE_EMIN+1)

 Since the test is based on an assumption that is incorrect for this
 implementation, I agree with the recommendation. The test can later be
 modified to check for MACHINE_EMIN in a way that does not make an assumption
 that .5 * 2**F'MACHINE_EMIN is representable.

 With respect to the added "question for interpretation", the value of
 MACHINE_EMIN is not given by the actual machine representation, but rather,
 by the canonical representation of the machine's smallest positive value. In
 the example given in the original dispute, EMIN is 128 because the canonical
 representation of the smallest positive value is

 2#0.10000...0001#e128

 In the example given in the postscript, the smallest positive number in
 canonical representation is
DRAFT DRAFT DRAFT
An underflowed value need not be equal to 0.0 AI00543/03 6
890620 co WI
 2#0.10_0000#e133

 so EMIN is 133. (The discussion of the original dispute confuses the issue
 by saying "The smallest actual exponent used in the machine representation is
 128; thus F'Machine_Emin = 128." This is actually a nonsequiter, because
 it is the exponent value in the CANONICAL representation that is relevant,
 and it happens that this exponent value is also 128; the machine
 representation is only relevant in that it defines the value that is to be
 represented canonically.)

 

 Date: Fri, 26 Jun 87 14:20:24 PDT
 From: hilfingr%tully.Berkeley.EDU@Berkeley.EDU (Paul Hilfinger)

 C45524A..Z:

 I don't understand the point of all this analysis. Implementation details
 like hidden bits have nothing to do with questions of semantics. The
 question is, how are we to interpret MACHINE_EMIN, etc.? I believe the
 Standard strongly implies that the MACHINE_ attibutes define a set of "real"
 model numbers analogous to the official Ada model numbers. Under this
 interpretation, 2#0.1#m_emin is a "real" model number and must be returned
 exactly.

 One could argue that the rules of Ada say that, as long as F'MACHINE_EMIN
 is less than F'EMAX, the end value of VAL is allowed to be 0.0. However,
 this renders MACHINE_EMIN, SAFE_EMAX, etc. without any meaning whatever.
 Since, as I have argued elsewhere, these attributes (esp., the MACHINE_
 attributes) are far more useful and important than 'EMAX, etc., we should
 not set a precedent of being unnecessarily loose about their interpretation.

 As for dealing with denormalized representations: the current MACHINE_
 attributes clearly do not give enough degrees of freedom to describe
 such characteristics. I suggest, therefore, that we stick with the notion
 of MACHINE_ attributes as having similar interpretations to the "standard"
 attributes, and leave additional attributes to later versions of the
 language.

 Paul

 

 Date: Fri, 26 Jun 87 16:51:40 PDT
 From: hilfingr%tully.Berkeley.EDU@Berkeley.EDU (Paul Hilfinger)

 The discrepency between JBG's response and mine is traceable to the
 following question of interpretation: I had assumed that the MACHINE
 attributes are to be considered as defining a set of model numbers, which
 comprise, for each exponent value n, ALL numbers of the form
 2#0.1ddddddd#en (total of F'MACHINE_MANTISSA digits after the point) for
 a MACHINE_RADIX of 2 (Motivation: just like the rules for regular model
 numbers, and also allows certain numerical guarantees, as indicated
DRAFT DRAFT DRAFT
An underflowed value need not be equal to 0.0 AI00543/03 7
890620 co WI
 below). There might, in addition, be denormalized numbers
 smaller than these, but this is an added degree of freedom not provided for
 in the Standard.

 John's interpretation is also reasonable (i.e., MACHINE_EMIN gives the
 smallest exponent of a nonzero floatingpoint number in canonical
 form). The problem is that because the Standard does not provide enough
 parameters to twiddle, one of two properties must be sacrificed. With
 John's interpretation, you cannot assume that a result whose canonicalform
 exponent is in range always has MACHINE_MANTISSA bits of accuracy. With
 mine, you cannot assume that a result whose canonicalform exponent is
 OUT of range is UNrepresentable. Which of these to accept is a good question.
 I suppose, on reflection, that I can't really hold it against the implementor
 that he took another interpretation (the reasoning given for doing so, however,
 still doesn't cut the mustard with me.)

 Paul

 

 From: Clausen@MITMultics.ARPA
 Subject: FRN 870625B

 C45524A..Z (26 tests)

 My feeling is that the discussion given in the dispute is somewhat besides the
 point. In my opinion the question is whether the accuracy rules given in ARM
 4.5.7 allow the computation of 0.0 for VAL.

 Assume, the following definitions:

 2 = F'machine_radix
 e = F'emax
 s = F'safe_emax
 m = F'machine_emin

 and assume that m < s <= e holds true.

 When considering the loop in question we find the invariant 2**(k) for the
 values assigned to VAL where k covers the range 1..m1. For all k such that
 k<=s, the values are safe numbers and should be represented exactly. However,
 as i approaches 0 there will be a multiplication

 2**(1)*2**(s1) = 2**(s2)

 whose result is not a safe number. Looking for a safe interval (ARM 4.5.7(4)
 and 4.5.7(8)) we find

 0.0 <= 2**(s2) <= 2**(s1)

 My interpretation of the manual is that any end_point of this interval is a
 correct result. Hence, assigment of 0.0 to VAL is correct by the rules of the
 ARM.
DRAFT DRAFT DRAFT
An underflowed value need not be equal to 0.0 AI00543/03 8
890620 co WI
 I conclude that the test is incorrect and should be withdrawn altogether. The
 value returned for machine_emin is quite irrelevant as long as it is smaller
 than s.

 Concerning the question for interpretation, I have the feeling that the actual
 machine characteristics should be reutrned for machine_emin and machine_radix.
 Thus, I would like to seE 128 as value for machine_emin in both cases.
 However, ARM 13.7.3 is sufficiently confusing to allow other interpretations.
 Note that these may be a machine which represents number in a very different
 system so that the terms "radix" and "machine_emin" are not applicable. My
 conclusion is that the LMP should be asked for an interpretation.

 Stephan

 

 Date: Wed, 1 Jul 87 15:12:21 PDT
 From: hilfingr%tully.Berkeley.EDU@Berkeley.EDU (Paul Hilfinger)

 I must disagree that an implementation is free to provide an arbitrary value
 for machine_emin that is less than 'safe_emax and then ignore it for purposes
 of determining underflow to 0. This would make 'machine_emin essentially
 meaningless.

 I will repeat what I've said before (it may be, as JDI says, "intellectual
 terrorism," but is nevertheless true): for general purpose use, it is the
 'MACHINE_.... attributes that are important for portability, not the 'SAFE...
 or the standard model number attributes. We must not undermine their
 usefulness with our decisions.

 Paul

 

 Date: 20 Jul 1987 10:26PDT
 From: DLEHMAN@ADA20.ISI.EDU

 John, et al.:

 Is this issue something that the LMC/P can discuss? The FRT appears to
 be fairly divided on this; the implementer is not in the process of valida
 tion.

 Forwarded is Brian's response.

 Dan

 Date: 20 Jul 1987 09:37:20 PDT
 From: BWICHMANN@ADA20.ISI.EDU

 Tests C45524A..Z

 I have at last looked at the example in depth. I agree with Stephan that the
DRAFT DRAFT DRAFT
An underflowed value need not be equal to 0.0 AI00543/03 9
890620 co WI
 test has to be withdrawn because the test for equality with zero cannot be
 derived from the ARM since machine attributes are used. However, the complete
 set of attributes for the type in question is not given, and hence I cannot be
 sure. Certainly the test makes unwarranted assumptions and should be
 withdrawn. The proper solution to these problems is to calculate the safe
 intervals for all the ACVC tests. The Numerical Algorithms Group at Oxford
 have the necessary software, but it would need conversion to Ada to be useful
 for this.

 Brian.


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

 !section 13.07.03 (09) J. Goodenough 890617
 !version 1983
 !topic Version /02 returned to the ARG

 The ARG was requested to correct the expression in the question and
 make clearer what issue is being addressed and why the formulas in
 the commentary are correct.

DRAFT DRAFT DRAFT