!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
!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.

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