matplotlib-devel Mailing List for matplotlib

[Putting this back on devel]
> 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...
No, I hadn't seen this. And argh!, I wish I had *before* I had coded
up something that met my needs. I hate to see a duplication of effort
and would love to see more of your matplotlib extensions moved into
matplotlib itself. Having said that, I now have a patch that
accomplishes what I want and (now) keeps our unit tests passing. I've
also pretty much expended all the time I have for matplotlib
development in the short term. So if one of the other devs is
interested, awesome. But for me at this point, I can't go study yet
more code when I have something IMO ready to check in.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Wed, Oct 14, 2009 at 3:59 PM, John Hunter <jd...@gm...> 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?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

Thanks.
I can reproduce the bug and the patch looks good.
The patch is applied to the maint. branch and the svn head.
Regards,
-JJ
On Thu, Oct 15, 2009 at 4:30 PM, Stan West <sta...@nr...> wrote:
> Developers:
>
> I happened upon a small bug in which changing the rotation mode of text does
> not take effect until another property is changed:
>
> t = plt.text(0.5, 0.5, 'Lorem ipsum', rotation=-45)
> # rotation_mode defaults to None
> t.set_rotation_mode('anchor')
> plt.draw() # the new rotation mode doesn't take effect
> t.set_rotation(-44)
> plt.draw() # now the angle and rotation mode are updated
>
> This seems to be corrected by adding _rotation_mode to the properties
> handled by get_prop_tup; I've attached a patch for your review.
>
> ------------------------------------------------------------------------------
> 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-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>