Thanks for doing this work. On 02/03/2012 11:40 AM, Phil Elson wrote: > Currently, one can set the theta_0 of a polar plot with: > > ax = plt.axes(projection='polar') > ax.set_theta_offset(np.pi/2) > ax.plot(np.arange(100)*0.15, np.arange(100)) > > But internally there are some nasties going on (theta_0 is an attribute on the > axes, the transform is instantiated from within the axes and is given the axes > that is instantiating it, which is all a bit circular). I have made a branch > (https://github.com/PhilipElson/matplotlib/compare/master...polar_fun) which > alleviates the axes attribute issue and would allow something like: > > polar_trans = mpl.transforms.Polar.PolarTransform(theta_offset=np.pi/2) > ax = plt.axes(projection=polar_trans) > ax.plot(np.arange(100)*0.15, np.arange(100))
I agree that the canonical copy of theta_offset should probably live in the transform and not the PolarAxes. However, an important feature of the current system that seems to be lost in your branch is that the user deals with Projections (Axes subclasses) which bring together not only the transformation of points from one space to another, but the axes shape and tick placement etc., and they also allow for changing everything after the fact. The Transformation classes, as they stand now, are intended to be an implementation detail hidden from the user. I'm not quite sure what the above lines are meant to do. matplotlib.transforms doesn't have a Polar member -- matplotlib.projections.polar.Polar does not have a PolarTransform member (on master or your polar_fun branch). Even given that, I think the user should be specifying a projection, not a transformation, to create a new axes. There is potential for confusion that some transformations will allow getting a projection out and some won't (for some it doesn't even really make sense). > > Or, I have added a helper class which also demonstrates the proposed: > > non-string change: > ax = plt.axes(projection=Polar(theta0=90)) > ax.plot(np.arange(100)*0.15, np.arange(100)) > > As I said, I am not proposing these changes to the way Polar works at this > stage, but thought it was worth sharing to show what can be done once > something similar to the proposed change gets on to mpl master. > This makes more sense to me. It doesn't appear to allow for setting the theta0 after the fact since Polar doesn't propagate changes along to the PolarAxes object that it created and set_theta_offset has been removed from PolarAxes. Cheers, Mike ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
