!standard A.05.03(26) 04-04-20 AI95-00379/00

!standard A.05.03(29)

!standard A.05.03(47)

!class binding interpretation 04-04-20

!status work item 04-04-20

!status received 04-04-05

!priority Low

!difficulty Medium

!subject Static evaluation of numeric attributes

!standard A.05.03(29)

!standard A.05.03(47)

!class binding interpretation 04-04-20

!status work item 04-04-20

!status received 04-04-05

!priority Low

!difficulty Medium

!subject Static evaluation of numeric attributes

!summary

!question

The wording of Remainder specifies that the result is zero if the result is not
a machine number. That seems very strange. It might make sense if the operands
are assumed to be machine numbers, but if they are not (as in static
evaluation), this could lead to nonsense results.

The definition of Scaling and Compose require the result to be a machine
number. Is this intended even for static evaluation?

!wording

Change A.5.3(47) by approximately
"If the result R is a machine number, the result is R; if R satisfies
T'Pred(0.0) < R < T'Succ (0.0), then the result is 0.0; otherwise, the result
is one of the machine numbers adjacent to R."

Dunno what to change A.5.3(26) and A.5.3(29) to (if anything).

!discussion

The requirement for Compose and Scaling to return a machine number means that
an implementation has to discard any extra precision in the calculation. On a
machine like the Intel processors, where operations are done in extra
precision, and instructions exist to implement these attributes, that's a
significant extra expense.

--!corrigendum

!example

!ACATS test

!appendix

