Proposed change to default log scale tick formatting

[zblz]

Following #4730 and #4867, this is a proposal to change the defaults for the upcoming 2.0 release regarding the default tick label formatting for log-scaled axes. This is not a finished PR, but mean to initiate discussion on whether this is desired as default (if not I still think a similar thing could be worth having as an option).

• A new default formatter (LogFormatterSciNotation) is used as default for all log-scaled axes. This formatter always prints all labels for the bases of the log scale (major ticks) and adds labels to the minor ticks as the axis view limits are made smaller (with a similar logic to LogLocator with subs=None):
  • For less than 3 decades, (1, 3) * base**i are labeled.
  • For less than 2 decades, (1, 2, 5) * base**i are labeled.
  • For less than 1 decade, (1, 2, 4, 7) * base**i are labeled.
• The minor ticks are formatted in scientific notation: $ 3 \times 10^{-2} $
• The base and exponent are omitted if the exponent is between -1 and 1: i.e., 0.1, 0.7, 1, 8, will be formatted as shown (as in #4730, this could be split as an option for all LogFormatter).

Example of this formatter in action:

The main motivation is to improve readability of the axis ticks when log-scaled axis are zoomed-in to less than a few decades, which under the current Formatters leaves only very few labels in the axis. Note that this does not change the formatting whenever more than 3 decades are spanned by the axis view limits.

[mdboom]

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.

[zblz]

@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)?

[mdboom]

@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...

[zblz]

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)

[WeatherGod]

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)
.

[mdboom]

@WeatherGod: I like that idea.

[zblz]

@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.

[WeatherGod]

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)
.

[tacaswell]

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.

[zblz]

@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.

[zblz]

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.

[tacaswell]

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

[zblz]

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.

[zblz]

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).

[mdboom]

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.

[mdboom]

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

[efiring]

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.

[zblz]

@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.

[mdboom]

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

[anntzer]

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.

[WeatherGod]

power-cycling to trigger Travis on latest master...

[efiring]

Is this a bugfix that should go in as a separate PR?

[zblz]

Yes, I ran into this line failing while testing stuff, corrected and commited it by mistake. I'll take it out from this PR.

[tacaswell]

@zblz Would you be able to add a test + an example?

[zblz]

I am working on a test and example. In the meantime, what is the consensus on whether to make this a default or not?

In addition, the PR in #4730 has not been developed further, but I think this PR and that one complement each other nicely in that having several labels that look like 2x10^0, 5x10^0, 10^1 is a lot of clutter compared to 2, 5, 10. Should I reinclude that functionality in this PR?

[zblz]

Tests added, example still missing.

[efiring]

I think it would be better to keep #4730 as a separate PR; you could take it over if @astrofrog doesn't have the time or inclination to finish it.

[jenshnielsen]

This should have a @cleanup decorator to make sure that the plot is closed correctly after the test

[tacaswell]

👍 to adding this and having it turned on by default.

Can you please move the logic if a tick label or an empty string should be emited into the formatter logic (and not add new public API). If there is a performance bottle neck, we should try to deal with that via private caching/memorized private methods.

[zblz]

Can you please move the logic if a tick label or an empty string should be emited into the formatter logic (and not add new public API). If there is a performance bottle neck, we should try to deal with that via private caching/memorized private methods.

I agree that it would be better to keep this sort of logic private, but @mdboom argued some time ago that a Formatter should only format, not decide whether to format or not, which is a fair point.

We could also keep it in Locator and make it private: show_tick_labels -> _show_tick_labels.

[efiring]

Locators place ticks, and a formatter either labels all of them, or none of them (NullFormatter), presently with one exception: the FixedFormatter could be given empty strings. Furthermore, a formatter is called once per tick in Axis.iter_ticks, but that series of calls is preceded by a single call to the formatter's set_locs method, giving it the opportunity to calculate axis-wide parameters once at the start, depending on view interval and the tick locations. ScalarFormatter uses this call to calculate the scale and offset. Logically, LogFormatter should be using this to calculate its d parameter, but instead it is doing it repeatedly in the __call__() method. In practice there will be negligible difference, so leaving it as-is is fine.

My conclusion is that the decision as to which tick locations to label is properly the function of the formatter, and it should be done via the set_locs method. Then the __call__ method checks its pos arg against the sequence calculated in set_locs to decide whether to return an empty string.

[anntzer]

Nice writeup of the behavior of the formatter class.

I feel like this suggests that the API for the Formatter should be rethought. Fundamentally, there should just be one main method (let's call it .format_labels for now) supported by the class: take a list of tick positions returned by a Locator, and return a list of (possibly empty) strings corresponding to the labels. (FuncFormatter, e.g., would call the passed-in function internally.)

I said one main method because there's actually a second method needed: formatting for the cursor (currently .format_data_short), which may or may not depend on the currently labeled ticks as well. Fortunately, we can ensure that .format_labels is always called first, and thus the Formatter can save whatever information it needs at that point.

[zblz]

@efiring: Thanks for the perspective on the formatter classes, very useful! Considering this, I'll move the logic back into the Fomatter, with as much of it as possible in set_locs.

[zblz]

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.

[WeatherGod]

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

[zblz]

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.

[zblz]

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.

[WeatherGod]

power-cycling to test against the latest master.

[WeatherGod]

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

[tacaswell]

backported to v2.x as fb45c4a