Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: jan gillis <jan.gillis@in...>  20080916 06:18:34

Hello, I have a problem with polar plot, if i run the following code in matplotlib 0.98.3, polar plot is drawing a extra circle to go from angle 3.14159265 to angle 3.03753126. Is there a solution for this problem? ******************** 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 fig = figure(figsize=(8,8)) ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c') z = np.zeros((1,2000),complex) z.real = 0.2 z.imag = np.arange(50,50,0.05) gamma_r = np.transpose((z1)/(z+1)) ax.plot(np.angle(gamma_r), np.abs(gamma_r), '.', zorder=0) ax.set_rmax(2.0) grid(True) show() ******************** Kind regards, Jean 
From: Nils Wagner <nwagner@ia...>  20100818 13:04:01

Hi all, Is it possible to create a polar plot, where the lower bound of the radius is larger than zero ? I would like to plot an annulus. Any pointer would be appreciated. Thanks in advance Nils 
From: Benjamin Root <ben.root@ou...>  20100818 13:52:06
Attachments:
Message as HTML

On Wed, Aug 18, 2010 at 8:03 AM, Nils Wagner <nwagner@...>wrote: > Hi all, > > Is it possible to create a polar plot, where the lower > bound of the radius is larger than zero ? > I would like to plot an annulus. > > Any pointer would be appreciated. > > Thanks in advance > > Nils > > Nils, It appears that there is a .set_rmin() function, however, I don't think it does what we expect it to. I can't get an annulus, but it only plots the parts that are r >= r_min (but r_min is at the origin, and the axis labels are in the wrong places...) Ben Root 
From: Nils Wagner <nwagner@ia...>  20100818 15:10:38

On Wed, 18 Aug 2010 08:51:31 0500 Benjamin Root <ben.root@...> wrote: > On Wed, Aug 18, 2010 at 8:03 AM, Nils Wagner > <nwagner@...>wrote: > >> Hi all, >> >> Is it possible to create a polar plot, where the lower >> bound of the radius is larger than zero ? >> I would like to plot an annulus. >> >> Any pointer would be appreciated. >> >> Thanks in advance >> >> Nils >> >> > Nils, > > It appears that there is a .set_rmin() function, >however, I don't think it > does what we expect it to. I can't get an annulus, but >it only plots the > parts that are r >= r_min (but r_min is at the origin, >and the axis labels > are in the wrong places...) > > Ben Root Ben, Thank you for your reply. Please can you send me your example. Nils 
From: Michael Droettboom <mdroe@st...>  20100818 17:37:40
Attachments:
Message as HTML

On 08/18/2010 09:51 AM, Benjamin Root wrote: > > > On Wed, Aug 18, 2010 at 8:03 AM, Nils Wagner > <nwagner@... <mailto:nwagner@...>> > wrote: > > Hi all, > > Is it possible to create a polar plot, where the lower > bound of the radius is larger than zero ? > I would like to plot an annulus. > > Any pointer would be appreciated. > > Thanks in advance > > Nils > > > Nils, > > It appears that there is a .set_rmin() function, however, I don't > think it does what we expect it to. I can't get an annulus, but it > only plots the parts that are r >= r_min (but r_min is at the origin, > and the axis labels are in the wrong places...) > > Ben Root This bug (that the raxis labels are in the wrong place) should now be fixed in r8651. This doesn't, unfortunately, address the original question about annular plots. Mike  Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA 
From: Friedrich Romstedt <friedrichromstedt@gm...>  20100818 22:03:55
Attachments:
polar.pdf

2010/8/18 Michael Droettboom <mdroe@...>: > This bug (that the raxis labels are in the wrong place) should now be fixed > in r8651. This doesn't, unfortunately, address the original question about > annular plots. Is the attached issue with a plain polar axes already fixed? I never encountered this before. 344 degrees happens to be 6.0 rad. I'm on svn 8626. 
From: Michael Droettboom <mdroe@st...>  20100819 13:14:01

On 08/18/2010 06:03 PM, Friedrich Romstedt wrote: > 2010/8/18 Michael Droettboom<mdroe@...>: > >> This bug (that the raxis labels are in the wrong place) should now be fixed >> in r8651. This doesn't, unfortunately, address the original question about >> annular plots. >> > Is the attached issue with a plain polar axes already fixed? I never > encountered this before. 344 degrees happens to be 6.0 rad. I'm on > svn 8626. > How are you creating that graph? By default, polar plots don't do that. Mike  Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA 
From: Friedrich Romstedt <friedrichromstedt@gm...>  20100819 21:53:19

