incorrect FFT results for Fortran-order arrays?

• Conditions (from python -c 'import cupy; cupy.show_config()')

Tested in two environments with different CuPy versions:

CuPy Version          : 4.4.1
CUDA Root             : /usr/local/cuda
CUDA Build Version    : 9010
CUDA Driver Version   : 9010
CUDA Runtime Version  : 9010
cuDNN Build Version   : 7102
cuDNN Version         : 7102
NCCL Build Version    : 2115

and (this CuPy is built from the latest master branch)

CuPy Version          : 6.0.0b1
CUDA Root             : /usr/local/cuda
CUDA Build Version    : 9010
CUDA Driver Version   : 9010
CUDA Runtime Version  : 9010
cuDNN Build Version   : None
cuDNN Version         : None
NCCL Build Version    : None

• Code to reproduce

import numpy as np
import cupy as cp

AXES=[(0,), (1,), (2,), (0,1), (1,2), (0,2), (0,1,2)]
a_np = np.random.random((3,4,5))+1j*np.random.random((3,4,5))

print("In C order:")
a_np = np.ascontiguousarray(a_np)
a_cp = cp.asarray(a_np)
a_cp = cp.ascontiguousarray(a_cp)
assert np.allclose(cp.asnumpy(a_cp), a_np)
for axes in AXES:
    result_np = np.fft.fftn(a_np, axes=axes)
    result_cp = cp.fft.fftn(a_cp, axes=axes)
    print(axes, ":", np.allclose(cp.asnumpy(result_cp), result_np))

print("\nIn F order:")
a_np = np.asfortranarray(a_np)
a_cp = cp.asarray(a_np)
a_cp = cp.asfortranarray(a_cp)
assert np.allclose(cp.asnumpy(a_cp), a_np)
for axes in AXES:
    result_np = np.fft.fftn(a_np, axes=axes)
    result_cp = cp.fft.fftn(a_cp, axes=axes)
    print(axes, ":", np.allclose(cp.asnumpy(result_cp), result_np))

• Error messages, stack traces, or logs

The outputs from both environments are identical:

In C order:
(0,) : True
(1,) : True
(2,) : True
(0, 1) : True
(1, 2) : True
(0, 2) : True
(0, 1, 2) : True

In F order:
(0,) : False
(1,) : True
(2,) : False
(0, 1) : True
(1, 2) : False
(0, 2) : False
(0, 1, 2) : True

But it’s expected to be True for all of the axes choices. It seems to me the bug is not introduced by the recent changes in adding support for cuFFT plans (#1669, #1745, #1746) but by something much older. For now I have not yet tracked down the problem, will update here if I find it. I hope I didn’t do something stupid in the test…

Thanks.

[fiarabbit]

@leofang I’m very sorry that I did not write that my second comment is executed in the master-branch environment. I edited my comment.

[grlee77]

I think I spotted the inconsistency among our outputs. The reason is that I was using NumPy v1.14.2 from conda

Okay, that makes sense. conda’s default channel replaces numpy’s fftpack with mklfft which had a bug with Fortran-ordered input that was only recently fixed: https://github.com/IntelPython/mkl_fft/pull/30 numpy recently expanded their tests to check for this as well: https://github.com/numpy/numpy/pull/12702