geggo / gpyfft

python wrapper for the OpenCL FFT library clFFT
GNU Lesser General Public License v3.0
54 stars 21 forks source link

Real->complex and complex->real #42

Open vincefn opened 6 years ago

vincefn commented 6 years ago

I have a question regarding complex<->real plans.

You can create a real<->complex plans using:

 ny, nx = 256, 280
 nx2 = nx //2 + 1
 d = np.arange(ny * nx).reshape((ny,nx)).astype(np.float32)
 cl_d = cla.to_device(queue=queue,ary=d.astype(np.float32))
 cl_d_ft = cla.zeros(queue=queue, shape=(ny, nx2), dtype=np.complex64)
 planr2c = gpyfft.FFT(ctx, queue, cl_d, cl_d_ft, axes=(-1,-2))
 planc2r = gpyfft.FFT(ctx, queue, cl_d_ft, cl_d, axes=(-1,-2), real=True)

... and cl_d_ft is a complex hermitian array - OK However, to create a complex(half-hermitian array)->real plan, you need to use real=True keyword, but why is it needed ? Should it not be sufficient to detect that the input is complex and output real to trigger the creation of a complex-hermitian->real plan ? (it took me a while to find that keyword was needed, that's why I'm asking...)

geggo commented 6 years ago

Dear Vincent,

thanks for your hint, you are right, for an out-of-place complex->real transform, where both in- and output arrays are provided by the user, the real=True keyword should not be necessary (only for an inplace transform).

Real<->complex transforms are a late addition and still lack tests, I did not yet dare to fiddle around with the interface.

Gregor

vincefn commented 6 years ago

Is there any case where the real keyword is used beside real<->complex transforms ? Can I submit a PR deprecating this keyword ? Thanks, Vincent

vincefn commented 6 years ago

I just saw the inline-real2real branch. No deprecation then ? But may be useful to recognize the complex hermitian->real transform without the keyword. Could inline real2real also be recognized automatically from having in_array.dtype=np.float* and out_array=None ?