matplotlib-devel Mailing List for matplotlib

Eric Firing wrote:
> Michael Droettboom wrote:
>> That's right, Eric. I think having resolution be an attribute of the 
>> artist (and not the projection) is the "path" of least resistance 
>> here. To clarify, however, the interpolation (more specifically, 
>> whether to interpolate) should remain a function of the projection, 
>> not the path. That's the important point that lead to it ending up 
>> in the wrong place in the first place. If we aim to keep the 
>> generalization that all grid lines are the same kind of object 
>> regardless of the projection, and therefore set a high resolution 
>> parameter on all the grid lines, we wouldn't want this to slow down 
>> the standard rectilinear axes. As long as the standard axes don't 
>> obey the parameter, then would should be fine. It's somewhat 
>> confusing, but I also am seeing this the resolution parameter on 
>> artists as more of an implementation detail than a public API. If 
>> someone wants to interpolate their data, IMHO that should be the 
>> user's responsibility, since they know the best way to do it. This 
>> functionality isn't really about data points, IMHO.
>
> Mike,
>
> Thanks for taking care of this so quickly.
>
> Although I agree that _interpolation_steps is a low-level, 
> implementation-dependent attribute (which might not be the right 
> specification if interpolation were changed to take advantage of 
> Bezier curves, for example), I think that some sort of 
> "follow_curvilinear_coordinates" public Artist attribute would be 
> desirable. For example, one might want to plot a set of arcs, or 
> arc-shaped patches (warped rectangles) on a polar plot. It would be 
> nice to be able to do this using lines, line collections, rectangle 
> patches, or rectangle collections, by adding a single kwarg to set 
> that attribute. Then it would be up to each Artist to use that 
> attribute to set _interpolation_steps or whatever implementation 
> mechanism is in place. Possibly it does not make sense as a general 
> Artist attribute but should be restricted to a subset, but it is 
> probably simpler to put it at the Artist level and then selectively 
> apply it. 
Agreed with all of the above -- all the infrastructure is now in place 
to do this. I was most concerned with fixing the bug (seeming lack of 
gridlines) first, and then getting this improvement in later (probably 
not till next week).
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> That's right, Eric. I think having resolution be an attribute of the 
> artist (and not the projection) is the "path" of least resistance here. 
> To clarify, however, the interpolation (more specifically, whether to 
> interpolate) should remain a function of the projection, not the path. 
> That's the important point that lead to it ending up in the wrong place 
> in the first place. If we aim to keep the generalization that all grid 
> lines are the same kind of object regardless of the projection, and 
> therefore set a high resolution parameter on all the grid lines, we 
> wouldn't want this to slow down the standard rectilinear axes. As long 
> as the standard axes don't obey the parameter, then would should be 
> fine. It's somewhat confusing, but I also am seeing this the resolution 
> parameter on artists as more of an implementation detail than a public 
> API. If someone wants to interpolate their data, IMHO that should be 
> the user's responsibility, since they know the best way to do it. This 
> functionality isn't really about data points, IMHO.
Mike,
Thanks for taking care of this so quickly.
Although I agree that _interpolation_steps is a low-level, 
implementation-dependent attribute (which might not be the right 
specification if interpolation were changed to take advantage of Bezier 
curves, for example), I think that some sort of 
"follow_curvilinear_coordinates" public Artist attribute would be 
desirable. For example, one might want to plot a set of arcs, or 
arc-shaped patches (warped rectangles) on a polar plot. It would be 
nice to be able to do this using lines, line collections, rectangle 
patches, or rectangle collections, by adding a single kwarg to set that 
attribute. Then it would be up to each Artist to use that attribute to 
set _interpolation_steps or whatever implementation mechanism is in 
place. Possibly it does not make sense as a general Artist attribute 
but should be restricted to a subset, but it is probably simpler to put 
it at the Artist level and then selectively apply it.
Eric
> 
> The more difficult change seems to be being backward compatible about 
> the Polar plot accepting a resolution argument. I'm not even certain 
> that it's worth keeping, since as you suggest, it makes more sense for 
> it to be a property of the artist. I'd almost prefer to raise a warning 
> if the user provides a resolution argument (other than 1) to Polar 
> rather than trying to make it work. Is anyone actually using it, other 
> than to set it to 1 on 0.98.x versions?
> 
> I should have some time to work on this today.
> 
> Mike
> 
> Eric Firing wrote:
>> Eric Firing wrote:
>>> Jae-Joon Lee wrote:
>>>> The default resolution (which is used to interpolate a path in polar
>>>> coordinate) has change to 1 at some point. And because of this, a
>>>> radial grid becomes a 0-length line. Increasing the resolution will
>>>> bring back your gridlines.
>>>
>>> This is not the right solution, though. There was a reason for the 
>>> change in default resolution to 1--it gives the expected behavior for 
>>> plotting a line between two points in polar coordinates--and it is 
>>> not going back. The inability to set resolution on a per-artist 
>>> basis is a serious problem that doesn't seem to have a simple 
>>> solution. Until one can be found, some sort of special case handling 
>>> will be needed for the radial grid lines.
>>>
>>> Eric
>>
>>
>> Expanding on this: it looks like a possible solution is to attach a 
>> new "resolution" attribute to the Path object. This would ordinarily 
>> be None, but could be set to another value when the Path is created 
>> (or later). Then the PolarTransform.transform_path method (and the 
>> same in other curvilinear projections) could use that value, if not 
>> None, to control interpolation. Some additional changes would be 
>> needed to apply this to the radial gridlines.
>>
>> Now it is not clear to me that resolution should be an attribute of 
>> the PolarAxes at all--the interpolation is done by a path method, so 
>> that method doesn't need a resolution parameter at all if resolution 
>> is a Path attribute. Except for backwards compatibility. Comments, 
>> Mike?
>>
>> I can't implement it right now, but if no one comes up with a better 
>> solution, or wants to implement something like this one, then I can do 
>> it in a day or two.
>>
>> (Of course, I may not be seeing a stumbling block.)
>>
>> Eric
> 

