matplotlib-devel Mailing List for matplotlib

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

Some time back I asked about initialising a projection in MPL using generic
objects rather than by class name. I created a pull request associated with
this which was responded to fantastically by leejjoon which (after several
months) I have finally got around to implementing. My changes have been added
to the original pull request, which will eventually be obsoleted, but that
doesn't seem to have notified the devel mailing list, therefore I would like
to draw the list's attention to
https://github.com/matplotlib/matplotlib/pull/470#issuecomment-3743543 on
which I would greatly appreciate feedback & ultimately get onto the mpl master.
The pull request in question would pave the way for non string projections so
I thought I would play with how one might go about specifying the location of
theta_0 in a polar plot (i.e. should it be due east or due north etc.). I have
branched my changeset mentioned in the pull request above and implemented
a couple of ideas, although I am not proposing that these changes go any
further at this stage (I would be happy if someone wants to run with
them though):
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))
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.
Hope that makes sense.
Many Thanks,

I'm trying to understand how the TransformedPath mechanism is working
with only limited success, and was hoping someone could help.
I have a non-affine transformation defined (subclass of
matplotlib.transforms.Transform) which takes a path and applies an
intensive transformation (path curving & cutting) which can take a
little while, but am able to guarantee that this transformation is a
one off and will never change for this transform instance, therefore
there are obvious caching opportunities.
I am aware that TransformedPath is doing some caching and would really
like to hook into this rather than rolling my own caching mechanism
but can't q
uite figure out (the probably obvious!) way to do it.
To see this problem for yourself I have attached a dummy example of
what I am working on:
import matplotlib.transforms
class SlowNonAffineTransform(matplotlib.transforms.Transform):
 input_dims = 2
 output_dims = 2
 is_separable = False
 has_inverse = True
 def transform(self, points):
 return matplotlib.transforms.IdentityTransform().transform(points)
 def transform_path(self, path):
 # pretends that it is doing something clever & time consuming,
but really is just sleeping
 import time
 # take a long time to do something
 time.sleep(3)
 # return the original path
 return matplotlib.transforms.IdentityTransform().transform_path(path)
if __name__ == '__main__':
 import matplotlib.pyplot as plt
 ax = plt.axes()
 ax.plot([0, 10, 20], [1, 3, 2], transform=SlowNonAffineTransform()
+ ax.transData)
 plt.show()
When this code is run the initial "show" is slow, which is fine, but a
simple resize/zoom rect/pan/zoom will also take a long time.
How can I tell mpl that I can guarantee that my level of the transform
stack is never invalidated?
Many Thanks,