FFT output dtype mismatches with NumPy's

This relates to the test failures we saw in #3587.

Reproducer:

import numpy as np
import cupy as cp


dtypes = [np.int8, np.int16, np.int32, np.int64,
          np.uint8, np.uint16, np.uint32, np.uint64,
          np.float16, np.float32, np.float64,
          np.complex64, np.complex128]

for dtype in dtypes:
    a_np = np.random.random(100).astype(dtype)
    a_cp = cp.asarray(a_np)
    b_np = np.fft.fft(a_np)
    b_cp = cp.fft.fft(a_cp)
    if b_np.dtype != b_cp.dtype:
        print(f"in_dtype {a_np.dtype}: NumPy out_dtype {b_np.dtype}; CuPy out_dtype {b_cp.dtype}")

Output:

in_dtype float16: NumPy out_dtype complex128; CuPy out_dtype complex64
in_dtype float32: NumPy out_dtype complex128; CuPy out_dtype complex64
in_dtype complex64: NumPy out_dtype complex128; CuPy out_dtype complex64

I think CuPy is actually making sense and I don’t understand:

1. why pocketfft chose to promote the dtype
2. why our tests did not discover this

We’ll also need to discuss if we want to enforce a strict compliance for this issue, as our current implementation clearly has performance advantage…

cc: @emcastillo @grlee77 @peterbell10

[leofang]

I am being stupid again — I can close this myself 😂

[leofang]

Sorry, this is largely due to my stupidity — I should have recalled it before filing an issue. This behavior is well documented here: https://docs.cupy.dev/en/stable/reference/fft.html#code-compatibility-features

FFT functions of NumPy alway return numpy.ndarray which type is numpy.complex128 or numpy.float64. CuPy functions do not follow the behavior, they will return numpy.complex64 or numpy.float32 if the type of the input is numpy.float16, numpy.float32, or numpy.complex64.

It’s been the case since the beginning of CuPy (#477), and in the tests we do work around this issue. @kmaehashi Could you close this please? Sorry for the noise…😞