2010/8/19 Michael Droettboom <mdroe@...>: > On 08/18/2010 06:03 PM, Friedrich Romstedt wrote: >> Is the attached issue with a plain polar axes already fixed? I never >> encountered this before. 344 degrees happens to be 6.0 rad. I'm on >> svn 8626. > > How are you creating that graph? By default, polar plots don't do that. Yeah, it's my issue, but I'm not happy with fixing it. Currently, matplotlib forces the xticks (i.e., the theta ticks) to be at sensible values via .set_xticks() and .set_xlabels() (projections/polar.py). I'm coding a matplotlib extension package which has to clear the axes often, but restoring the major locators, the title and stuff after clearing. It was agnostic to the specialities of polar axes so far. I could say, "if nothing is requested specially, treat it as a running system", but I see this as clumsy and errorprone at all. I would rather suggest to insert a new Locator class being aware of radians. It would suffice to return tick positions dividing 2 pi into an integer number of bins. It's not necessary to cover all the peculiarities of the old historic division system into 360 parts. Accompanying would be formatters in radians and degrees with adjustable precision (no autodetect necessary). Friedrich 
From: JaeJoon Lee <lee.j.joon@gm...>  20100819 03:28:22
Attachments:
image.png
demo_floating_axes.py

On Wed, Aug 18, 2010 at 10:03 PM, Nils Wagner <nwagner@...> wrote: > I would like to plot an annulus. > With mpl_toolkits.axisartist, it is possible to make an axes of annulus. But, the resulting axes is not fully compatible with the original matplotlib axes. Most of the tickrelated commands won't work and you need to use new commands provided by the axisartist module. Attached is a sample script and a screeshot. Also see these examples, http://matplotlib.sourceforge.net/examples/axes_grid/demo_floating_axes.html JJ 
From: Michael Droettboom <mdroe@st...>  20100820 13:33:11

On 08/19/2010 05:53 PM, Friedrich Romstedt wrote: > 2010/8/19 Michael Droettboom<mdroe@...>: > >> On 08/18/2010 06:03 PM, Friedrich Romstedt wrote: >> >>> Is the attached issue with a plain polar axes already fixed? I never >>> encountered this before. 344 degrees happens to be 6.0 rad. I'm on >>> svn 8626. >>> >> How are you creating that graph? By default, polar plots don't do that. >> > Yeah, it's my issue, but I'm not happy with fixing it. Currently, > matplotlib forces the xticks (i.e., the theta ticks) to be at sensible > values via .set_xticks() and .set_xlabels() (projections/polar.py). > > I'm coding a matplotlib extension package which has to clear the axes > often, but restoring the major locators, the title and stuff after > clearing. It was agnostic to the specialities of polar axes so far. > Why and how are you restoring the major locator? It seems like that's the issue. I don't think preventing the theta locator from being changed is something we want to do. Polar plots (by default) just set fixed theta ticks at multiples of pi/4. > I would rather suggest to insert a new Locator class being aware of > radians. It would suffice to return tick positions dividing 2 pi into > an integer number of bins. It's not necessary to cover all the > peculiarities of the old historic division system into 360 parts. > Perhaps using FixedLocator, rather than explicitly setting the ticks using set_xticks (as polar plots currently do) would be better. However, the locator could still be changed, not really addressing your problem. For convenience, however, we could add a locator that given n, divides 2pi into n parts. > Accompanying would be formatters in radians and degrees with > adjustable precision (no autodetect necessary). > Sure. Adding a radian formatter makes sense. Mike  Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA 
From: Benjamin Root <ben.root@ou...>  20100820 15:02:58
Attachments:
Message as HTML

