Don't convert numbers plotted on an axis with units #10206
Conversation
lib/matplotlib/tests/test_units.py
Outdated
| if iterable(self.magnitude): | ||
| return Quantity(self.magnitude[item], self.units) | ||
| else: | ||
| return Quantity(self.magnitude[item], self.units) |
There was a problem hiding this comment.
🤦♂️ the most useless if statement in the world.
| @@ -1498,6 +1498,10 @@ def have_units(self): | |||
| return self.converter is not None or self.units is not None | |||
|
|
|||
| def convert_units(self, x): | |||
| # If x is already a number, doesn't need converting | |||
| if munits.ConversionInterface.is_numlike(x): | |||
There was a problem hiding this comment.
Right now the assigned converter deals with the floats.
This change means that a user can never create a converter that accepts numlike vectors and does something with them. They'd always have to wrap it in a class that is_numlike doesn't think is numlike.
I guess I'm OK w/ that restriction, and I don't think it harms any of our current converters. But, I'm not 100% sure what the rest of the world is doing.
There was a problem hiding this comment.
BTW pinging @tacaswell, @anntzer and @story645 as they are working on categoricals where unit handling has come up a lot
There was a problem hiding this comment.
Hmm, you make a good point. If the decision is to allow plotting numbers on an axis with units, then this PR is the way to go. (In principle I'm -1 on that, but I wasn't on the call so I'm guessing there's good reasons for allowing it?)
There was a problem hiding this comment.
I think there are good reasons for both.
@efiring 's example was: imagine you plot five categories, and then want a line at x=0.5. Thats hard to do if we have locked out x to be only categories.
I'm not 100% convinced we can't come up w/ a way to let the user force the units, but still retain the lockout by default.
There was a problem hiding this comment.
(I wasn't really "working on categoricals", just trying to write some version that's reasonably robust and doesn't do too silly things (which is quite hard) :-))
There was a problem hiding this comment.
But axvline('5') would work and line up with the 5 category right?
There was a problem hiding this comment.
Was there a decision on supporting mixed types in categorical?
There was a problem hiding this comment.
Just strings, according to #10212
There was a problem hiding this comment.
Axvline plots a line at an x in data coordinates. If you want that half-way between two categorical values, you have to be able to specify that location in numeric data coordinates. If you know how categoricals are mapped to numbers, and you are allowed to plot in numeric data coordinates, this is easy. Fundamentally, all plotting is done in floating point coordinates. Plotting something in "units" should not prevent the user from positioning something directly in the numbers to which those units map--and from doing so efficiently.
There was a problem hiding this comment.
Regarding your example, it should be well-documented--if it isn't already--that categoricals map sequentially to integers starting from zero. Knowing that, the user can easily calculate that the point half-way between your '2' and '3' (which more realistically might be 'dogs' and 'cats' or "instrument 872" and "instrument 253") is 1.5.
|
Since the consensus seems to be "always allow numbers on unitised axes", I'm going to provocatively tag this as release critical, since it's a fairly minor change but would massively help plotting non-datetime units. |
|
... Units really need a MEP at some point 😉 But, my opinion still is:
|
|
Decided on call that the use case above can be considered when the use case above is actually needed.... |
I've been playing around trying to get Astropy units to play nicely with Matpltolib recently. One of the things I've realised is that some of the
datetimeplotting capabilities rely on thedatetimeconverter just passing through numbers without attempting to convert them. (the specific example where I came across this is axhline/axvline when the x and y units are different).This PR means custom converters do not have to manually pass through floats (e.g.), but instead it is automatically done at "convert time". I think this makes explicit what @efiring said in this comment about always letting unit-less data being plotted on an axis with units.
Also pinging @jklymak because this probably affects your converter PR.