Thanks. Should be fixed now in SVN.
Mike
Andrew Straw wrote:
> Hi Mike, I think you introduced a regression in r7131. I picked this up
> using "python backend_driver.py agg":
>
> examples/api$ python custom_projection_example.py
> Traceback (most recent call last):
> File "custom_projection_example.py", line 440, in <module>
> subplot(111, projection="hammer")
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/pyplot.py",
> line 645, in subplot
> a = fig.add_subplot(*args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/figure.py",
> line 690, in add_subplot
> a = subplot_class_factory(projection_class)(self, *args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 7802, in __init__
> self._axes_class.__init__(self, fig, self.figbox, **kwargs)
> File "custom_projection_example.py", line 35, in __init__
> Axes.__init__(self, *args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 525, in __init__
> self.set_figure(fig)
> File "/usr/local/lib/python2.6/dist-packages/matplotlib/axes.py", line
> 597, in set_figure
> self._set_lim_and_transforms()
> File "custom_projection_example.py", line 94, in _set_lim_and_transforms
> self.transProjection = self.HammerTransform(self.RESOLUTION)
> TypeError: __init__() takes exactly 1 argument (2 given)
>
>
> Michael Droettboom wrote:
> 
>> That's right, Eric. I think having resolution be an attribute of the 
>> artist (and not the projection) is the "path" of least resistance here. 
>> To clarify, however, the interpolation (more specifically, whether to 
>> interpolate) should remain a function of the projection, not the path. 
>> That's the important point that lead to it ending up in the wrong place 
>> in the first place. If we aim to keep the generalization that all grid 
>> lines are the same kind of object regardless of the projection, and 
>> therefore set a high resolution parameter on all the grid lines, we 
>> wouldn't want this to slow down the standard rectilinear axes. As long 
>> as the standard axes don't obey the parameter, then would should be 
>> fine. It's somewhat confusing, but I also am seeing this the resolution 
>> parameter on artists as more of an implementation detail than a public 
>> API. If someone wants to interpolate their data, IMHO that should be 
>> the user's responsibility, since they know the best way to do it. This 
>> functionality isn't really about data points, IMHO.
>>
>> The more difficult change seems to be being backward compatible about 
>> the Polar plot accepting a resolution argument. I'm not even certain 
>> that it's worth keeping, since as you suggest, it makes more sense for 
>> it to be a property of the artist. I'd almost prefer to raise a warning 
>> if the user provides a resolution argument (other than 1) to Polar 
>> rather than trying to make it work. Is anyone actually using it, other 
>> than to set it to 1 on 0.98.x versions?
>>
>> I should have some time to work on this today.
>>
>> Mike
>>
>> Eric Firing wrote:
>> 
>>> Eric Firing wrote:
>>> 
>>>> Jae-Joon Lee wrote:
>>>> 
>>>>> The default resolution (which is used to interpolate a path in polar
>>>>> coordinate) has change to 1 at some point. And because of this, a
>>>>> radial grid becomes a 0-length line. Increasing the resolution will
>>>>> bring back your gridlines.
>>>>> 
>>>> This is not the right solution, though. There was a reason for the 
>>>> change in default resolution to 1--it gives the expected behavior for 
>>>> plotting a line between two points in polar coordinates--and it is 
>>>> not going back. The inability to set resolution on a per-artist 
>>>> basis is a serious problem that doesn't seem to have a simple 
>>>> solution. Until one can be found, some sort of special case handling 
>>>> will be needed for the radial grid lines.
>>>>
>>>> Eric
>>>> 
>>> Expanding on this: it looks like a possible solution is to attach a 
>>> new "resolution" attribute to the Path object. This would ordinarily 
>>> be None, but could be set to another value when the Path is created 
>>> (or later). Then the PolarTransform.transform_path method (and the 
>>> same in other curvilinear projections) could use that value, if not 
>>> None, to control interpolation. Some additional changes would be 
>>> needed to apply this to the radial gridlines.
>>>
>>> Now it is not clear to me that resolution should be an attribute of 
>>> the PolarAxes at all--the interpolation is done by a path method, so 
>>> that method doesn't need a resolution parameter at all if resolution 
>>> is a Path attribute. Except for backwards compatibility. Comments, 
>>> Mike?
>>>
>>> I can't implement it right now, but if no one comes up with a better 
>>> solution, or wants to implement something like this one, then I can do 
>>> it in a day or two.
>>>
>>> (Of course, I may not be seeing a stumbling block.)
>>>
>>> Eric
>>> 
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Tony S Yu wrote:
> When running `pyplot.spy` I ran into the following error:
> 
> AttributeError: 'BlendedGenericTransform' object has no attribute 
> '_interpolation_steps'
> 
> Just from pattern matching (I have no idea what's going on in the 
> code), I noticed that _interpolation_steps was usually called from a 
> Path object, not a Transform object, so I tried switching the call 
> (see diff below), which seems to work for me. Since this was a recent 
> addition (r7130), I figure this was just a typo.
Fixed. Thank you.
Eric
> 
> Cheers,
> -Tony
> 
> 
> ===================================================================
> --- lib/matplotlib/transforms.py	(revision 7133)
> +++ lib/matplotlib/transforms.py	(working copy)
> @@ -1145,7 +1145,7 @@
> ``transform_path_affine(transform_path_non_affine(values))``.
> """
> return Path(self.transform_non_affine(path.vertices), 
> path.codes,
> - self._interpolation_steps)
> + path._interpolation_steps)
> 
> def transform_angles(self, angles, pts, radians=False, 
> pushoff=1e-5):
> """
> 
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

When running `pyplot.spy` I ran into the following error:
AttributeError: 'BlendedGenericTransform' object has no attribute 
'_interpolation_steps'
Just from pattern matching (I have no idea what's going on in the 
code), I noticed that _interpolation_steps was usually called from a 
Path object, not a Transform object, so I tried switching the call 
(see diff below), which seems to work for me. Since this was a recent 
addition (r7130), I figure this was just a typo.
Cheers,
-Tony
===================================================================
--- lib/matplotlib/transforms.py	(revision 7133)
+++ lib/matplotlib/transforms.py	(working copy)
@@ -1145,7 +1145,7 @@
 ``transform_path_affine(transform_path_non_affine(values))``.
 """
 return Path(self.transform_non_affine(path.vertices), 
path.codes,
- self._interpolation_steps)
+ path._interpolation_steps)
 def transform_angles(self, angles, pts, radians=False, 
pushoff=1e-5):
 """

On Fri, May 22, 2009 at 9:35 AM, Andrew Straw <str...@as...> wrote:
> Based on Jae-Joon's comment, I was thinking of making .frame a property
> that raised an Error describing to get .spines instead... That avoids
> the getattr issues, but I think depends on Artist being a new style class.
This is a much better solution, one I hadn't thought of, so go with
it. Artist is already a newstyle class, so no problems there.
> (Thanks to all for the responses... I'm acting on them and will
> incorporate most or all of the suggestions.)
Excellent.
JDH

> but as I look through patches, I notice there are a number of places
> (eg RegularPolygon) where hidden methods w/o docstrings are used. I
> assume Michael wrote most of these in the transforms refactorring.
> Was this a conscious decision to hide them from the doc proprty
> introspection mechanism?
> 
I don't think so. IIRC, most of what are now properties were raw 
attributes at one time, and the hidden methods was just to avoid adding 
more things to the public namespace. But I don't see any compelling 
reason they couldn't be public.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
> 
>> 2) Axes.frame
>> Is it okay to simply drop this attribute? Any code that access this
>> attribute will raise an exception. For example, some of my code in
>> mpl_toolkits.axes_grid access this attribute, although a fix would be
>> very trivial.
>> 
>
> We can drop it - there never was a documented reference to it, no
> public method, etc, so it is safely considered mostly "internal
> code", and in the global scheme is comparatively new code (and on a
> quick grepping did not see any examples using it in the pylab_examples
> or api dirs). I don't think it will impact many users, and anyone who
> was trying to manipulate the frame directly can easily update their
> code. We should just have a little transition cheatsheet in the
> API_CHANGES section describing the removal.
>
> We *could* override getattr and raise a suitable warning pointing to
> the spine docs, if people think that is needed, but overriding getattr
> often leads to unintentional bugs.
> 
Based on Jae-Joon's comment, I was thinking of making .frame a property
that raised an Error describing to get .spines instead... That avoids
the getattr issues, but I think depends on Artist being a new style class.
(Thanks to all for the responses... I'm acting on them and will
incorporate most or all of the suggestions.)
-Andrew

On Thu, May 21, 2009 at 12:35 PM, Tony S Yu <to...@mi...> wrote:
> I'm animating a Circle patch with a varying center and radius, and I noticed
> that changing the ``radius`` attribute has no effect on the patch.
> Currently, ``radius`` is only used to instantiate an Ellipse object, but
> updating radius has no effect (i.e. redrawing the patch doesn't use the new
> radius).
> I've included a patch to add this feature. Also included in the patch is a
> small fix to one of the UI examples (sorry for included a completely
> unrelated patch but the fix seemed to small for a separate email).
> BTW, I'm using a property idiom
> from: http://code.activestate.com/recipes/205183/. I thought that this
> approach was better than polluting the namespace with getters and setters,
> especially since this would differ from the way the Ellipse class uses
> ``width`` and ``height`` attributes.
Thanks Tony -- I committed this with a change. The mpl getters and
setters, as well as the ACCEPTS line, are used in the object
introspection and doc building, so the way to add a property like
radius is:
 def set_radius(self, radius):
 """
 Set the radius of the circle
 ACCEPTS: float
 """
 self.width = self.height = 2 * radius
 def get_radius(self):
 'return the radius of the circle'
 return self.width / 2.
 radius = property(get_radius, set_radius)
but as I look through patches, I notice there are a number of places
(eg RegularPolygon) where hidden methods w/o docstrings are used. I
assume Michael wrote most of these in the transforms refactorring.
Was this a conscious decision to hide them from the doc proprty
introspection mechanism?

That's right, Eric. I think having resolution be an attribute of the 
artist (and not the projection) is the "path" of least resistance here. 
To clarify, however, the interpolation (more specifically, whether to 
interpolate) should remain a function of the projection, not the path. 
That's the important point that lead to it ending up in the wrong place 
in the first place. If we aim to keep the generalization that all grid 
lines are the same kind of object regardless of the projection, and 
therefore set a high resolution parameter on all the grid lines, we 
wouldn't want this to slow down the standard rectilinear axes. As long 
as the standard axes don't obey the parameter, then would should be 
fine. It's somewhat confusing, but I also am seeing this the resolution 
parameter on artists as more of an implementation detail than a public 
API. If someone wants to interpolate their data, IMHO that should be 
the user's responsibility, since they know the best way to do it. This 
functionality isn't really about data points, IMHO.
The more difficult change seems to be being backward compatible about 
the Polar plot accepting a resolution argument. I'm not even certain 
that it's worth keeping, since as you suggest, it makes more sense for 
it to be a property of the artist. I'd almost prefer to raise a warning 
if the user provides a resolution argument (other than 1) to Polar 
rather than trying to make it work. Is anyone actually using it, other 
than to set it to 1 on 0.98.x versions?
I should have some time to work on this today.
Mike
Eric Firing wrote:
> Eric Firing wrote:
>> Jae-Joon Lee wrote:
>>> The default resolution (which is used to interpolate a path in polar
>>> coordinate) has change to 1 at some point. And because of this, a
>>> radial grid becomes a 0-length line. Increasing the resolution will
>>> bring back your gridlines.
>>
>> This is not the right solution, though. There was a reason for the 
>> change in default resolution to 1--it gives the expected behavior for 
>> plotting a line between two points in polar coordinates--and it is 
>> not going back. The inability to set resolution on a per-artist 
>> basis is a serious problem that doesn't seem to have a simple 
>> solution. Until one can be found, some sort of special case handling 
>> will be needed for the radial grid lines.
>>
>> Eric
>
>
> Expanding on this: it looks like a possible solution is to attach a 
> new "resolution" attribute to the Path object. This would ordinarily 
> be None, but could be set to another value when the Path is created 
> (or later). Then the PolarTransform.transform_path method (and the 
> same in other curvilinear projections) could use that value, if not 
> None, to control interpolation. Some additional changes would be 
> needed to apply this to the radial gridlines.
>
> Now it is not clear to me that resolution should be an attribute of 
> the PolarAxes at all--the interpolation is done by a path method, so 
> that method doesn't need a resolution parameter at all if resolution 
> is a Path attribute. Except for backwards compatibility. Comments, 
> Mike?
>
> I can't implement it right now, but if no one comes up with a better 
> solution, or wants to implement something like this one, then I can do 
> it in a day or two.
>
> (Of course, I may not be seeing a stumbling block.)
>
> Eric
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee <lee...@gm...> wrote:
> 2) Axes.frame
> Is it okay to simply drop this attribute? Any code that access this
> attribute will raise an exception. For example, some of my code in
> mpl_toolkits.axes_grid access this attribute, although a fix would be
> very trivial.
We can drop it - there never was a documented reference to it, no
public method, etc, so it is safely considered mostly "internal
code", and in the global scheme is comparatively new code (and on a
quick grepping did not see any examples using it in the pylab_examples
or api dirs). I don't think it will impact many users, and anyone who
was trying to manipulate the frame directly can easily update their
code. We should just have a little transition cheatsheet in the
API_CHANGES section describing the removal.
We *could* override getattr and raise a suitable warning pointing to
the spine docs, if people think that is needed, but overriding getattr
often leads to unintentional bugs.
JDH

