BUG: complex special case for clip

[birm]

Fixes #15630
Continues #15640

For now, I've just removed tests that didn't work with the clip. I'll re-add and fix them if this is judged to be useful.

[charris]

This is a big change in behavior, OTOH, I can't see anybody relying on the previous behavior :)

@seberg I've tagged this for triage.

[seberg]

Clip uses minimum and maximum for the 1 parameter version, so I doubt that this covers that part. If nobody relies on it, might as well go through a short futurewarning?
I am unsure I like defining clip to deviate from min/max, but the main issue around it is the fallback to minimum/maximum which we currently use and practically enforces symmetry.

[birm]

It wasn't mentioned as a recommended option in the base issue, but maybe just warning on use of clip with complex input is sufficient.

[mattip]

Is there a actual use case for this? In any case it seems the consensus is for the behaviour to box-clip (separately clip real and imaginary) without touching min/max: the ufunc should not re-use max and min. In any case the proposal should be discussed on the mailing list.

[rgommers]

Thanks @birm, test cases look fine to me.

[charris]

@birm Needs a release note, see doc/release/upcoming_changes for examples. This probably needs two entries, one for compatibility, and another for new_feature. The docstring for fromnumeric.clip also needs updating with a .. versionchanged:: note. In particular, the way to specify the box in the complex case needs explanation.

[eric-wieser]

Did we ever decide we actually wanted this? My understanding was we were only able to justify it if we deprecated the comparison on complex numbers which the current behavior is consistent with. Have we done that?

[seberg]

No, there is a bit of a net of dependencies. Comparison is used in sorting. For sorting we have a solution (i.e. we can add a "sortkey", the code for which is mostly ready). I think my main problem was that np.minimum and np.maximum should probably also be deprecated with that. Which may be OK, but there is no obvious replacement for them.

[charris]

@birm Needs a rebase. I don't see any reason not to put this in.

[birm]

Trying to fix my messes, as ever. I'm not opposed to maintainer changes, but I'll try to fix the tests as best as I can.