J3,
I have been contacted by Michael Rutter of Cambridge University over an
issue that concerns him and some of the developers of gfortran.
Almost all current computers support signed zeros and NaNs and the
Standard mentions them in several places, for example, 7.4.3.2,
13.7.2.3.5, 16.9.22, 16.9.128, 16.9.189, 16.9.195. Some gfortran
developers became convinced that the Standard required real-complex
multiplication to be performed by first converting the real to complex,
even if it involved a performance penalty, because the result can differ
in the presence of NaNs and signed zeros. We believe that the
performance penalty is not required because the Standard allows the use
of a mathematically equivalent expression. It hinges on the exact
meaning of mathematical equivalence. We see no need for edits to the
Standard, but do see a formal interpretation as necessary to resolve the
issue among the gfortran developers.
Our draft interp is attached. Do you have any comments before I send it in?
Cheers,
John.
-------------- next part --------------
To: J3 J3/##-###
From: John Reid & Michael Rutter
Subject: Interp. on mathematical equivalence
Date: 2024-July-30
Reference: 24-007
NUMBER: F23/xxx
TITLE: Mathematical equivalence
KEYWORDS: arithmetic, operation, NaN
DEFECT TYPE: Clarification
STATUS: J3 consideration in progress
QUESTION
24-007, 10.1.5.2.4, paras 2-3 state
"Once the interpretation of a numeric intrinsic operation is established,
the processor may evaluate any mathematically equivalent expression,
provided that the integrity of parentheses is not violated.
Two expressions of a numeric type are mathematically equivalent if,
for all possible values of their primaries, their mathematical values
are equal. However, mathematically equivalent expressions of numeric
type can produce different computational results."
If the processor supports signed zeros and IEEE NaN values, are these
included in the set of possible values for the primaries and the results?
For example, consider the code
complex function csmul(a, b)
real :: a
complex :: b
csmul = a * b
end function csmul
Does an implementation that treats the multiplication as
cmplx(a*real(b),a*aimag(b))
instead of
cmplx(a) * b
conform to the standard, nowithstanding this statement in 24-007,
10.1.5.2.1, para 1
"The two operands of numeric intrinsic binary operations may be of
different numeric types or different kind type parameters. Except for a
value of type real or complex raised to an integer power, if the operands
have different types or kind type parameters, the effect is as if each
operand that differs in type or kind type parameter from those of the
result is converted to the type and kind type parameter of the result
before the operation is performed."?
Inputs for which the two methods can produce computationally-different
results on IEEE processors include
1/ One component of b is a NaN.
e.g. a*(r,NaN) might evaluate to (a*r,NaN) or (NaN,NaN)
2/ One component of b is an Inf
e.g. a*(r,Inf) might evaluate to (a*r,Inf) or (NaN,Inf)
3/ One component of b, or a, is -0.0
e.g. a*(r,-0.0) might evaluate to (a*r,-0.0) or (a*r,0.0)
ANSWER
The text quoted at the start of this question refers to traditional
mathematics, which does not include IEEE NaNs and signed zeros.
Implementations are permitted to treat the multiplication in the
example in either of the ways illustrated.
EDITS to 24-007
None.
SUBMITTED BY: John Reid & Michael Rutter
HISTORY: 24-nnn m234 Submitted