Eric Firing wrote:
> Jae-Joon Lee wrote:
>> The default resolution (which is used to interpolate a path in polar
>> coordinate) has change to 1 at some point. And because of this, a
>> radial grid becomes a 0-length line. Increasing the resolution will
>> bring back your gridlines.
> 
> This is not the right solution, though. There was a reason for the 
> change in default resolution to 1--it gives the expected behavior for 
> plotting a line between two points in polar coordinates--and it is not 
> going back. The inability to set resolution on a per-artist basis is a 
> serious problem that doesn't seem to have a simple solution. Until one 
> can be found, some sort of special case handling will be needed for the 
> radial grid lines.
> 
> Eric
Expanding on this: it looks like a possible solution is to attach a new 
"resolution" attribute to the Path object. This would ordinarily be 
None, but could be set to another value when the Path is created (or 
later). Then the PolarTransform.transform_path method (and the same in 
other curvilinear projections) could use that value, if not None, to 
control interpolation. Some additional changes would be needed to apply 
this to the radial gridlines.
Now it is not clear to me that resolution should be an attribute of the 
PolarAxes at all--the interpolation is done by a path method, so that 
method doesn't need a resolution parameter at all if resolution is a 
Path attribute. Except for backwards compatibility. Comments, Mike?
I can't implement it right now, but if no one comes up with a better 
solution, or wants to implement something like this one, then I can do 
it in a day or two.
(Of course, I may not be seeing a stumbling block.)
Eric

