!standard A.05.03 (45) 01-02-12 AC95-00007/01
!class confirmation 01-02-12
!status received no action 01-02-12
!subject Surprising results from floating point 'Remainder function
!summary
!appendix
!topic Implementation of Floating Point 'Remainder function
!reference RM95-A.5.3(45)
!from Matt Spencer 01-02-09
!keywords Floating Point Remainder
!discussion
The implementation rules for the Floating Point 'Remainder function seem
incorrect. It describes that for S'Remainder (X, Y), v is the value X - n*Y,
where n is the "integer nearest to the exact value of X/Y". The portion in
quotes should state "integer as a result of truncating X/Y". Currently, if X =
7.0 and Y = 4.0 then X/Y = 1.75. n would equal 2, which is nearest integer to
1.75. The function will return X-n*Y, or 7.0 - 2.0 * 4.0 = -1. It seems that
the correct implementation would return 3, which would be the case if 1.75 would
have been truncated.
****************************************************************
From: Randy Brukardt
Sent: Friday, February 09, 2001 4:31 PM
It's very clear that "nearest" was the intent; here's the full paragraph:
For nonzero Y, let v be the value X - n · Y, where n is the integer
nearest to the exact value of X/Y; if |n - X/Y| = 1/2, then n is chosen
to be even. If v is a machine number of the type T, the function yields v;
otherwise, it yields zero. Constraint_Error is raised if Y is zero. A zero
result has the sign of X when S'Signed_Zeros is True.
The part about "if |n - X/Y| = 1/2" makes it clear that the authors intended
nearest.
Moreover, AARM A.5.3(47.b) says:
Ramification: The magnitude of the result is less than or equal to one-half
the magnitude of Y.
So it is crystal clear that the intent was that 'Remainder can return
negative values.
Now, one could argue that that isn't what the attribute should do, but I
think such arguments are about 7 years too late. Certainly, we're not going
to change the meaning of this attribute (it would break any programs that
currently use it).
****************************************************************
From: Tucker Taft
Sent: Monday, February 12, 2001 4:23 PM
Randy Brukardt wrote:
> ...
> It's very clear that "nearest" was the intent;
I agree that this is somewhat surprising, but Randy
is correct that 'Remainder is intentionally defined
the way it says.
This definition of Remainder comes from IEEE Floating
point, I believe (aka IEC 559:1989), and is implemented
in hardware in various IEEE floating point units.
Here is a quote from the Java Virtual Machine specification
which mentions the IEEE remainder operation:
... The IEEE 754 "remainder" operation computes the remainder from a
rounding division, not a truncating division, and so its behavior
is not analogous to that of the usual integer remainder operator....
****************************************************************
From: Pascal Leroy
Sent: Tuesday, February 13, 2001 3:20 AM
> Now, one could argue that that isn't what the attribute should do, but I
> think such arguments are about 7 years too late. Certainly, we're not going
> to change the meaning of this attribute (it would break any programs that
> currently use it).
One of the usages of Remainder is to do argument reduction for periodic
functions (e.g. the trigonometric functions with a Cycle parameter). In this
situation you want the result range to be symmetrical around zero, because
interesting functions are often odd or even. So the current definition is
exactly right in my opinion.
****************************************************************