[J3] Draft interp on mathematical equivence

[John Reid]

Steve,

We do quote 10.1.5.2.1 in the draft. Your reaction nicely illustrates 
why a formal interpretation is needed. Others do think mathematical 
equivalence comes into it.

Cheers,

John

Steven G. Kargl wrote:
> John,
>
> It seems the all important "10.1.5.2.1 Interpretation of numeric
> intrinsic operations" section was omitted from the list of sections.
>
>    The two operands of numeric intrinsic binary operations may be of
>    different numeric types or different kind type parameters. ...,
>    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.
>
> For "COMPLEX Z" and "REAL X", the Fortran standard requires
> "Z * X = Z * CMPLX(X)".  With the possibility that X is +-0, +-inf,
> or nan, I do not see how mathematical equivalence can come into
> play.
>
> --
> Steve
> Former gfortran contributor
>
>
> On Sat, Aug 10, 2024 at 12:19:46PM +0100, John Reid via J3 wrote:
>> 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.
>> 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
>>
>