Jae-Joon Lee wrote:
> The default resolution (which is used to interpolate a path in polar
> coordinate) has change to 1 at some point. And because of this, a
> radial grid becomes a 0-length line. Increasing the resolution will
> bring back your gridlines.
This is not the right solution, though. There was a reason for the 
change in default resolution to 1--it gives the expected behavior for 
plotting a line between two points in polar coordinates--and it is not 
going back. The inability to set resolution on a per-artist basis is a 
serious problem that doesn't seem to have a simple solution. Until one 
can be found, some sort of special case handling will be needed for the 
radial grid lines.
Eric
> 
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c',
> resolution=100)
> 
> -JJ
> 
> 
> 
> On Thu, May 21, 2009 at 10:13 PM, John Hunter <jd...@gm...> wrote:
>> When plotting the polar demo, I am not getting radial grids on the
>> trunk (but I am getting them on the branch). Any ideas?
>>
>> import matplotlib
>> import numpy as np
>> from matplotlib.pyplot import figure, show, rc, grid
>>
>> # radar green, solid grid lines
>> rc('grid', color='#316931', linewidth=1, linestyle='-')
>> rc('xtick', labelsize=15)
>> rc('ytick', labelsize=15)
>>
>> # force square figure and square axes looks better for polar, IMO
>> width, height = matplotlib.rcParams['figure.figsize']
>> size = min(width, height)
>> # make a square figure
>> fig = figure(figsize=(size, size))
>> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
>>
>> r = np.arange(0, 3.0, 0.01)
>> theta = 2*np.pi*r
>> ax.plot(theta, r, color='#ee8d18', lw=3)
>> ax.set_rmax(2.0)
>>
>> ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
>> ax.grid(True)
>>
>> ax.set_title("And there was much rejoicing!", fontsize=20)
>> show()
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

