Skip to content

Keep explicit ticklabels in sync with ticks from FixedLocator #17266

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
May 11, 2020

Conversation

efiring
Copy link
Member

@efiring efiring commented Apr 29, 2020

PR Summary

Using FixedFormatter with ticks from FixedLocator causes mislabeled ticks if the nbins kwarg of the locator triggers subsampling. This PR addresses that in the common case where the Axis.set_ticklabels method is used, by setting a FuncFormatter instead of a FixedFormatter.

Closes #11937.

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

efiring added 5 commits April 28, 2020 15:25
When explicitly setting the tick locations and then the corresponding
tick labels, a FixedLocator is used for the locations.  It has an nbins
argument that can trigger subsampling.  Previously, tick labels were
made by FixedFormatter and based on position, not value, so subsampling
caused a mismatch, yielding incorrect tick labels.  This is changed to
use FuncFormatter with a function to look up the label by value,
ignoring the position.
@QuLogic
Copy link
Member

QuLogic commented Apr 30, 2020

xref #15005

ticks = self.get_major_ticks()

self._update_ticks()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you really need to call update_ticks() here? and if you do, shouldn't this go before get_major_ticks()/get_minor_ticks()? (otherwise you'd be possibly invalidating ticks even before iterating on them...)

@@ -379,18 +379,28 @@ class FuncFormatter(Formatter):

The function should take in two inputs (a tick value ``x`` and a
position ``pos``), and return a string containing the corresponding
tick label.
tick label. The function may take additional arguments that are
supplied upon instantiation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"appended" (they go after x, pos, not before).

else self.get_major_locator())
if isinstance(locator, mticker.FixedLocator):
tickd = {loc: lab for loc, lab in zip(locator.locs, ticklabels)}
formatter = mticker.FuncFormatter(self._format_with_dict, tickd)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure whether we want or not to make this extension to the FuncFormatter API (perhaps?) but if not, I think you can get away with

@staticmethod
def _format_with_ticks(tickd, x, pos): ...  # move tickd to first

...

formatter = FuncFormatter(functools.partial(self._format_with_ticks, tickd))

as the partial object will stay picklable (I think this is more or less the canonical way to bind some arguments while keeping picklability).

@efiring
Copy link
Member Author

efiring commented Apr 30, 2020

@anntzer I think I have addressed all your points. I had tried using partial earlier, but hadn't gotten it right. _update_ticks is overkill, but some of its function is essential to passing the pre-existing test_axes.py::test_set_get_ticklabels, so I put the needed parts directly into set_ticklabels.

for tick_label, tick in zip(ticklabels, ticks):
for pos, (loc, tick) in enumerate(zip(locs, ticks)):
tick.update_position(loc)
tick_label = formatter(tick._loc, pos)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is tick._loc just loc? or not?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point they should be identical; but yes, it might look better and be slightly more efficient with loc.

Copy link
Contributor

@anntzer anntzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just one question, and needs ci to pass

@efiring efiring added this to the v3.3.0 milestone May 4, 2020
Comment on lines +4459 to +4461
ax.xaxis.set_ticks(np.arange(10) + 0.1)
ax.locator_params(nbins=5)
ax.xaxis.set_ticklabels([c for c in "bcdefghijk"])
Copy link
Member

@QuLogic QuLogic May 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting these together would make it a bit clearer:

Suggested change
ax.xaxis.set_ticks(np.arange(10) + 0.1)
ax.locator_params(nbins=5)
ax.xaxis.set_ticklabels([c for c in "bcdefghijk"])
ax.xaxis.set(ticks=np.arange(10) + 0.1),
ticklabels=[c for c in "bcdefghijk"])
ax.locator_params(nbins=5)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of set here would work only by accident, because the kwargs are sorted in inverse order, so that set_ticks will be called before set_ticklabels. I will stick with the individual function calls.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the closest analogue to plt.xticks(locs, labels), so if you're saying it might be broken, then I think that's not good. Especially given the recent tweet about .set()...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't use twitter and haven't seen the tweet.

I'm not saying the behavior is currently broken, just that it works in this case (I think--I haven't tried it) because the names are sorted in inverse order, and the "s" in "ticks" makes it sort before the first "l" in "ticklabels". It's an accident. It might be better to make it explicit by adding a "ticks" entry to Artist._prop_order to boost its priority. The _prop_order dict provides a way of setting priority at a higher level than the alphanumeric sort. Presently, it serves only to give 'color' low priority, so it is executed last.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The is the tweet that @story645 mentioned.

For users, working by accident and working by design are the same thing. So I meant if this PR breaks it, that would not be good. However, it doesn't, so we're fine, even if it's working by accident right now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'll take advantage of this to point to #16328 :)

@jklymak
Copy link
Member

jklymak commented May 4, 2020

As discussed on the call, it would be good if there was a lock on set_ticklabels that said it had to be the same length as set_ticks.

@@ -1635,6 +1635,11 @@ def set_ticklabels(self, ticklabels, *, minor=False, **kwargs):
locator = (self.get_minor_locator() if minor
else self.get_major_locator())
if isinstance(locator, mticker.FixedLocator):
if len(locator.locs) != len(ticklabels):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

L 1620 probably needs something like "Number of labels must be the same as number of ticks set by set_ticks or the FixedLocator"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a reference to set_ticks.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That helps, but I mean above in the Parameter description. Its a bit unclear as to what is meant by "tick labels". maybe:

ticklabels : sequence of str or of `.Text`\s
            List of texts for tick labels, one for each tick defined in `.axis.set_ticks`.

@efiring
Copy link
Member Author

efiring commented May 4, 2020

Adding the check for a match turned up a blatant error in our image_annotated_heatmap example. I wonder how many such mismatches are out in the wild, and not as obvious as in our example? We'll see...

@efiring
Copy link
Member Author

efiring commented May 5, 2020

The appveyor failure appears to be caused by the crash of the VM running the test.

@efiring
Copy link
Member Author

efiring commented May 5, 2020

@jklymak I have augmented the ticklabels kwarg description in the docstring, and updated a statement in the API docs about set_ticks and set_ticklabels.

@jklymak
Copy link
Member

jklymak commented May 6, 2020

I'll leave here since there is a mailing list discussion, but anyone may merge after that is done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Limiting ticks on colorbar axes falsify tick labels.
5 participants