On Oct 16, 2009, at 2:59 PM, Ryan May wrote: > On Wed, Oct 14, 2009 at 3:59 PM, John Hunter <jdh2...@gmail.com> > 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. > > 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?
Have you checked scikits.timeseries.lib.plotlib ? We provide some functions that adapt the ticks to the frequency of you base series, but also according to the range of the axes. For example, if you work with a 100-y daily timeseries, you'll have major ticks every 5 years if you plot the whole series, every month if you plot or zoom on one year only, etc. it may be worthwhile to give it a try. I'd be happy to help adapting our code to remove the dependency on scikits.timeseries if needed... ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