The default resolution (which is used to interpolate a path in polar
coordinate) has change to 1 at some point. And because of this, a
radial grid becomes a 0-length line. Increasing the resolution will
bring back your gridlines.
ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c',
resolution=100)
-JJ
On Thu, May 21, 2009 at 10:13 PM, John Hunter <jd...@gm...> wrote:
> When plotting the polar demo, I am not getting radial grids on the
> trunk (but I am getting them on the branch). Any ideas?
>
> import matplotlib
> import numpy as np
> from matplotlib.pyplot import figure, show, rc, grid
>
> # radar green, solid grid lines
> rc('grid', color='#316931', linewidth=1, linestyle='-')
> rc('xtick', labelsize=15)
> rc('ytick', labelsize=15)
>
> # force square figure and square axes looks better for polar, IMO
> width, height = matplotlib.rcParams['figure.figsize']
> size = min(width, height)
> # make a square figure
> fig = figure(figsize=(size, size))
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
>
> r = np.arange(0, 3.0, 0.01)
> theta = 2*np.pi*r
> ax.plot(theta, r, color='#ee8d18', lw=3)
> ax.set_rmax(2.0)
>
> ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
> ax.grid(True)
>
> ax.set_title("And there was much rejoicing!", fontsize=20)
> show()
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I just had a quick at the patch and it looks good.
I have two minor issues.
1) API change in Axes.get_xaxis_transform & get_yaxis_transform.
 The default keyword argument which=None raises an exception. Maybe
