!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

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

Questions? Ask the ACAA Technical Agent