It seems like you've combined the logic of whether to display a tick (which is usually the job of a Locator subclass) with the logic of how to display a tick (which is usually the job of a Formatter subclass). Any reason why you didn't separate concerns like all the other Locator/Formatters?

Other than that, I see this as very useful, though we'll have to determine whether or not it's a good idea to change the default behavior.

@mdboom: For the case of log-scaled axis, it is nice to show all minor ticks to make it clear that the scaling is logarithmic, but we obviously do not want to label all minor ticks. The current default is show all minor ticks and label none. I had to combine them so that all minor ticks are shown, but not all of them labeled. I understand its a departure from how other Locator/Formatter work, but I did not see a different way to do it.

EDIT: I could not find it, but is there any other Locator/Formatter where this is done (i.e., only some of the shown minor or major ticks are labeled)?

@zblz: I understand the problem better now. I think it could lead to confusion that the formatter chooses not to format some ticks, particularly if using an explicit locator or something. However, as you say, I can't think of a better way right now. That's all the more argument to keep the default for log scales as something that formats everything. Let me think on it for a bit -- maybe there is a better way, perhaps by adding the ability to have separate locators for ticks and text...

Separate locators would be ideal for this case, but it would increase the complexity of the tick logic in Axis. In addition, the process to change tick format and location is not the easiest thing for a user (needing additional imports from ticker, and discovering the names and options of the Locator/Formatter a bit difficult), so adding another Locator might complicate things even further. I don't really have a better option, though.

By the way, I adapted this logic of not showing some labels from the only way I knew how to produce this previously, which was to use horrible, horrible ad-hoc labels like this:

ax.xaxis.set_ticklabels([r'$2\times10^4$','','',r'$5\times10^4$','','','','', 
        r'$2\times 10^4$','','',r'$5\times10^4$','','','','',
        r'$2\times 10^5$','','',r'$5\times10^5$','','','','',
        ],minor=True)

What if a locator could signal whether the location is intended for
tickline, ticklabel, or both (default)?

On Tue, Oct 6, 2015 at 1:58 PM, Victor Zabalza notifications@github.com
wrote:

Separate locators would be ideal for this case, but it would increase the
complexity of the tick logic in Axis and might be quite confusing for the
user. In addition, the process to change tick format and location is not
the easiest thing for a user (needing additional imports from ticker, and
discovering the names and options of the Locator/Formatter a bit
difficult), so adding another Locator might complicate things even further.
I don't really have a better option, though.

—
Reply to this email directly or view it on GitHub
#5161 (comment)
.

@WeatherGod: I like that idea.

@WeatherGod: It sounds good, but I have no idea of how to even begin to implement that from a glance at ticker.py and axis.py. In Axis all ticks have an associated location and label, so if we dissociate the tick location and the label location we might need a lot of refactoring.

If one works from the assumption that all ticklabels must have a tickline,
then it is possible to simply have a blank ticklabel where a location is
only intended for a tickline. Then, it just becomes a matter of how to
signal that from the locator to Axis. That is the hard part, but probably
doable.

On Tue, Oct 6, 2015 at 2:15 PM, Victor Zabalza notifications@github.com
wrote:

@WeatherGod https://github.com/WeatherGod: It sounds good, but I have
no idea of how to even begin to implement that from a glance at ticker.py
and axis.py. In Axis all ticks have an associated location and label, so
if we dissociate the tick location and the label location we might need a
lot of refactoring.

—
Reply to this email directly or view it on GitHub
#5161 (comment)
.

The Formatter objects are called with the signature (tick_location, tick_number) where iirc tick_number is either None or the integer count of ticks along the axis (with possibly some off-by-one bugs due to a clipped left most tick). It may be possible to write a clever enough Formatter to take this into account.

@tacaswell: But if whether we return a label depends on tick_number then we have the same problem as looking at the parent axis: the decision of whether to show a label is left to the Formatter rather than the Locator, which is what @mdboom objected to initially.

