!standard A.5.3(47) 13-10-24 AC95-00253/00

!class confirmation 13-10-24

!status received no action 13-10-24

!status received 13-10-11

!subject Remainder attribute

!class confirmation 13-10-24

!status received no action 13-10-24

!status received 13-10-11

!subject Remainder attribute

!summary

!appendix

From: Steve Baird Sent: Friday, October 11, 2013 7:55 PM One reasonably substantive question followed by two corner case nits. [Editor's note: Each question is handled separately.] 3) The definition of the Remainder attribute in A.5.3 includes If v is a machine number of the type T, the function yields v; otherwise, it yields zero. Assuming that 1/3 (the mathematical value) is not a machine number of type My_Float, this seems to imply that, given Named_Number : constant := My_Float'Remainder (1.0/3.0, 1.0); , Named_Number shall equal zero (which seems undesirable). (Recall that a subexpression of a static expression is evaluated exactly, so the division yields exactly one third). Is there a problem here that needs to be fixed? Presumably the "it yields zero" wording was only intended to apply in cases where the mathematically exact answer is close to zero. *************************************************************** From: Randy Brukardt Sent: Monday, October 14, 2013 6:26 PM > One reasonably substantive question followed by two corner case nits. Please, *please* do not mix unrelated questions in ARG messages. That drives your editor nuts when he has to separate them. ... > 3) The definition of the Remainder attribute in A.5.3 includes > > If v is a machine number of the type T, the function yields v; > otherwise, it yields zero. > > Assuming that 1/3 (the mathematical value) is not a machine number of > type My_Float, this seems to imply that, given > > Named_Number : constant := My_Float'Remainder (1.0/3.0, 1.0); > > , Named_Number shall equal zero (which seems undesirable). > > (Recall that a subexpression of a static expression is evaluated > exactly, so the division yields exactly one third). > > Is there a problem here that needs to be fixed? > > Presumably the "it yields zero" wording was only intended to apply in > cases where the mathematically exact answer is close to zero. This subject was raised years ago in AI95-0379-1. That AI was eventually voted "No Action". The mail on the topic starts about halfway down (mail from Pascal Leroy, April 7, 2004 3:31 AM). It's not clear from the mail why it was voted "No Action", but there did seem to be a consensus that it is exactly correct for runtime evaluation. That's because the inputs are necessarily machine numbers, and the only time that v is not a machine number in that case is in underflow situations. Indeed, it's important to prescribe zero as the result in that case for machines without "gradual underflow" [whatever that is]. See Mike Yoder's message for lengthy details. The only problem comes with static evaluation of the attribute (that is, when both operands are static). Then the machine number assumption isn't true and weird things can happen. Here's the minutes (November 2004) on why we didn't fix this: "The wording is fine for non-static computations. There are problems for static expressions. But the fix is hard. Pascal doesn't want to work to find fixes. Tucker thought that they had agreed on the needed fixes; Randy notes that only one was explained in a fashion that he could understand well enough to put in the AI. There are two other attributes that may also need fixes." It's possible this was in part because we were wrapping up Ada 2005 and didn't want to mess with things that aren't that important. In any case, this is not very broken, and I'm not sure what's changed since late 2004 such that we would want to try to fix it. If we do want to try to fix it, we ought to fix all of the problems with statically evaluated attributes defined in A.5.3, not just this one. That seems like a nasty numerics rathole to me (as Pascal noted, A.5.3 was written assuming runtime evaluation only, and a lot of it is dubious when considering static evaluation). *************************************************************** From: Steve Baird Sent: Monday, October 14, 2013 7:33 PM >> 3) The definition of the Remainder attribute in A.5.3 includes >> > This subject was raised years ago in AI95-0379-1. I didn't realize the topic had come up before. Given that, I agree that there is no reason to discuss it again. ***************************************************************

Questions? Ask the ACAA Technical Agent