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 ------------------------------------------------------------------------------ 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