Ok, I tried to move the print logic from the formatter to the locator following @WeatherGod's suggestion, and now the locator must return two arrays: the location for the ticks and whether each tick should be labeled. This means a change to all the __call__ functions of the locators: I have modified it only for LogLocator as a proof-of-concept, but they could also be wrapped so that if they only return one array, the second defaults to all True.

re-milestoned this for 2.1 as this is not just changing some parameters.

Change of mind right after pushing: I moved the logic on whether to show the labels to an different function than the __call__ so that this new function (show_tick_label) can be defined in the parent Locator class. In this way, locator classes that want labels on all their ticks don't have to be modified.

To keep the focus of this PR, I have removed the functionality to plot (1e-1, 1e0, 1e1) as 0.1 1 10, because this should be covered by #4730 in LogFormatterMathtext. This allows LogFormatterSciNotation to be a subclass of LogFormatterMathtext with only the non-decade ticks formatted differently (and any changes to LogFormatterMathtext in #4730 will propagate here).

Thanks. I think the separation of Locator/Formatter is much better now. One further refinement though -- I don't think we necessarily require that a Locator inherits from LocatorBase (matplotlib's built-in ones all do, but third-party ones may not). So we should be robust to the possibility that show_tick_label may not be present and handle the default behavior accordingly.

Thanks. I'm happy to merge this once the test failure is resolved.

1. I presume this needs a "what's new" entry.
2. Is this still a default change, or is it now just a new Formatter that one can choose? I think it is the latter. Can the PR title be changed accordingly, before or after a merge?
3. I can see the usefulness of this, particularly for interactive use when zooming, as noted at the start of the PR, but it could also cause clutter and messiness, particularly when using multiple subplots. One thing that might help would be to make the thresholds for labeling minor ticks into settable parameters.
   Suggestion 3 need not hold up this PR; it could be a future improvement, if needed. I suspect it would fit in with the move to traitlets.

@efiring:

2. It is both a new Formatter and a change in how Locators can specify where to put labels. I think it would make a good default, but if you think it should be considered separately, I can make this PR only about adding the functionality and another PR about whether to make it default (i.e., chaning the default minor tick formatter from NullFormatter to LogFormatterSciNotation) when setting a log scale.
3. Yes, it does add a bit of horizontal width to the y-axis labels as compared to labeling only the bases, so could be a problem in close multiple plots. It can always be avoided by setting the minor formatter to NullFormatter.

We could consider the default change as part of 2.0. Not promising anything, but that's a good window of opportunity for it.

I would like to suggest re-milestoning this (or the original issue, #4867), for 2.0. When round-number limits were the default, a log-scale axis would by default be expanded to initially cover at least one (integer) decade, and thus have at least two labeled ticks (at the two ends). With the switch to margins-based limits, it is now possible for axes to default to having no labels at all (e.g. semilogy([.2, .9])) which is (IMO) very bad.

Edit: Changed the milestone, but feel free to discuss if you disagree.

I have moved the logic back into the formatter classes, choosing to add it into LogFormatter rather than LogFormatterSciNotation as all log formatters could benefit from it (note though that all of them except for LogFormatterSciNotation have labelOnlyBase=True as default, so this change will not affect them if used with default parameters).

I have also added back LogFormatterSciNotation as the default formatter for log-scaled axes.

Getting a bunch of errors. Somehow, zeros are getting down into math.log(). Got some image comparison failures, too.

I have fixed the error on symlog axes, which where sending values vmin <= 0 to math.log. I also updated the baseline images for the test_axes.log_scale test.

The remaining error on matplotlib.tests.test_backend_ps.test_savefig_to_stringio_eps_afm will be fixed by PR #6898, so that should be merged before this PR.

power-cycling to test against the latest master.

This is passing and is milestoned for v2.0. I don't know who is the one to approve the remaining style changes.

backported to v2.x as fb45c4a