BUG: initial parameter in reduction operations is incorrectly type-converted

[jkunimune]

Describe the issue:

When the initial parameter of a reduction operation has a type that is different from the contents of the array, it is converted to match in C, and thereby circumvents many of the checks that would normally go with such a conversion in Python. This sometimes leads to behavior that would make sense in C, but seems incorrect in Python. It seems to me that initial should be converted to the same type as the array in the Python function before it is passed to the C layer.

Reproduce the code example:

import numpy as np
a = np.array([1, 2, 3])
print(np.amin(a, initial=np.inf))
# expected result: either 1 or OverflowError('cannot convert float infinity to integer')
# actual result: -2147483648

NumPy/Python version information:

Numpy 1.20.2
Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64 bit (AMD64)]

[seberg]

Thanks for the report. The behavior may actually be influenced by gh-20924. gh-21437 should ensure that we at least get a warning here, I think.

In principle, there is a question whether input scalars should be cast to the correct dtype (similar to np.asarray(np.inf).astype(correct_dtype) or _coerced np.asarray(np.inf, dtype=correct_dtype), which is subtly different when it comes to handling such "unsafe" casts.

There is also a question whether initial should be allowed to affect the result dtype (i.e. a float array be returned in that example), but that may be a larger change.

[seberg]

Closing, should be strict now in this case... and in general just use normal assignment rules, which I think is fine.
(There is a related issue of whether the initial parameter should be taken into account for casting safety or promotion.)