allow single precision operation in the cupyx.scipy.ndimage module

allow single-precision computations in cupyx.scipy.ndimage

I opened this PR to discuss the potential for performing computations in single precision in cupyx.scipy.ndimage functions when the input is single precision. Currently, the internal weights arrays used in the convolution function, etc. are always np.float64, which does match the internal use of double precision in scipy.ndimage. However, to improve performance and reduce memory usage, it would be preferable to use single precision for the computations when possible.

A similar exception was made previously for cupy.fft where inputs are NOT automatically promoted to double precision as in NumPy.

I see three ways this can potentially be done (I am willing to make the necessary changes, but need to know what approach would be preferred).

• automatically promote types to at least float32 via: cp.promote_types(image, cupy.float32) instead of just using cupy.float64 everywhere (e.g. for the weights arrays in convolution)
• leave the default internal floating point type float64, unless a boolean keyword-only argument (e.g. allow_float32) is specified
• add a global cupy configuration variable to control whether single-precision computation is allowed within the cupyx.scipy.ndimage module

related issue: complex dtype support

A separate consideration is adding support for complex-valued inputs. I have open PRs for this in SciPy for the filtering and interpolation functions (scipy/scipy#12725 and scipy/scipy#12812). Hopefully those will be merged for SciPy 1.6.0 and then we can revisit adding complex support here.

cc: @jakirkham, @quasiben

[jakirkham]

I don’t think there is an equivalent issue related to single-precision open on SciPy. For SciPy itself, I think the argument is less compelling because the amount of work required would be substantial and the performance benefits of single precision may not be substantial.

Ah right. Sorry forgot this.

It may still be worth adding an issue even if it is closed out as unfeasible or lingerings for time. At least that will make this issue more visible to others who may care about the performance improvement.

[grlee77]

~I don’t think there is an equivalent issue related to single-precision open on SciPy.~ There is an issue scipy/scipy#8495. For SciPy itself, I think the argument is less compelling because the amount of work required would be substantial and the performance benefits of single precision may not be substantial.

As an example, many C functions copy lines to buffers that are double precision and the temporary variable holding the convolution result is double, etc. Adding templating would make the source C code harder to read and a rewrite to templated C++ would be a lot of work.

On the CuPy side the kernel C++ code is generated on the fly, so it is minimal effort to support single and/or complex dtypes as well.