you meant which="grid"?
2) Axes.frame
 Is it okay to simply drop this attribute? Any code that access this
attribute will raise an exception. For example, some of my code in
mpl_toolkits.axes_grid access this attribute, although a fix would be
very trivial.
Regards,
-JJ
On Thu, May 21, 2009 at 8:06 PM, Andrew Straw <str...@as...> wrote:
> I've implemented initial support for "dropped spines". This is motivated
> by the ability to draw figures that look like
> http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
> attaching the patches and an image created by the new example.
>
> This is a somewhat invasive change into the core of the axis rendering
> code, so I'm hereby requesting a review before committing it into the
> code base. In particular, I dropped the idea of using Traits in MPL not
> because I think it's a bad idea, but because that would involve more
> substantial changes.
>
> Anyhow, I'm attaching the proposed implementation as a series of
> patches. If the general form of this looks OK, I'd write up doc strings
> and a CHANGELOG entry and commit it. Should I wait until after the trunk
> release?
>
> Please let me know what you think. All the examples run with
> exaples/tests/backend_driver.py still seem to give OK results, and the
> test suite raises a few more failures, but these appear due to
> (sub)pixel shifts in text rendering rather than anything more severe.
>
> -Andrew
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Andrew Straw wrote:
> John Hunter wrote:
>> When plotting the polar demo, I am not getting radial grids on the
>> trunk (but I am getting them on the branch). Any ideas?
> 
> git bisect let me narrow it down to r7100 in a few minutes. (I'm back to
> using git to interact with MPL svn again. Just don't ask me to deal
> with the svn branches! :)
Hmm, it seems my git mirror of the svn repo is bad... For some reason
git thinks r7100 comes after r6550, so there are a few commits in there
that seem to have been lumped with r7100!
Oh, wait, now I remember doing "git svn fetch -r 7100:HEAD" at some
point. I'll have to remedy this...

