API: Ensure that casting does not affect ufunc loop

This ensures that casting does not affect ufunc loops, which means
that the following will give the same result:

```
>>> np.not_equal(None, False, dtype=bool)
True

>>> np.not_equal(None, False, dtype=bool, casting="unsafe")
False
```

This is absolutely necessary to make new promotion and type resolution
sane.

In some cases, it causes problems with existing weirder dtype usage,
the workaround is that we allow the promoter (in current terms the
type resolver) to resolve more strictly (potentially ignoring input
types).
I.e. a promoter (after not finding match), can use the fixed (signature)
dtypes to infer the loop.

Because this makes things more strict, most importantly `nextafter`
causes problems. Code like:
```
np.nextafter(0., np.inf, dtype=np.float32)
```
looks harmless enough, but requires such preferential treatment.  NumPy
has such capabilities currently for the homogeneous type resolver, so
changing to that fixes it (SciPy uses the above quite a lot).

SciPy also has code like (in the tests):
```
np.nextafter(0, 1)
```
which will now FAIL.  However, this is for the better since the above code
is actually buggy: It will return different values on windows and 32bit linux
because it will find the float32 instead of the float64 loop. That is almost
certainly not the expected result.

0 files changed, 0 insertions, 0 deletions