revise dtype handling in cupyx.scipy.ndimage.spline_filter

[grlee77]

This PR is related to #4247, but deals only with the recently implemented spline_filter functions from #4145.

The first commit here removes the allow_float32 keyword-only argument which is not present in scikit-image and has not yet appeared in a released CuPy version. It also changes the default output=np.float64 to output=None which will autoselect a floating point precision for the output. This allows computations to run in single precision by default on float16, float32 or complex64 inputs. In other words, the functionality previously provided by allow_float32=True becomes the default. update: restored default output to float64 for SciPy consistency. internal dtype behaves as if allow_float32=True.

If this type of single precision dtype handling seems okay, I would like to extend it to other functions in the ndimage module in a follow-up PR.

The second commit here adds tests for complex-valued inputs. These were previously supported, but were untested. Complex support was only recently merged upstream in SciPy and will be present in the upcoming 1.6.0 release, so for now a separate test class is used to allow this to also be tested on older SciPy versions.

[emcastillo]

For this PR we have decided to change the
allow_float32=False kwarg to use_intermediate_fp32=True to set this by default.

Eventually we want to have a common interface to address all these cases using a defined COMPUTE_MODE in an env var instead of just adding kwargs :).

How do you think?

[grlee77]

I can change the kwarg name and default to use_intermediate_fp32=True.

However, I am interested in extending this to most other functions in ndimage (aside from exceptions like binary morphology functions where it would not apply). It doesn't seem like it makes sense to proceed to add this same kwarg to all functions in ndimage.filters, ndimage.interpolation, etc. if the preferred solution is to move away from this and use a COMPUTE_MODE environment variable. Why not just start with the environment variable approach now? Otherwise it seems that we eventually have to go back and deprecate any unwanted keyword arguments.

[grlee77]

I reverted the change to output=None as a default. Now the output dtype will be consistent with SciPy, with the only difference being that intermediate computations can use float32 internally when the input is single precision.

[emcastillo]

Jenkins, test this please

[chainer-ci]

Jenkins CI test (for commit 20d6288, target branch master) succeeded!