Mark explicit `plan` in `cupyx.scipy.fftpack.*` a stable API?

The explicit plan argument in cupyx.scipy.fftpack.* and the get_fft_plan() function there were added in v6. I have used it extensively in production since then, and I also heard positive feedbacks (via private communication). The plans (Plan1d or PlanNd) returned by the get_fft_plan() handle can be reused either explicitly as an argument, or implicitly as a context manager. In other words, the plans can be used

• implicitly in cupy.fft.fft.* (and later cupyx.scipy.fft.*)
• explicitly in cupyx.scipy.fftpack.*

Given where we are now, and that the cupyx.scipy.fft API will be added soon (#2355) which do not take a plan as argument, I wonder if this nice feature can be removed from the “experimental” status and become a stable API. Thanks.

[grlee77]

Hi @leofang. I think your summary of the SciPy side of things sounds correct.

I understand wanting to keep APIs consistent, but I also think there are practical considerations that warrant exceptions. For example IIRC, cupy.fft.fft has always preserved single precision dtypes while NumPy’s version explicitly casts to double, so apparently an exception was already made in that case. When there is a clear performance or utility benefit to allowing something, then I think it makes sense to do so as long as it is clearly documented. Perhaps there could even be a specific documentation page that collects these exceptions in a central location for easier reference.

I was also under the impression that the cupyx module was perhaps a bit more accepting of such deviations than the core cupy API.

[leofang]

@asi1024 Don’t worry too much 🙂

First, with scipy.fft being added in v1.4.0 and in preference to scipy.fftpack, the latter is considered as “long term legacy” (https://github.com/cupy/cupy/pull/2355#issuecomment-517325388) and maintained only for backward compatibility. I doubt there will be any change over its API.

Second, in the event that a plan argument is to be added to scipy.fftpack, we can and will try to coordinate the efforts (with @grlee77 and @peterbell10). For example, this SciPy issue title is renamed exactly for the need of CuPy discussed here, see https://github.com/scipy/scipy/issues/10302#issuecomment-517351532.