Skip to content

ENH: Change default Autodatelocator *interval_multiples* #9801

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 1 commit into from
Jul 4, 2018

Conversation

jklymak
Copy link
Member

@jklymak jklymak commented Nov 16, 2017

PR Summary

OK, AutoDateLocator returned "not-nice" tick labels:

old

So like a dummy, I went and tried to implement better ticks that snapped to the tick intervals (10 minutes in this case). Then this morning I reread the code and found that lo-and-behold, it has a flag for this (interval_multiples=False)

I don't see the rationale behind the default being interval_multiples=False. Other than that it will break some existing tests, and its a breaking change. The resulting ticks look far better, and are much more amenable to panning. Tick locators are obscure enough that I never use them except in extremis, so expecting normal users to change options in them just to get something that looks somewhat rational is not putting our best foot forward.

new

PR Checklist

  • Regularize day intervals to include first of month
  • Has Pytest style unit tests
  • Code is PEP 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

@dstansby dstansby added this to the v2.2 milestone Nov 16, 2017
@jklymak
Copy link
Member Author

jklymak commented Nov 16, 2017

As a further suggestion for discussion, I'd also consider changing the interval for 14 days from a strict 14 days to first of month, 15th of month. We could consider regularizing all the daily intervals to be sure they fall on month boundaries.

The above fails the obvious image comparison tests...

@jklymak
Copy link
Member Author

jklymak commented Nov 17, 2017

Is their appetite for changing the default formatters as well, particularly for dates:

I'd strip repeated entries. i.e. for "Feb 01", "Feb 08", "Feb 15", I'd strip "Feb" from the second two labels. i.e. only show month name when day == 1. Similarly, only show years when month == 1 (and day==1). That would make tick labels much more compact.

To make that work properly, the rcParams for the date formaters (i.e. rcParams['date.autoformat.day']) may need to change their meaning, so this would be a breaking change, the problem being that we would need to know how to parse the strings to strip information, and allowing the user to input arbitrary formatting information would make that hard.

@tacaswell
Copy link
Member

I am open to this so long as there is clear and easy instructions on how to get old behavior back.

@jklymak
Copy link
Member Author

jklymak commented Nov 19, 2017

I'll work on this.

I was also thinking a tutorial on how to label axes would be useful. I think that info is in a bunch of examples all over the place, but not explained systematically. @tacaswell I only hesitate because I keep hearing rumours that you have a documentation plan. If so, I can wait for that, and help contribute to that.

@tacaswell
Copy link
Member

There is a plan to make a plan. In any outcome, the more content we have up front the less we have to write later (even if we re-organize or re-word it a bit).

If matching the current API is too annoying, making a new formatter / locator (but not using them by default yet) is a reasonable course of action as well.

@jklymak
Copy link
Member Author

jklymak commented Mar 24, 2018

OK, this PR makes interval_multiples the default. It also changes the tick locator for months to be 1 and 15 if the 14-day locator is called for.

@jklymak jklymak changed the title WIP: FIX: Change default Autodatelocator *interval_multiples* ENH: Change default Autodatelocator *interval_multiples* Mar 24, 2018
@jklymak jklymak force-pushed the fixdateticklocator branch 2 times, most recently from be9c155 to 3356826 Compare March 25, 2018 04:12
byranges[i] = self._byranges[i][::interval]
if i == 2 and interval == 14:
# special case for monthday: Just tick 1 and 15:
byranges[i] = range(1, 16, 14)
Copy link
Member

Choose a reason for hiding this comment

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

Could this not simply be [1, 15] to make it more clear?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep!

@@ -319,7 +319,8 @@ def test_empty_date_with_year_formatter():

def test_auto_date_locator():
def _create_auto_date_locator(date1, date2):
locator = mdates.AutoDateLocator()
# we prob. should eventually have a test w/ interval_multiples=True
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this comment is out of date.

@@ -13,12 +13,12 @@
# set this to True. It will download and build a specific version of
# FreeType, and then use that to build the ft2font extension. This
# ensures that test images are exactly reproducible.
#local_freetype = False
local_freetype = True
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks extraneous.

@@ -1338,7 +1341,11 @@ def get_locator(self, dmin, dmax):
self._freq = freq

if self._byranges[i] and self.interval_multiples:
byranges[i] = self._byranges[i][::interval]
print(self._byranges[i])
Copy link
Contributor

Choose a reason for hiding this comment

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

print() needs to go before merging.

@@ -1234,6 +1234,9 @@ def __init__(self, tz=None, minticks=5, maxticks=None,
MICROSECONDLY: [1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 2000,
5000, 10000, 20000, 50000, 100000, 200000, 500000,
1000000]}
if interval_multiples:
self.intervald[3] = [1, 2, 4, 7, 14, 21]
Copy link
Member

@efiring efiring Jul 3, 2018

Choose a reason for hiding this comment

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

Instead of [3] do you mean [DAILY]?

@efiring
Copy link
Member

efiring commented Jul 3, 2018

I agree with the basic idea here of using "nice" values by default. It would be good to get this into 3.0.

@jklymak jklymak force-pushed the fixdateticklocator branch 2 times, most recently from b755888 to 44c0bbb Compare July 3, 2018 03:16
@jklymak
Copy link
Member Author

jklymak commented Jul 3, 2018

Reviews addressed, squashed and rebased, API note added (that may need CI to test if it rendered correctly).

Copy link
Member

@efiring efiring left a comment

Choose a reason for hiding this comment

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

Looks good.

@@ -1234,6 +1234,9 @@ def __init__(self, tz=None, minticks=5, maxticks=None,
MICROSECONDLY: [1, 2, 5, 10, 20, 50, 100, 200, 500, 1000, 2000,
5000, 10000, 20000, 50000, 100000, 200000, 500000,
1000000]}
if interval_multiples:
self.intervald[DAILY] = [1, 2, 4, 7, 14, 21]
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps just curiosity, but why have this substitution of 4 for 3 in this case, and not in general? And isn't 21 a rather strange option? It is inconsistent with the docstring.

Copy link
Member

Choose a reason for hiding this comment

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

To clarify, the 21 option is present in the current code as well as in the line cited above, so the inconsistency predates your PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I don't know why the 21 is in there. I left it in as possibly some weird edge case, but I don't see how it'd happen.

3 vs 4?

3: 1, 4,..., 28, 31, 1
4: 1, 5, ... 25, 29, 1

So except for Feb leap years it avoids an awkward cross-month transition.

Copy link
Member Author

Choose a reason for hiding this comment

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

added a couple of comments...

@jklymak
Copy link
Member Author

jklymak commented Jul 3, 2018

This is ready for a second review.... Relatively simple change that I think makes the date locators much better...

@jklymak jklymak force-pushed the fixdateticklocator branch 2 times, most recently from 1e609db to 7c994b8 Compare July 3, 2018 23:29
Also make monthly byranges be 1 and 15
@jklymak jklymak force-pushed the fixdateticklocator branch from 7c994b8 to 0337883 Compare July 4, 2018 19:08
@jklymak
Copy link
Member Author

jklymak commented Jul 4, 2018

squashed...

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.

8 participants