!topic Unexpected semantics of 'Floor, 'Ceiling and other static attributes !reference RM95-A.5.3(30-35) !from Gary Dismukes 2004-04-05 !discussion [Note: This comment is submitted on behalf of Geert Bosch of Ada Core Technologies. This issue is outside my area of expertise and I have only made minor editorial changes to the write-up from Geert. -- Gary] The following program raises constraint error: procedure t is X : constant Float := Float'Floor (2.0**32 - 0.5); begin if X >= 2.0**32 then raise Constraint_Error; end if; end t; The reason is that the Float'Floor attribute returns the largest integer smaller than or equal to its argument even if that number is not a machine number. When leaving the static context, the value gets rounded to the nearest machine number, which rounds up in this case. Even though this is consistent with a literal reading of the RM, this seems unintended and is unexpected. It seems more useful to define these attributes as follows: 30. S'Floor S'Floor denotes a function with the following specification: 31. function S'Floor (X : T) return T 32. The function yields the value Floor(X), i.e., the largest (most positive) integral value less than or equal to X. When >>> ^^^^^machine number X is zero, the result has the sign of X; a zero result otherwise has a positive sign. 33. S'Ceiling S'Ceiling denotes a function with the following specification: 34. function S'Ceiling (X : T) return T 35. The function yields the value Ceiling(X), i.e., the smallest (most negative) integral value greater than or equal to X. >>> ^^^^^ machine number When X is zero, the result has the sign of X; a zero result otherwise has a negative sign when S'Signed_Zeros is True. (That is, replace "integral value" with "integral machine number".) Rounding and Unbiased_Rounding need similar replacements of value by machine number. **************************************************************** From: Adam Beneschan Sent: Monday, April 5, 2004 3:15 PM I disagree, at least with respect to Floor and Ceiling. The definition of "Floor" given in the RM is the mathematical definition. If I were to say Y := Floor(X), I would assume that after this statement, 0.0 <= X-Y < 1.0 regardless of the value of X beforehand. But, assuming "Float" is a 32-bit float with a 23-bit mantissa (which really ought to be stated in a post like this---we can't assume that every Float in every Ada compiler is implemented this way), the proposed definition would, for X = 2.0**32, yield a value of Y = Floor(X) where X-Y = 256. This, to me, would be unexpected semantics. If it's *useful* to return the largest integral machine number smaller than or equal to the argument, then let's propose a new attribute for that purpose. But it seems wrong to change the definition of a well-known mathematical term. **************************************************************** From: Tucker Taft Sent: Monday, April 5, 2004 3:36 PM The suggestion to replace "integral value" with "integral machine number" makes sense to me. **************************************************************** From: Randy Brukardt Sent: Monday, April 5, 2004 4:18 PM I agree with Adam, this seems like a horrible idea. A common use of these attributes is to use them immediately before a conversion to some integer type: procedure t is X : constant Integer := Integer(Float'Floor (2.0**31 - 0.5)); begin if X /= 2.0**31-1 then raise Program_Error; end if; end t; I think virtually everyone would find it goofy if the above program raised Program_Error. Yet, the proposed wording change would require X to be 2**31-128 on IEEE machines. The case that causes concern can only happen for a static expression (if the argument had already been a machine number, the answer also would have to be a machine number), and as the above shows, the change is likely to produce nonsense as it is to fix something. And it's clearly incompatible (it's changing the answer of something in use for years). So I don't think the change meets the "smell" test. **************************************************************** From: Nick Roberts Sent: Monday, April 5, 2004 6:58 PM > (That is, replace "integral value" with "integral machine number".) I don't think the proposed wording is acceptable, as such, because (if followed pedantically) it would produce silly results. For example, Float'Floor(5.1) could produce the result 4.0000... if 5.0000... happened not to be a machine number. I'm sure that this is not the intended effect of the proposed wording (and would not be acceptable to anyone). I suggest the required wording for Floor is to change "integral value less than or equal to X" to "integral value less than or equal to X whose nearest machine number is not greater than X." Similarly, for Ceiling, change "integral value greater than or equal to X" to "integral value greater than or equal to X whose nearest machine number is not less than X." > Rounding and Unbiased_Rounding need similar replacements of value by > machine number. For the Rounding function, the existing wording is: S'Rounding denotes a function with the following specification: function S'Rounding (X : T) return T The function yields the integral value nearest to X, rounding away from zero if X lies exactly halfway between two integers. A zero result has the sign of X when S'Signed_Zeros is True. This could be changed to: The function yields the machine number nearest to the integer nearest to X, preferring the result further from zero if X lies exactly halfway between two integers. A zero result has the sign of X when S'Signed_Zeros is True. S'Unbiased_Rounding denotes a function with the following specification: function S'Unbiased_Rounding (X : T) return T The function yields the integral value nearest to X, rounding toward the even integer if X lies exactly halfway between two integers. A zero result has the sign of X when S'Signed_Zeros is True. This could be changed to: The function yields the machine number nearest to the integer nearest to X, preferring the result nearer the even integer of the two integers nearest X if X lies exactly halfway between two integers. A zero result has the sign of X when S'Signed_Zeros is True. I support these changes, with the proviso that a minimal survey is first conducted to confirm that it is unlikely that existing (important, operational) software will not be adversely affected. I can confirm that none of the software I am responsible for (which isn't much) would be. **************************************************************** From: Randy Brukardt Sent: Monday, April 5, 2004 8:08 PM > > Rounding and Unbiased_Rounding need similar replacements of value by > > machine number. I hadn't noticed this before. I would be very opposed to any such change to Unbiased_Rounding. That's because that attribute is often used directly in Integer type conversions. On the Intel processors, we optimize these down to just the store instruction (rounding comes for free in that instruction). If the expression is at all complex, it will have been evaluated in the 80-bit precision of the Intel floating point registers. In order to implement any machine number wording, we'd have to truncate the expression value to a machine number. That is an expensive operation, as the implementation usually involves writing the value to memory and then reading it back. So adding such a requirement would not only change the answers in significant ways, but it also would cost quite a bit in performance. Rounding is pretty common! **************************************************************** From: Pascal Leroy Sent: Tuesday, April 6, 2004 4:26 AM > The reason is that the Float'Floor attribute returns the > largest integer smaller than or equal to its argument even if > that number is not a machine number. When leaving the static > context, the value gets rounded to the nearest machine > number, which rounds up in this case. The analysis is confused here. The issue has nothing to do with "leaving the static context", because all the expressions involved are static. The issue comes from the "tweaking" of floating-point values required by 4.9(38). In other words the result of Float'Floor is 2.0**32-1.0, but the value of X is 2.0**32 because that's presumably the machine number closer to 2.0**32-1.0. > (That is, replace "integral value" with "integral machine number".) > > Rounding and Unbiased_Rounding need similar replacements of > value by machine number. I am going to strenuously oppose this change. For one, it's grossly incompatible: it would silently change the semantics of existing code, in ways that may only be detected the hard way under the debugger. But more importantly it's completely misguided: one very important use of the attributes of A.5.3 is for static computations. For such computations, we want to stick to the mathematical definition as much as possible. After all, exact evaluation of static expressions is one of the great features of Ada. Introducing dependencies on machine numbers here is not only killing all hopes of portability, it also makes it impossible to reason about static expressions, as Adam and Randy have pointed out. Furthermore, it leads to definitional problems; for instance, what is the value of: Float'Ceiling (10.0*10000) - 10.0*10000 I hope it is 0.0, but I can't deduce that from the proposed wording because there is no machine number above 10.0*10000 (assuming a reasonably-size Float). As much as possible, we want to avoid any dependency on the set of machine numbers in A.5.3. In fact, I have always assumed that the references to machine numbers in A.5.3 do not really apply to static computations, and I notice that GNAT has the same view; witness the fact that the following declarations compile with both GNAT and Apex: X : constant := Float'Compose (1.0, -1000); Y : constant := 1 / Boolean'Pos (X = 2.0 ** (-1001)); A strict reading of A.5.3(26) would lead to the conclusion that, because 2.0 ** (-1001) is not a machine number of Float, X should be 0.0 or the machine number immediately above 0.0. However, that interpretation would be actively harmful as it would lose the accuracy of static computations for no benefit at all. **************************************************************** From: Tucker Taft Sent: Tuesday, April 6, 2004 8:01 AM Pascal's discussion convinces me we should not change the definition of this attribute. **************************************************************** From: Nick Roberts Sent: Tuesday, April 6, 2004 9:17 AM It doesn't convince me. I'm not certain that the issue is important for Rounding and Unbiased_Rounding, but I would prefer the definitions I proposed (after Geert and Gary) for Floor and Ceiling, because they would correspond to the semantics that I would require in real working software (as opposed to the artificial examples given by Randy and Pascal). Presumably Geert's customer will write their own, probably non-portable, versions of Floor and Ceiling in order to get the semantics they need. That's hardly a victory for the language standard, is it? **************************************************************** From: Randy Brukardt Sent: Tuesday, April 6, 2004 2:41 PM Why would they need a non-portable version? The attributes of A.5.3 and the 'Machine attribute provide all of the support needed to write Floor and Ceiling. (The only reason that they're built-in is that some hardware supports such operations, and the attributes provide a way to use those operations.) Indeed, Janus/Ada implements Floor and Ceiling in software, using A.5.3 attributes. **************************************************************** From: Geert Bosch Sent: Tuesday, April 6, 2004 4:22 PM Hi everyone, I just joined this list after Gary submitted my comment earlier today. I'd like to clarify a few points. > I disagree, at least with respect to Floor and Ceiling. The > definition of "Floor" given in the RM is the mathematical definition. > If I were to say Y := Floor(X), I would assume that after this > statement, > > 0.0 <= X-Y < 1.0 > > regardless of the value of X beforehand. But, assuming "Float" is a > 32-bit float with a 23-bit mantissa (which really ought to be stated > in a post like this---we can't assume that every Float in every Ada > compiler is implemented this way), the proposed definition would, for > X = 2.0**32, yield a value of Y = Floor(X) where X-Y = 256. This, to > me, would be unexpected semantics. I'd like to point out, that (assuming a 32-bit float type T with T'Machine_Radix = 2 and T'Machine_Mantissa = 24) if X = 2.0**32, this is an integral machine number, so T'Floor (X) = T'Ceiling (X) = X, and X - T'Floor (X) = 0.0. Finally, in a statement Y := T'Floor (X); the value in Y is necessarily a machine number and that may cause the equality 0.0 <= X - T'Floor (X) < 1.0 to be false. Currently, the following case X : constant := 2.0**32 - 0.5; Y : T := T'Floor (X); will cause Y to be negative: neither of the conditions you gave are guaranteed to hold for all values of X. With my proposed change, at least X - T'Floor (X) will be guaranteed not to be negative. This is in my opinion an important property. Finally, the 'Floor attribute is stated to return a value of type T, not a universal_real value, so I feel the current language in the RM isn't very clear on the intended behavior. **************************************************************** From: Randy Brukardt Sent: Tuesday, April 6, 2004 4:50 PM Geert Bosch wrote: ... > I'd like to point out, that (assuming a 32-bit float type T with > T'Machine_Radix = 2 and T'Machine_Mantissa = 24) if X = 2.0**32, > this is an integral machine number, so T'Floor (X) = T'Ceiling (X) = X, > and X - T'Floor (X) = 0.0. I'm sure Adam meant your example of X := 2.0**32-0.5. > Finally, the 'Floor attribute is stated to return a value of type T, > not a universal_real value, so I feel the current language in the RM > isn't very clear on the intended behavior. So is the result of "*", and the language is just as clear about that: -- Static expressions are evaluated exactly; -- Extra precision is allowed in intermediate results. Thus the result type has nothing to do with the result other than for resolution purposes. As Pascal pointed out, the problem you're worrying about comes from the conversion to a machine number, and that isn't part of the attribute (or any of the others) at all. I don't care much about Floor (it's pretty useless), but I'm sure that we can't make silent incompatibilities because someone has some code that expects behavior not guaranteed by the standard. It would be better to delete the attributes altogether (but that of course would be an even worse incompatibility). And, then you have to wonder why these attributes are special. It's crystal clear that you don't want any machine number baloney going on in the rounding attributes; but Floor and Ceiling are just (funny) rounding attributes. Why should they be different? **************************************************************** From: Adam Beneschan Sent: Tuesday, April 6, 2004 6:11 PM > I'm sure Adam meant your example of X := 2.0**32-0.5. Yes, indeed that's what I meant. Sorry about the mistake, which appears to be an effect of Caffeine Deficiency Syndrome . . . **************************************************************** From: Tucker Taft Sent: Tuesday, April 6, 2004 5:19 PM > ... > Finally, the 'Floor attribute is stated to return a value of type T, > not a universal_real value, so I feel the current language in the RM > isn't very clear on the intended behavior. Referring to a value of type T does not imply a machine number. Static arithmetic is infinite precision even for non-univeral- real floating point types. In fact, universality has relatively little to do with precision in Ada 95. Staticness is what matters. After reading Pascal's argument, I really don't see how we can change the definition of these attributes. We could add a note to warn users that they are essentially useless for non-static calculation when the values are so large that the integral values are not machine numbers. I'm not sure what the original example was trying to prove, but if the goal was to find the largest integral machine number less than 2**32, I would suggest you use 'Pred. **************************************************************** From: Adam Beneschan Sent: Tuesday, April 6, 2004 6:06 PM That would certainly work in the original example. The way Geert wanted to redefine 'Floor was as "the largest integral machine number less than or equal to X". My first reaction to this was that perhaps this was, for some reason, a useful function, one whose value would be 'Pred if the number was so large that 'Floor couldn't be represented as a machine number, but would be 'Floor for numbers with smaller exponents in the range where the delta between consecutive machine numbers would be <= 0.5. I suggested that if this really was useful, a new attribute could be proposed. But it's now occurred to me that this isn't necessary. I believe that "the largest integral machine number less than or equal to X" can always be obtained via: Float'Min (Float'Floor (X), Float'Pred (X)) I haven't yet tried to prove it formally, but I believe that for an IEEE representation, Float'Pred(X) must always be an integer if Float'Pred(X) < Float'Floor(X), and that should be true of any other real-life floating-point representation. Thus the above formula will return the value in the above proposal. **************************************************************** From: Geert Bosch Sent: Tuesday, April 6, 2004 6:13 PM If X itself is an integral machine number, this is not correct. Thanks anyway for the help. I've solved the problem (which was related to range-checking in float-to-integer conversion) directly in the front-end by using extra tests and adjustments. **************************************************************** From: Geert Bosch Sent: Tuesday, April 6, 2004 6:09 PM > After reading Pascal's argument, I really don't see how > we can change the definition of these attributes. We could > add a note to warn users that they are essentially useless > for non-static calculation when the values are so large that > the integral values are not machine numbers. OK. I think we can do without the note, it may only cause more confusion. The original problem came up in computing bounds for range/overflow checking in float-to-integer conversion. Thanks for everyone's help and views. **************************************************************** From: Nick Roberts Sent: Tuesday, April 6, 2004 6:10 PM > I'm not sure what the original example was trying to prove, > but if the goal was to find the largest integral machine number > less than 2**32, I would suggest you use 'Pred. But I feel that's a bit like saying to users: here's a function that computes the Floor/Ceiling of a floating point expression; but don't use it, because it doesn't work properly (under certain conditions), you should define your own function in terms of Pred/Succ instead. Why not just fix the standard functions to work properly? **************************************************************** From: Pascal Leroy Sent: Wednesday, April 7, 2004 3:38 AM Nick, by your definition of "properly", no (nonstatic) floating-point computation works properly. I don't see why you are focusing on Floor here. Take plain old arithmetic. For some values of X, it is perfectly possible for: X - 1.0E9 >= X to return True (just make X big enough). Anyone believing that (nonstatic) floating-point computations have any ressemblance to mathematical computations is seriously confused, and should urgenly re-read Knuth's chapter 4.2.2. Again, the great thing about static computations is that they match their mathematical counterparts, and this makes it much easier to reason about them. **************************************************************** From: Nick Roberts Sent: Thursday, April 8, 2004 10:46 AM By 'properly' what I mean is 'usefully'. Plain old (non-static) arithmetic does not work properly (it is inaccurate), but it is still useful. I believe that the semantics that will be useful for almost all real, working software, for Floor and Ceiling, will be what Geert wanted, not what is currently defined. Whether it is mathematically correct is not what is required for these functions, in practice, it is what Geert required. Specifically, I believe the most important property for Floor/Ceiling is that it never returns a value greater/less than its operand under any circumstances. That is why I think the language standard definition of the functions should be changed. In order to supply the mathematically correct functions, we need to introduce something like Universal_Real'Floor and so on. There also seems (to me) to be implications for Truncation, and a separate question regarding Remainder seems to have been raised. This is a complicated issue, and I'm still analysing it (while doing my day job). **************************************************************** From: Geert Bosch Sent: Tuesday, April 6, 2004 5:54 PM > In fact, I have always assumed that the > references to machine numbers in A.5.3 do not really apply to static > computations, I do not see any grounds to assume that references to machine numbers in A.5.3 do not apply to static computations. At least the 'Succ, 'Pred, 'Adjacent, 'Remainder and 'Machine attributes would not be meaningful without this. The main use of floating-point attributes in static expressions is to be able to determine how arbitrary precision constants or constant expressions will be rounded to machine numbers by the implementation. This way, it is possible to adjust for rounding errors that result from the finite precision of machine numbers. **************************************************************** From: Pascal Leroy Sent: Wednesday, April 7, 2004 3:31 AM > I do not see any grounds to assume that references to machine numbers > in A.5.3 do not apply to static computations. At least the 'Succ, > 'Pred, 'Adjacent, 'Remainder and 'Machine attributes would not be > meaningful without this. You're absolutely right regarding Succ, Pred, Adjacent and Machine. Their sole purpose in life is to expose the properties of the underlying machine numbers, so of course references to machine numbers in the RM text is appropriate here. I should have been more precise and I should have mentioned the exact paragraphs that I believe are faulty. Take for instance Remainder. It's meaning is perfectly well-defined mathematically, independently of machine numbers, so any reference to machine numbers in A.5.3(47) is bogus. Consider the (static) expression: Float'Remainder (Pi, E) and assume that Pi and E are static values with a fairly large number of digits (say 50, as shown in A.5(3)). With the notation of A.5.3(47), n is 1 here, and v is Pi-E. Surely v is not a machine number of Float (it's somewhere between two machine numbers) so the result of this attribute is +0.0 by a strict reading of A.5.3(47). Now that's a clear absurdity and every reasonable compiler will return Pi-E here. **************************************************************** From: Tucker Taft Sent: Thursday, April 8, 2004 8:43 AM I had never noticed this, but it seems that the definition of Float'Remainder must simply be wrong. All of the other attributes talk about returning an "adjacent" machine number. But this one says zero if the result is not a machine number. That doesn't make any sense to me. Maybe it makes sense to someone else... As far as machine numbers applying to static calculations, I believe the specification of machine numbers was intentional for Compose and Scaling (and our compiler definitely applies 'Machine to the result, even if static). I am completely confused as to why Remainder is defined the way it is. All I can think was that someone concluded that if the result were not a machine number, then one of the adjacent machine numbers would be zero, and so we might as well specify that that is the one always chosen. But your Remainder(Pi,e) example clearly disproves that. Perhaps it should have said that 'Machine is applied to the two operands *before* computing the Remainder. In that case, I guess I can believe the result will always be a machine number unless you get underflow, in which case zero seems like a reasonable answer. Perhaps someone else can shed more light... **************************************************************** From: Robert A. Duff Sent: Thursday, April 8, 2004 8:54 AM I suggest you ask Ken Dritz. **************************************************************** From: Pascal Leroy Sent: Thursday, April 8, 2004 10:13 AM This entire section was written by someone who missed the implications of static computations. In other words, it was written exclusively with run-time computations in mind. As explained in IEC 559, the run-time version of remainder is always exact. There is one caveat, though: if Y is very close to 0.0 (for instance if Y is the machine number immediately above 0.0) then the result may not be representable (because it is always less than Y/2.0). In this case, returning 0.0 makes sense; however, it smells of overspecification because I can't find a similar rule in IEC 559. But clearly, for static computations, the sentence about machine numbers is absurd... > Perhaps it should have said that 'Machine is applied to the > two operands *before* computing the Remainder. In that > case, I guess I can believe the result will always be > a machine number unless you get underflow, in which > case zero seems like a reasonable answer. No, if you want to apply Machine automatically, you can always do that yourselves explicitly. If the current wording really gives you the willies, we could fix it, but let's not change the semantics. All this verbiage about machine numbers in Remainder, Scaling and the like is actually completely unnecessary: we don't have anything equivalent for the basic arithmetic operations "+", "*", etc. All we say is that they have their usual mathematical meaning, and that (in strict mode) you get a value in the proper interval. In the case of the attribute we have to specify their "mathematical meaning", because it's not obvious, but other than that we should let the strict mode do its job. It is actually worse that you think because, unlike all the rest of the language, it doesn't let you keep more accuracy. If you are on a Pentium and your type Float corresponds to the 32-bit format, the result of Scaling has to be a machine number of Float. So if you did the intermediate computations using the 80-bit format (quite likely on this architecture ;-), you have to explicitly emit a load/store pair to get rid of the extra accuracy. Yuck! **************************************************************** From: Tucker Taft Sent: Thursday, April 8, 2004 10:39 AM > This entire section was written by someone who missed the implications > of static computations. In other words, it was written exclusively with > run-time computations in mind. I believe Ken Dritz of Argonne National Lab wrote much of this. He is no fool. I suspect he wanted the results to be in terms of machine numbers for Compose, Scaling, and Remainder. We of course may disagree. However, I wouldn't be surprised if various compilers implement the attributes as written (I know we do). For Remainder, they are definitely getting bizarre answers if they don't first apply 'Machine to the operands (we don't). I think we need to fix the wording for Remainder, one way or the other. For Scaling and Compose, I have no problem leaving them the way they are as returning machine numbers. I think that is better than silently changing the behavior. Also, these seem to be oriented toward manipulating machine representations more than abstract real values. On the other hand, Remainder is clearly broken the way it is currently written, and perhaps we can make our own decision which way makes more sense. I could go either way, though I probably have a slight preference for specifying that 'Machine is applied before using the given algorithm, but you could convince me the opposite. > ... > But clearly, for static computations, the sentence about machine numbers > is absurd... Unless 'Machine is applied to the operands. > > >>Perhaps it should have said that 'Machine is applied to the >>two operands *before* computing the Remainder. In that >>case, I guess I can believe the result will always be >>a machine number unless you get underflow, in which >>case zero seems like a reasonable answer. > > > No, if you want to apply Machine automatically, you can always do that > yourselves explicitly. If the current wording really gives you the > willies, we could fix it, but let's not change the semantics. But what exactly *are* the semantics? For this one, I am not sure. The notion of a Remainder that is sometimes positive and sometimes negative depending not on the sign of the operands, but rather their values, is a bit bizarre to me, and I really don't know what this is used for. Is it for argument reduction? > All this verbiage about machine numbers in Remainder, Scaling and the > like is actually completely unnecessary: we don't have anything > equivalent for the basic arithmetic operations "+", "*", etc... That's true, but these are not basic arithmetic operations. At least scaling and compose are pretty low level manipulations that seem pretty oriented toward representation. Remainder I will admit sounds more "mathematical" and as I indicated, I could be convinced that any reference to machine numbers should be removed. > It is actually worse that you think because, unlike all the rest of the > language, it doesn't let you keep more accuracy... I believe that was intentional. You can argue (and you have ;-) that that was a mistake. Whether it should be changed now is a debate in my mind. We argued for not changing what the manual said about Floor for compatibility reasons. The same could certainly be said about Scaling and Compose. I am at a loss as to say what to do with Remainder. If we use the "RM never says anything silly" rule, then the only reasonable interpretation of Remainder is either that 'Machine is applied to the operands, or something like "if the result cannot be represented exactly, the result is zero." In any case, I think it is a bit of a stretch to allow additional accuracy in the run-time results of Scaling and Compose, based on the well-defined wording already present in the manual. **************************************************************** From: Tucker Taft Sent: Thursday, April 8, 2004 10:44 AM One last comment. Scaling and Compose are designed to be performed by directly manipulating the IEEE representation, rather than doing multiplication or division. For Scaling, you just adjust the exponent and leave the mantissa as is. For Compose you shove the exponent and the mantissa into the appropriate parts of the 32-bit or 64-bit representation. So I don't think the 80-bit intermediate form is really an issue. **************************************************************** From: Pascal Leroy Sent: Thursday, April 8, 2004 11:15 AM It is when it comes to underflows/overflows. I have always thought that these attributes should be implemented as efficiently as possible, using one or a few machine instructions. Now you want me to do an extra conversion/check to detect underflow/overflow. Sorry, that doesn't sound like a good idea to me. **************************************************************** From: Geert Bosch Sent: Thursday, April 8, 2004 11:44 AM In order to implement these attributes efficiently, you need to work on the in-memory representation anyway (which will have caused rounding to the type's precision). I don't see where the inefficiency is. **************************************************************** From: Michael F. Yoder Sent: Thursday, April 8, 2004 3:01 AM >As explained in IEC 559, the run-time version of remainder is always >exact. There is one caveat, though: if Y is very close to 0.0 (for >instance if Y is the machine number immediately above 0.0) then the >result may not be representable (because it is always less than Y/2.0). >In this case, returning 0.0 makes sense; however, it smells of >overspecification because I can't find a similar rule in IEC 559. > If the representation incorporates gradual underflow, as the 'single' and 'double' IEEE reps do, then the remainder of two machine numbers is always representable as a machine number. If Y is the machine number immediately above 0.0, the remainder is always exactly 0.0 when X is a machine number. The case cited only obtains if the floating point representation doesn't use gradual underflow. In that case, converting underflowed results to 0.0 is easier in hardware than other methods. (I don't recall whether there are machines that do anything different.) I'd be willing to bet lots of money at even odds that this is the origin of the rule, but I could be wrong. Unfortunately, the above suggests that the right generalization to static expressions differs according to whether the type T incorporates gradual underflow. I'd say, if it does, the right generalization of T'Remainder would be to make the remainder exact. If not, I'd say the right generalization is to force underflowed results to zero, and otherwise use an exact result. The "gradual underflow" case corresponds to T'Denorm being true. It's likely the language in A.5.3(47) is a slip based on the implicit assumption that the operands are machine numbers (in which case a result that isn't a machine number must be an underflow). My personal suggestion: make the result be forced to zero if and only if T'Denorm is false, and the result R is such that T'Pred(0.0) < R < T'Succ (0.0). **************************************************************** From: Pascal Leroy Sent: Friday, April 9, 2004 3:18 AM > The case cited only obtains if the floating point representation doesn't > use gradual underflow. In that case, converting underflowed results to > 0.0 is easier in hardware than other methods. (I don't recall whether > there are machines that do anything different.) I'd be willing to bet > lots of money at even odds that this is the origin of the rule, but I > could be wrong. Thank you, Mike, for a very rigorous analysis. You're absolutely correct here. > It's likely the language in A.5.3(47) is a slip based on the implicit > assumption that the operands are machine numbers (in which case a result > that isn't a machine number must be an underflow). I concur. > My personal suggestion: make the result be forced to zero if and only if > T'Denorm is false, and the result R is such that T'Pred(0.0) < R < T'Succ (0.0). I find the dependence on T'Denorm unpalatable. However I could probably live with this: it is much more sensible that Tuck's notion of applying Machine to the arguments. **************************************************************** From: Pascal Leroy Sent: Friday, April 9, 2004 4:35 AM > I believe Ken Dritz of Argonne National Lab wrote much of this. He is > no fool. Right, and the description is exactly correct for nonstatic computations, as pointed out by Mike Yoder. (I withdraw my previous comment that the reference to zero in Remainder is overspecification: Mike convinced me that it is exactly the right thing.) A little bit of historical context helps here: this section is the result of integrating ISO/IEC 11729:1994 into the Ada 95 RM. Now 11729 was defining a predefined unit, so staticness was irrelevant. Unfortunately my copy of 11729 seems to have evaporated so I cannot check it, but I suspect that the problematic wording must have been inherited from 11729. > However, I wouldn't be > surprised if various compilers implement the attributes as > written (I know we do). Sorry, I don't take your word for it. We need a compiler survey here. The version of GNAT that I am using (arguably oldish) seems to agree with my interpretation for Compose; to believe that Scaling is never static; and to be using some form of inexact computation for Remainder (but not applying Machine to the arguments). Writing tests for static evaluation is really hard when you don't know what to expect, so it would be useful for implementers to tell us what they think they implement. **************************************************************** From: Tucker Taft Sent: Friday, April 9, 2004 7:31 AM We do the following for static computations of these attributes: S'Compose: S'Machine(Fraction*S'Machine_Radix**(-k) * S'Machine_Radix**Exponent) where "k" is the normalized exponent of Fraction S'Scaling: S'Machine(X * S'Machine_Radix**Adjustment) S'Remainder: Let R = X - Y * S'Unbiased_Rounding(X/Y) if R = S'Machine(R) then R else 0.0 end if I would suggest that we leave Compose and Scaling as is (including the application of S'Machine to the result). S'Remainder makes no sense as is. What do you propose we do instead? My preference would be to change it to return S'Machine(R), but making sure that it returns 0 on underflow. Note that S'Machine takes advantage of denormalized numbers if they exist on the machine, so there is no need to explicitly depend on S'Denorm. **************************************************************** From: Pascal Leroy Sent: Tuesday, April 13, 2004 7:14 AM This is _not_ what A.5.3(26, 29) require, btw. For Scaling, it should be, by a strict reading of the RM: V = X * S'Machine_Radix**Adjustment; if abs V >= T'Model_Small or else V = S'Machine (V) then return V; else return S'Machine (V); end if; Similarly for Compose. Your implementation is going to cause trouble when V is large because S'Machine will raise C_E (or be illegal in the case of static computations). **************************************************************** From: Tucker Taft Sent: Tuesday, April 13, 2004 6:35 AM Interesting. You are clearly right. The person who implemented our static evaluation must have thought for some reason just calling S'Machine would do the right thing. But that again presumes the inputs are machine numbers. And as you point out, even if they are machine numbers, it might give the wrong answer for large positive adjustments. > Your implementation is going to cause trouble when V is large because > S'Machine will raise C_E (or be illegal in the case of static > computations). Blech. Oh well, it's nice to have somebody else debug our compiler for a change... ;-) **************************************************************** From: Randy Brukardt Sent: Monday, April 26, 2004 8:33 PM > You _may_ but you don't _need_to_ if you hardware has appropriate > instructions. On a Pentium you can (should?) implement some of these > attributes using the FSCALE and FXTRACT instructions, and that won't > touch memory. For what it's worth (probably not much), Janus/Ada uses FSCALE and FXTRACT to implement these operations, and doesn't truncate to machine numbers. As I recall, these attributes are used frequently in the GEF implementation; you'd want to control the use of 'Machine only to those parts of the code where its actually needed. **************************************************************** From: Geert Bosch Sent: Wednesday, April 28, 2004 7:33 AM This seems confused. We were discussing the behavior of these attributes in a static context. If you would be using machine instructions such as FSCALE and FXTRACT for the static evaluation, that would not seem a conforming implementation is the operands are rounded to machine numbers as well. Of course the results of FSCALE and FXTRACT, which most likely are used for run-time evaluation, are by definition machine numbers. **************************************************************** From: Randy Brukardt Sent: Wednesday, April 28, 2004 2:49 PM > This seems confused. We were discussing the behavior of these attributes > in a static context. Actually, Pascal was discussing them in a dynamic context as well. But perhaps you missed that (I only noticed it when I re-read this stuff while filing it). > If you would be using machine instructions such > as FSCALE and FXTRACT for the static evaluation, that would not seem > a conforming implementation is the operands are rounded to machine > numbers as well. Of course the results of FSCALE and FXTRACT, which > most likely are used for run-time evaluation, are by definition > machine numbers. No, FSCALE and FXTRACT operate on the Pentium floating point stack, which are 80-bit numbers. These definitely are not machine numbers for float (for example). As Pascal notes, in an underflow case, these will be very different than one of the machine numbers (since the exponents of the 80-bit numbers go to +/- 1024); an implementation that doesn't truncate such numbers to zero is wrong, by the wording of the standard. But that means writing and rereading the values of memory on the Pentium, which obviously a substantial extra expense. The reason that we recognize these in the code generator is because they are commonly used in numerical software (like GEF); and that's the last place we want to be paying a large extra cost to truncate to machine numbers. Obviously we could avoid that by adding Machine_Compose and Machine_Scale attributes, but that seems like overkill. Or we can just not implement strict mode (that was our solution); but it's hard to see who benefits from that. ****************************************************************

Questions? Ask the ACAA Technical Agent