radial grids broken on polar?

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()

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! :slight_smile:

Author: efiring <efiring@...722...>

    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

···

Date: Wed May 13 19:59:16 2009 +0000

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! :slight_smile:

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...

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

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

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

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

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

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