[J3] Draft interp on mathematical equivence

[Robert Corbett]

The question assumes that the rules of mathematical equivalence need to accommodate NaNs and infinites.  That was not the intent of the committee when the concept of mathematical equivalence was added to the standard.  The rules of mathematical equivalence assume that expressions can be modified as if integer, real, and complex expressions are mathematical integer, real, and complex expressions, subject to a few additional restrictions stated in the standard, such as the requirement that the integrity of parentheses be honored.

Bob Corbett

> On Aug 10, 2024, at 12:17 PM, John Reid via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 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
>>> 
>> 
>