John Hunter wrote:
> When plotting the polar demo, I am not getting radial grids on the
> trunk (but I am getting them on the branch). Any ideas?
git bisect let me narrow it down to r7100 in a few minutes. (I'm back to
using git to interact with MPL svn again. Just don't ask me to deal
with the svn branches! :)
Author: efiring <efiring@f61c4167-ca0d-0410-bb4a-bb21726e55ed>
Date: Wed May 13 19:59:16 2009 +0000
 Experimental clipping of Line _transformed_path to speed zoom and pan.
 This can be modified to work with x monotonically decreasing, but
 for a first try it works only with x monotonically increasing.
 The intention is to greatly speed up zooming and panning into
 a small segment of a very long time series (e.g., 10^6 points)
 without incurring any significant speed penalty in other situations.
git bisect start
# bad: [e4c9c46ab1909c05323da28c057c8d64fc6d44a8] add example of dropped
spines
git bisect bad e4c9c46ab1909c05323da28c057c8d64fc6d44a8
# good: [bdf5bb3116a6d58d49b0d7a98e8dab5d9dacd1da] removed extraneous
savefig calls from examples
git bisect good bdf5bb3116a6d58d49b0d7a98e8dab5d9dacd1da
# bad: [f36409e021d030fa22515d4d9362a2c657e3df3e] applied Michiel's sf
patch 2792742 to speed up Cairo and macosx collections
git bisect bad f36409e021d030fa22515d4d9362a2c657e3df3e
# good: [6d21b5b655f045d9edf759037e3a67ca51f89d08] updates to doc
git bisect good 6d21b5b655f045d9edf759037e3a67ca51f89d08
# bad: [d7a5aecdbf274227e98ad4ac4257435d2e37156d] Fixed bugs in quiver
affecting angles passed in as a sequence
git bisect bad d7a5aecdbf274227e98ad4ac4257435d2e37156d
# bad: [736a4f9804e01d0d5b738f869444709496e34c56] psfrag in backend_ps
now uses baseline-alignment when preview.sty is used
git bisect bad 736a4f9804e01d0d5b738f869444709496e34c56
# bad: [86e1487f9718db26c86867a2711aac5410bd828d] Experimental clipping
of Line _transformed_path to speed zoom and pan.
git bisect bad 86e1487f9718db26c86867a2711aac5410bd828d

On Thu, May 21, 2009 at 7:47 PM, Eric Firing <ef...@ha...> wrote:
> Andrew Straw wrote:
>> I've implemented initial support for "dropped spines". This is motivated
>> by the ability to draw figures that look like
>> http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
>> attaching the patches and an image created by the new example.
> It looks like that nicely addresses a frequent request. Great! I
> haven't looked closely enough yet to see how it all works, but one
> immediate suggestion is that the adjust_spines function in your example
> looks like something that should be modified a bit and turned into an
> axes method with the usual pyplot wrapper. That is a fine point, of
> course, that can be deferred.
>
> It looks like the offset is defined as positive outward from center of
> the plot. Are negative values allowed, so the spine goes through the
> middle of the plot, for example?
Hey Andrew -- this is really excellent. The lack of support for spine
placement is one of the things that has been mentally holding me back
from releasing mpl as 1.0, so by all means commit it. I did read
through the patch, and it looks like a clean implementation so I don't
have any specific suggestions. I would like to see a 'xcenter'or
'ycenter' (or whatver name works best) option in addition to the
'left', 'right', 'top' and 'bottom' so we can easily support things
like Mathematica/Sage style spines
 http://webscripts.softpedia.com/scriptScreenshots/SAGE-Screenshots-27855.html
