func argument in legend_elements with non-monotonically increasing functions

[rlung]

Account for inverse (or other) relationships where np.interp will not work correctly.

PR Summary

legend_elements does not account for inverse or non-monotonically increasing functions. See this post for an example. The problem is in using np.interp, which requires a monotonically increasing input xp. This PR sorts xp first before calling np.interp.

PR Checklist

• Has Pytest style unit tests
• Code is Flake 8 compliant
• New features are documented, with examples if plot related
• Documentation is sphinx and numpydoc compliant
• Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

[anntzer]

It's not clear to me why we bother going through this interpolation. After all, immediately above we assume that func can be called with all values at once (label_values = func(values)), so why not do the same here?

[rlung]

I suppose because the label values are the "starting point" to ideally get somewhat even/round numbers to display. The inverse of func would be required to get the sizes from these label values so interpolation might be an easier way to get there. In the line of code you reference, the idea seems to be to just use the data points available for the legend and not necessarily even/round numbers.

[ImportanceOfBeingErnest]

I'm pretty sure I just forgot that numpy.interp needs increasing input. (obviously any non-monotonic function would produce senseless output anyways)
So this looks like a correct fix.
The test suite results are pretty messy, I doubt the failures are from this PR. Yet, adding a test for the case in question (a 1/x relation or similar) would be good.

[QuLogic]

The test failures are unrelated. However, please add a test for this new case.

[timhoffm]

Modulo adding a test.

[rlung]

Added a test. I'm fairly new to this, so I'm not sure if the test is causing some of these failures. However, there were a lot of failures initially with this PR, though I don't know how they were resolved before these recent changes.

[QuLogic]

If you rebase this, it should fix the CI failures.

[jkseppan]

Thanks @rlung!