ENH: integrate: cumulative_simpson can support complex dtypes with small change

[TheIdealis]

Describe your issue.

If I use cumulative_simpson with a complex valued array, the imaginary part is discarded in _cumulatively_sum_simpson_integrals. The problem can be fixed easily by changing

sub_integrals = np.empty(shape)

to

sub_integrals = np.empty(shape, dtype=y.dtype)

Reproducing Code Example

from scipy.integrate import cumulative_simpson, simpson
import numpy as np

x = (1 + 1j) * np.ones(10)

print(cumulative_simpson(x))

Error message

.../python3.10/site-packages/scipy/integrate/_quadrature.py:857: ComplexWarning: Casting complex values to real discards the imaginary part
  sub_integrals[..., :-1:2] = sub_integrals_h1[..., ::2]

SciPy/NumPy/Python version and system information

cython
    version: 3.0.10
numpy
    version: 1.26.4
scipy
    version: 1.13.0
host:
    cpu: x86_64
    endian: little
    family: x86_64
    system: linux
Python Information:
  version: '3.10'

[j-bowhay]

cc @nprav

[mdhaber]

Typically, when the documentation doesn't specifically mention complex dtypes, it was developed with only real dtypes in mind. For instance, quad got support for complex valued functions relatively recently. The documentation of cumulative_simpson doesn't suggest that it should work for complex data, so we can consider this as an enhancement request.

@TheIdealis you're welcome to submit a PR. In addition to the adjustment you mentioned, please:

• consider cumulative_trapezoid, simpson, trapezoid, and other similar functions that can easily support complex y
• adjust the documentation to distinguish between real and complex inputs (e.g. the x input still needs to be real)
• write a unit test shared between the functions to check for correct behavior

[TheIdealis]

@mdhaber I'd like to do it, but I rarely ever did a PR so it might take some days to find the time for it. Just one small question. The documentation of e.g. cumulative_trapezoid is not specifying complex values either. Should I add this in those documentation entries as well? In the same manner as in e.g. fft: ", can be complex"?

[mdhaber]

Should I add this in those documentation entries as well?

Yes, that's what I mean by "consider cumulative_trapezoid, simpson, trapezoid, and other similar functions that can easily support complex y". I think we should ensure that similar functions have similar capabilities, and if we intend to provide those capabilities, they should be documented.