On Fri, Aug 20, 2010 at 8:33 AM, Michael Droettboom <mdroe@...> wrote: > On 08/19/2010 05:53 PM, Friedrich Romstedt wrote: > > 2010/8/19 Michael Droettboom<mdroe@...>: > > > >> On 08/18/2010 06:03 PM, Friedrich Romstedt wrote: > >> > >>> Is the attached issue with a plain polar axes already fixed? I never > >>> encountered this before. 344 degrees happens to be 6.0 rad. I'm on > >>> svn 8626. > >>> > >> How are you creating that graph? By default, polar plots don't do that. > >> > > Yeah, it's my issue, but I'm not happy with fixing it. Currently, > > matplotlib forces the xticks (i.e., the theta ticks) to be at sensible > > values via .set_xticks() and .set_xlabels() (projections/polar.py). > > > > I'm coding a matplotlib extension package which has to clear the axes > > often, but restoring the major locators, the title and stuff after > > clearing. It was agnostic to the specialities of polar axes so far. > > > Why and how are you restoring the major locator? It seems like that's > the issue. I don't think preventing the theta locator from being > changed is something we want to do. Polar plots (by default) just set > fixed theta ticks at multiples of pi/4. > > I would rather suggest to insert a new Locator class being aware of > > radians. It would suffice to return tick positions dividing 2 pi into > > an integer number of bins. It's not necessary to cover all the > > peculiarities of the old historic division system into 360 parts. > > > Perhaps using FixedLocator, rather than explicitly setting the ticks > using set_xticks (as polar plots currently do) would be better. > However, the locator could still be changed, not really addressing your > problem. > > For convenience, however, we could add a locator that given n, divides > 2pi into n parts. > > Accompanying would be formatters in radians and degrees with > > adjustable precision (no autodetect necessary). > > > Sure. Adding a radian formatter makes sense. > > Just curious, this wouldn't have to be just for PolarPlots, right? Could it also be used for regular plots of sinusoids and such. Ben Root 
From: Friedrich Romstedt <friedrichromstedt@gm...>  20100823 19:11:45

2010/8/20 Michael Droettboom <mdroe@...>: >> Yeah, it's my issue, but I'm not happy with fixing it. Currently, >> matplotlib forces the xticks (i.e., the theta ticks) to be at sensible >> values via .set_xticks() and .set_xlabels() (projections/polar.py). >> >> I'm coding a matplotlib extension package which has to clear the axes >> often, but restoring the major locators, the title and stuff after >> clearing. It was agnostic to the specialities of polar axes so far. > > Why and how are you restoring the major locator? It seems like that's the > issue. I don't think preventing the theta locator from being changed is > something we want to do. Polar plots (by default) just set fixed theta > ticks at multiples of pi/4. My package provides support for Layers in matplotlib. And the layers' data can be changed, making a complete redraw of the axes a solution much easier to implement than dealing with the fuzzy API stuff directly. I don't need highperformance. When putting axes.clear(), the locator is being reset. In cartesian coords, it happens that I want a MaxNLocator(nbins=3) or similiar from time to time, and this must be restored then. For cartesian axes, if the user does not specify another locator, I'm setting the AutoLocator(), what is the same what the (cartesian) axes does. Dealing with the case "no locator set" (by "using matplotlib default fallback") is neither nice nor straightforward. (It has to do with complicating the calling conventions. I would have to treat the case 'ignore [xy]locator' specially.) It would maybe be a good solution to provide some abstract Axes.get_default_locators(), being public. Each SomeClass(Axes) can define what they understand under "default locator". >> I would rather suggest to insert a new Locator class being aware of >> radians. It would suffice to return tick positions dividing 2 pi into >> an integer number of bins. It's not necessary to cover all the >> peculiarities of the old historic division system into 360 parts. > > Perhaps using FixedLocator, rather than explicitly setting the ticks using > set_xticks (as polar plots currently do) would be better. However, the > locator could still be changed, not really addressing your problem. Seems that you misunderstood my problem, if I'm not misunderstanding you :) I have no problem with a "mutable" locator. (But the user has normally no access to the axes, only the Stack class changes the axes.) But right, I wanted to derive it from the Locator class framework, just specialising the location. > For convenience, however, we could add a locator that given n, divides 2pi > into n parts. Yes, and Ben's idea is quite nice, to make this accessible also to rectangular plots. This implies some simple thoughts on the view lims to take them into account when issuing the tick locations. >> Accompanying would be formatters in radians and degrees with >> adjustable precision (no autodetect necessary). > > Sure. Adding a radian formatter makes sense. If we go into details let's switch to devel maybe? Friedrich 
Sign up for the SourceForge newsletter:
No, thanks