[J3] Draft interp on mathematical equivence

[Robert Corbett]

The Fortran standards do not specify how complex multiplication is implemented.  While the implementation involving four multiplications, an addition, and a subtraction is commonly used, it is not the only way complex multiplication can be implemented.  I have seen an implementation of complex multiplication that uses three multiplications, plus some additions and subtractions.  The implementation appears to be related to Strassen’s method for multiplying 2x2 matrices.

An implementation of complex multiplication could test for zeros and ones in the operands to avoid unnecessary arithmetic operations.  I see nothing in the Fortran standards that prohibits such an implementation.

I know of implementations of complex exponentiation that check for special values of the operands to avoid unnecessary work (and unnecessary exceptions).  The only difference I see between the cases of complex multiplication and complex exponentiation is the cost of the operations involved.

Bob Corbett

> On Aug 11, 2024, at 11:43 AM, Toon Moene via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> On 8/11/24 15:16, Robert Corbett via J3 wrote:
> 
>> Note that if the mathematical equivalence rule were required to preserve the semantics of exceptional values,  common optimizations such as replacing
>>       (0.0*X)
>> and
>>        (X - X)
>> with the value
>>       REAL(0.0, KIND(X))
>> would not be permitted.  I know of Fortran implementations that prohibit such optimizations when certain compiler options are specified.
>> Bob Corbett
> 
> The GNU compilers work the other way around. You, the user, have to specify if certain optimizations are allowed based on the properties THAT YOU TRUST of the program TO HAVE.
> 
> Take this simple example of the problem at hand:
> 
> $ cat complex.f90
> complex function p(c, r)
> complex, intent(in) :: c
> real, intent(in)    :: r
> p = c * r
> end
> 
> If you compile this just with
> 
> $ gfortran -S complex.f90
> 
> you'll get code that has four multiplications and an add and subtract, for six floating point operations.
> 
> If you compile with
> 
> $ gfortran -S -fno-signed-zeros -ffinite-math-only complex.f90
> 
> you'll get code that has just two multiplications [i.e., just like you would have gotten if you spelled out the cmplx(r*real(c), r*imag(c))].
> 
> (-ffinite-math-only instructs the compiler to ignore the special handling of NaN and Inf).
> 
> Now I know that all MY code can safely be compiled with -fno-signed-zeros -ffinite-math-only, but don't try this with a recent version of LAPACK (e.g., 3.11.0). They check on this and will slap you on the wrist (and refuse any further cooperation).
> 
> Kind regards,
> Toon.
> 
>>>> On Aug 10, 2024, at 7:52 PM, Steven G. Kargl via J3 <j3 at mailman.j3-fortran.org> wrote:
>>> 
>>> On Sat, Aug 10, 2024 at 11:29:35PM +0200, Toon Moene via J3 wrote:
>>>>> On 8/10/24 23:01, Robert Corbett via J3 wrote:
>>>>> 
>>>>> 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
>>>> 
>>>> From the Fortran 77 Standard (6.6 Evaluation of Expressions):
>>>> 
>>>> "Any arithmetic operation whose result is not mathematically defined is
>>>> prohibited in the execution of an executable program. Examples are
>>>> dividing by zero and raising a zero-valued primary to a zero-valued or
>>>> negative-valued power. Raising a negative-valued primary to a real or
>>>> double precision power is also prohibited."
>>>> 
>>>> It is my understanding that the concept of NaN or Infinity is only catered
>>>> for when USEing the IEEE modules:
>>>> 
>>>> "17.1 Overview of IEEE arithmetic support
>>>> 
>>>> The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and
>>>> IEEE_FEATURES provide support3 for the facilities defined by ISO/IEC
>>>> 60559:2020."
>>>> 
>>>> (From the latest version - 2023 - of the Standard).
>>>> 
>>> 
>>>  10.1.5.2.4
>>>  The execution of any numeric operation whose result is not
>>>  defined by the arithmetic used by the processor is prohibited.
>>> 
>>> Let's call +-0, +-inf, and nan exceptional values.  Then, if the
>>> exceptional values are not defined by the arithmetic used by
>>> the processor, a programmer's code that could run into one of
>>> these is nonconforming.  That is, in Z*X, none of REAL(Z), AIMAG(Z),
>>> nor X can be exceptional and the results of either the short-circuited
>>> evaluation or the standard conforming full evaluation of '*' cannot
>>> have an exceptional value (if it does, the processor can do anything).
>>> 
>>> So, now you're down to the exceptional values are defined by the
>>> arithmetic.  In that case, short-circuiting cannot occur under
>>> mathematically equivalence, because
>>> 
>>>  10.1.5.2.4
>>>  Two expressions of a numeric type are mathematically equivalent if,
>>>  for all possible values of their primaries, their mathematical values
>>>  are equal.
>>> 
>>> If one uses Z = (A,B), then Z*X = (A*X-B*0,A*0+B*X) for the evaluation
>>> after type conversion and Z*X = (A*X,B*X) without type conversion.
>>> A*X may not be equivalent to A*X-B*0 if any of A, X, or B is exceptional.
>>> B*X may not be equivalent to A*0-B*X if any of A, X, or B is exceptional.
>>> 
>>> --
>>> Steve
> 
> --
> Toon Moene - e-mail: toon at moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
>