Do you think you could add this fairly easily? Also, it would be nice
to have some simple configuration options, perhaps a few default
themes, so one could easily switch between them, and probably rc
support for a default theme. The theme might specify both the spine
placement as well as the tick in/out/center placement. None of this
needs to go in ahead of the initial commit though.
Thanks!
JDH

When plotting the polar demo, I am not getting radial grids on the
trunk (but I am getting them on the branch). Any ideas?
import matplotlib
import numpy as np
from matplotlib.pyplot import figure, show, rc, grid
# radar green, solid grid lines
rc('grid', color='#316931', linewidth=1, linestyle='-')
rc('xtick', labelsize=15)
rc('ytick', labelsize=15)
# force square figure and square axes looks better for polar, IMO
width, height = matplotlib.rcParams['figure.figsize']
size = min(width, height)
# make a square figure
fig = figure(figsize=(size, size))
ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
r = np.arange(0, 3.0, 0.01)
theta = 2*np.pi*r
ax.plot(theta, r, color='#ee8d18', lw=3)
ax.set_rmax(2.0)
ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
ax.grid(True)
ax.set_title("And there was much rejoicing!", fontsize=20)
show()

Andrew Straw wrote:
> I've implemented initial support for "dropped spines". This is motivated
> by the ability to draw figures that look like
> http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
> attaching the patches and an image created by the new example.
> 
> This is a somewhat invasive change into the core of the axis rendering
> code, so I'm hereby requesting a review before committing it into the
> code base. In particular, I dropped the idea of using Traits in MPL not
> because I think it's a bad idea, but because that would involve more
> substantial changes.
> 
> Anyhow, I'm attaching the proposed implementation as a series of
> patches. If the general form of this looks OK, I'd write up doc strings
> and a CHANGELOG entry and commit it. Should I wait until after the trunk
> release?
> 
> Please let me know what you think. All the examples run with
> exaples/tests/backend_driver.py still seem to give OK results, and the
> test suite raises a few more failures, but these appear due to
> (sub)pixel shifts in text rendering rather than anything more severe.
> 
> -Andrew
Andrew,
It looks like that nicely addresses a frequent request. Great! I 
haven't looked closely enough yet to see how it all works, but one 
immediate suggestion is that the adjust_spines function in your example 
looks like something that should be modified a bit and turned into an 
axes method with the usual pyplot wrapper. That is a fine point, of 
course, that can be deferred.
It looks like the offset is defined as positive outward from center of 
the plot. Are negative values allowed, so the spine goes through the 
middle of the plot, for example?
The name "spine" threw me off for a while; but I guess that is a 
reasonable description for a line with ticks. "Axis" and "Scale" are 
already taken, so maybe "spine" is as good as we can find. "Dropped 
spine" sounds like a painful medical condition... Oh, well...
Eric

I've implemented initial support for "dropped spines". This is motivated
by the ability to draw figures that look like
http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
attaching the patches and an image created by the new example.
This is a somewhat invasive change into the core of the axis rendering
code, so I'm hereby requesting a review before committing it into the
code base. In particular, I dropped the idea of using Traits in MPL not
because I think it's a bad idea, but because that would involve more
substantial changes.
Anyhow, I'm attaching the proposed implementation as a series of
patches. If the general form of this looks OK, I'd write up doc strings
and a CHANGELOG entry and commit it. Should I wait until after the trunk
release?
Please let me know what you think. All the examples run with
exaples/tests/backend_driver.py still seem to give OK results, and the
test suite raises a few more failures, but these appear due to
(sub)pixel shifts in text rendering rather than anything more severe.
-Andrew