fft - Is the storage of COMPLEX in fortran guaranteed to be two REALs?

Question

Many FFT algorithms take advantage of complex numbers stored with alternating real and imaginary part in the array. By creating a COMPLEX array and passing it to a FFT routine, is it guaranteed that it can be cast to a REAL array (of twice the size) with alternating real and imaginary components?

    subroutine fft (data, n, isign)
      dimension data(2*n)

      do 1 i=1,2*n,2
        data(i) = ..
        data(i+1) = ..
 1    continue
    return
    end

    ...
    complex s(n)
    call fft (s, n, 1)
    ...

(and, btw, is dimension data(2*n) the same as saying it is a REAL?)

Answer 1

I'm only writing this answer because experience has taught me that as soon as I do write this sort of answer one of the real Fortran experts hereabouts piles in to correct me.

I don't think that the current standard, nor any of its predecessors, states explicitly that a complex is to be implemented as two neighbouring-in-memory reals. However, I think that this implementation is a necessary consequence of the standard's definitions of equivalence and of common. I don't think I have ever encountered an implementation in which a complex was not implemented as a pair of reals.

The standard does guarantee, though that a complex can be converted into a pair of reals. So, given some definitions:

complex :: z
complex, dimension(4) :: zarr
real :: r1, r2
real, dimension(8) :: rarr

the following will do what you might expect

r1 = real(z)
r2 = aimag(z)

Both those functions are elemental and here comes a wrinkle:

real(zarr)

returns a 4-element array of reals, as does

aimag(zarr)

while

[real(zarr), aimag(zarr)]

is an 8-element array of reals with the real parts of zarr followed by the complex parts. Perhaps

rarr(1:8:2) = real(zarr)
rarr(2:8:2) = aimag(zarr)

will be OK for you. I'm not sure of any neater way to do this though.

Alexander's not the only one able to quote the standard ! The part he quotes left me wondering about non-default complex scalars. So I read on, and I think that para 6 of the section he points us towards is germane

a nonpointer scalar object of any type not specified in items (1)-(5) occupies a single unspecified storage unit that is different for each case and each set of type parameter values, and that is different from the unspecified storage units of item (4),

I don't think that this has any impact at all on any of the answers here.