Integral_image: promote floating point inputs to double by default

[grlee77]

Description

This PR was split off from #5372 as it is a change in existing behavior. To avoid surprises due to poor accuracy of floating point cumulative sums, I propose we default to double precision when computing integral images. See additional details in prior comment: #5372 (comment).

The user can override the default by manually specifying the dtype argument.

One question is whether we can consider this a bug fix or if we should introduce a deprecation cycle before making the switch. The new output should be strictly an improvement from an accuracy standpoint, but output dtype will be larger for float16, float32 or complex64 inputs.

Checklist

• Docstrings for all functions
• Gallery example in ./doc/examples (new features only)
• Benchmark in ./benchmarks, if your changes aren't covered by an
  existing benchmark
• Unit tests
• Clean style in the spirit of PEP8

For reviewers

• Check that the PR title is short, concise, and will make sense 1 year
  later.
• Check that new functions are imported in corresponding __init__.py.
• Check that new features, API changes, and deprecations are mentioned in
  doc/release/release_dev.rst.

[jni]

I think on some Windows builds, "float" will default to float32. Should we specify np.float64 here?

[grlee77]

That is the case for int on 32-bit, but I thought float was usually double precision? Definitely not a problem to just use np.float64 to make it unambiguous, though

[mkcor]

One question is whether we can consider this a bug fix or if we should introduce a deprecation cycle before making the switch.

I'm happy to consider it a bug fix, since the change fixes floating-point cumulative sums which used to be off. Does @rfezzani agree?

The new output should be strictly an improvement from an accuracy standpoint, but output dtype will be larger for [...] complex64 inputs.

Which (larger) output dtype do complex64 inputs yield? I guess complex128 where the complex number is represented by two 64-bit floats?

[grlee77]

Which (larger) output dtype do complex64 inputs yield? I guess complex128 where the complex number is represented by two 64-bit floats?

Yes, this is correct.

[rfezzani]

One question is whether we can consider this a bug fix or if we should introduce a deprecation cycle before making the switch.

I'm happy to consider it a bug fix, since the change fixes floating-point cumulative sums which used to be off. Does @rfezzani agree?

The new output should be strictly an improvement from an accuracy standpoint, but output dtype will be larger for [...] complex64 inputs.

Which (larger) output dtype do complex64 inputs yield? I guess complex128 where the complex number is represented by two 64-bit floats?

Sorry for not being available these last weeks 🙏...

👍 I agree @mkcor, and thank you @juan for merging this 😉 and thank you again @grlee77 🎉