[J3] [BULK] SCALE(x,i) with complex x

[Steven G. Kargl]

On Thu, Nov 09, 2023 at 08:44:58AM +0900, Malcolm Cohen wrote:
>
> Finally, I think the gfortran guys should get the free performance
> boost by calculating the mathematical real*complex. There are no
> user parentheses to violate here, so it falls clearly within the
> "mathematical equivalence" rule.

From a mathematical stand-point, there is an implicit set of
parentheses in real*complex.

r*z = r*(x+Iy) = r*x + Ir*y,  (I being sqrt(-1))

One may also write that a complex number as an ordered pair, which
is sometimes expressed as z = (x,y).  This then gives r*z=(r*x,r*y).
Certainly seems to be a "distributive" property.

The above mathematical representations can certainly be pushed aside
as I agree the Fortran standard does not specify implementation detail.

It does however specify type conversion (F2018, 10.1.5.2.1).  r*z
becomes cmplx(r,0)*z, which is complex*complex.  Multiplication
of complex entities then gives (r*x - 0*y) + I(r*y + 0*x).  A
Fortran processor that short-circuits this to r*x+Ir*y is simply
ignoring the possibility that either x or y can be +-inf and nan.
gfortran's -ffast-math option allows one to achieve this short
circuiting.

I suppose that one could argue via 10.1.5.2.4 that +-inf and
nan "are not defined by the arithmetic used by the processor",
so 0*(+-inf) and 0*nan mean the program is non-conforming.  A
processor is then free to do whatever the developers wants.  If
this is the case, then that processor likely does not support
Fortran 2018, Sec. 17, which is allowed by the Fortran standard.  

I concede, and won't bother J3 with other suggestions.

-- 
Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3950 bytes
Desc: not available
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20231108/d6c65fe2/attachment.bin>