AutoDateFormatter/AutoDateLocator

Hi,

Anybody know what the status of AutoDateLocator/AutoDateFormatter in
matplotlib.dates are? They work and seem reasonably well documented.
However, they do not show up in our online docs:

http://matplotlib.sourceforge.net/api/dates_api.html

They show up in the inheritance graph, but are not mentioned elsewhere
in the page and in fact have no link from the image. They're also not
present in the __all__ in the dates module. If this is just an
oversight, what do I need to do to make the classes show up in the
docs?

Ryan

···

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Most likely this is just due to an oversight in the __all__ so just
add it there in the branch and it should get picked up next time we
build the docs

JDH

···

On Wed, Oct 14, 2009 at 2:16 PM, Ryan May <rmay31@...149...> wrote:

Hi,

Anybody know what the status of AutoDateLocator/AutoDateFormatter in
matplotlib.dates are? They work and seem reasonably well documented.
However, they do not show up in our online docs:

http://matplotlib.sourceforge.net/api/dates_api.html

They show up in the inheritance graph, but are not mentioned elsewhere
in the page and in fact have no link from the image. They're also not
present in the __all__ in the dates module. If this is just an
oversight, what do I need to do to make the classes show up in the
docs?

Done. I also added them to the module-level docstring.

Along these lines, I was trying to make use of AutoDateLocator, and as
far as I can tell, there's no way to customize its behavior right now.
So when trying to use this for doing major and minor ticks, there's
no difference. It looks like in the get_locator() method of
AutoDateLocator, numticks is used to control what types of ticking
(yearly, monthly) is used. Would it make sense to have this as an
attribute of self so that the user can tweak it? Or maybe go to:

1) minticks (instead of numticks) which specifies a minimum number of
ticks that are desired,
     to select yearly, monthly, etc.
2) maxticks, which specifies a maximum number of ticks, which can be
used to calculate the interval
     (every N'th month). Right now, the rules for selecting this are hard coded.

I'm interested in hacking this up. But since you wrote the code, I
want to make sure that going this direction makes sense to you.

Ryan

···

On Wed, Oct 14, 2009 at 3:08 PM, John Hunter <jdh2358@...149...> wrote:

Most likely this is just due to an oversight in the __all__ so just
add it there in the branch and it should get picked up next time we
build the docs

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I don't have a strong opinion on this -- making it more customizable
is a good thing -- this came up at scipy as well, where I contributed
a patch to make the AutoDateFormatter a little more customizable by
exposing a scaled dictionary mapping the scale to a format string. As
long as the extension to the AutoDateLocator preserves the core
functionality, I say have at it.

JDH

···

On Wed, Oct 14, 2009 at 3:47 PM, Ryan May <rmay31@...149...> wrote:

On Wed, Oct 14, 2009 at 3:08 PM, John Hunter <jdh2358@...149...> wrote:

Most likely this is just due to an oversight in the __all__ so just
add it there in the branch and it should get picked up next time we
build the docs

Done. I also added them to the module-level docstring.

Along these lines, I was trying to make use of AutoDateLocator, and as
far as I can tell, there's no way to customize its behavior right now.
So when trying to use this for doing major and minor ticks, there's
no difference. It looks like in the get_locator() method of
AutoDateLocator, numticks is used to control what types of ticking
(yearly, monthly) is used. Would it make sense to have this as an
attribute of self so that the user can tweak it? Or maybe go to:

1) minticks (instead of numticks) which specifies a minimum number of
ticks that are desired,
to select yearly, monthly, etc.
2) maxticks, which specifies a maximum number of ticks, which can be
used to calculate the interval
(every N'th month). Right now, the rules for selecting this are hard coded.

I'm interested in hacking this up. But since you wrote the code, I
want to make sure that going this direction makes sense to you.

Here's a patch that implements the ideas I have. To the best of my
ability, it preserves the same behavior as before, it just opens it up
to configuration by the user instead of being hard-coded. It adds:

1) Configuring the minimum number of ticks, which determines whether
to do yearly, monthly, etc. ticking

2) Configuring the maximum number of ticks, which is used to select
what interval of ticking to use. This is actually
done on a per-frequency basis. This helps to keep in line with
previous behavior and is useful for keeping tick spacing in line with
what the label would be for a given frequency. The user can also
simply pass an integer that
gives the maximum for all frequencies.

3) A dictionary of intervals corresponding to each frequency. This
keeps the previous functionality of appropriate intervals for each
frequency, but also opens it up to user configuration.

4) Optional ticking on multiples of the interval. Previously, if you
were ticking with, say, 10 minute intervals, and the range happened to
start at 33 minutes, you'd get ticks at 33, 43, 53, etc. With this
flag set, the ticks instead end up at 40, 50, 0, 10, etc.

I'd appreciate anyone looking this over for any glaring problems
before I check this in. I've done my best to preserve old
functionality, though I'm still working on getting the unit tests to
run here. It also passes my own testing here when I fiddle with the
new knobs that have been exposed. My one question is: how important
is keeping API compatibility? The constructor tries to follow the
convention of the rest of the module (tz is last or nearly so), but
this breaks compatibility (where tz was the only argument). Also, to
me, it would be nice to tick multiples of the interval by default.

Thoughts?

Ryan

autodatelocator.diff (8.53 KB)

···

On Wed, Oct 14, 2009 at 3:59 PM, John Hunter <jdh2358@...149...> wrote:

I don't have a strong opinion on this -- making it more customizable
is a good thing -- this came up at scipy as well, where I contributed
a patch to make the AutoDateFormatter a little more customizable by
exposing a scaled dictionary mapping the scale to a format string. As
long as the extension to the AutoDateLocator preserves the core
functionality, I say have at it.

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States