Confirmed, but just to be completely explicit, removing the ax.autoscale_view(True,True,True) fixes the problem. Is there a specific thing you are trying to achieve that means ax.autoscale_view(True,True,True) is necessary?
Apologies, I mis-read the ticket. To me, this is not a bug - I would not expect a polar plot to draw negative tickmarks/gridlines - you will end up with irregularly spaced lines, and will be unable to determine the radial value of any of the plotted points (because, if you plot negative radii r == -r).
Personally, I don't think this feature should be implemented in mpl.
You could achieve a similar goal if all you want is negative radii - in which case, I would just define a formatter which returns the negative of the number it is given. I'd be happy to give you an example of that if you need.
WeatherGod : Plotting dB was maybe a bad example. The main use is not to plot log scale.
pelson : This ticket is the follow up of #1603. So I guess there is no r = -r issue anymore ?
To my mind : The center of the polar plot r =0 is the minY from autoscale or the set_ylim. And the rmax is the maxY is from autoscale or the set_ylim. Values are plotted correctly. I don't understand why the grid cannot?
For example, I don't know if it's the good way, but mpl could internally shift all values from (-2,5) to (0,7), plot the graph, so values and grid lines are plotted, and shift backwards the ticks to print correct values. This solution is a hack but it works without user interaction. In my case, I can know before if the values I will plot will have negatives values or not.
There seems to be some confusion about how to deal with negative r and polar plots. Someone(s) who regularly uses these plots (and preferably someone who plots decibels) needs to weight in on the 'right' way for them to behave.
We now have at least four open issues (and at least one closed one) on this problem.
Can someone re-explain why they think this shouldn't be implemented? I don't understand the objection. This is a very common thing to do, like microphone response plots or antenna radiation patterns:
I agree that we should be able to make these db plots without any fuss. All that is needed is an appropriate Locator (and Formatter, if you want to include the "db" labels). The default RadialLocator is appropriate for ordinary polar coordinates. One can replace it with a MaxNLocator, or anything else. A potential problem with existing locators for this purpose is that they might tend to put a tick and label at or too close to the actual center.
Activity
pelson commented on Feb 4, 2013
Confirmed, but just to be completely explicit, removing the ax.autoscale_view(True,True,True) fixes the problem. Is there a specific thing you are trying to achieve that means ax.autoscale_view(True,True,True) is necessary?
Cheers,
ffteja commented on Feb 4, 2013
It doesn't fix the problem. It just plots only positive Y values.
Replace
ax.autoscale_view(True,True,True)
by
ax.set_ylim(-2,5)
and the problem is still here
The problem is there is no Y gridlines for negatives values. (I want to plot a polar plot of negatives values ex: -20dB, -23dB....)
pelson commented on Feb 6, 2013
Apologies, I mis-read the ticket. To me, this is not a bug - I would not expect a polar plot to draw negative tickmarks/gridlines - you will end up with irregularly spaced lines, and will be unable to determine the radial value of any of the plotted points (because, if you plot negative radii r == -r).
Personally, I don't think this feature should be implemented in mpl.
You could achieve a similar goal if all you want is negative radii - in which case, I would just define a formatter which returns the negative of the number it is given. I'd be happy to give you an example of that if you need.
Cheers,
WeatherGod commented on Feb 6, 2013
Or, perhaps, just have the radial axis be set to a log scale and use the
raw (non-negative) values for plotting?
ffteja commented on Feb 7, 2013
WeatherGod : Plotting dB was maybe a bad example. The main use is not to plot log scale.
pelson : This ticket is the follow up of #1603. So I guess there is no r = -r issue anymore ?
To my mind : The center of the polar plot r =0 is the minY from autoscale or the set_ylim. And the rmax is the maxY is from autoscale or the set_ylim. Values are plotted correctly. I don't understand why the grid cannot?
For example, I don't know if it's the good way, but mpl could internally shift all values from (-2,5) to (0,7), plot the graph, so values and grid lines are plotted, and shift backwards the ticks to print correct values. This solution is a hack but it works without user interaction. In my case, I can know before if the values I will plot will have negatives values or not.
ffteja commented on Feb 22, 2013
pelson : I think your workaround is not possible is you want to plot negative values and positive values on the same graph, isn't it?
tacaswell commented on Jan 20, 2014
This is related to #2203 and #1847
There seems to be some confusion about how to deal with negative r and polar plots. Someone(s) who regularly uses these plots (and preferably someone who plots decibels) needs to weight in on the 'right' way for them to behave.
We now have at least four open issues (and at least one closed one) on this problem.
endolith commented on Apr 18, 2014
Can someone re-explain why they think this shouldn't be implemented? I don't understand the objection. This is a very common thing to do, like microphone response plots or antenna radiation patterns:
http://w4rnl.net46.net/img/amod48-4a.gif
https://2.bp.blogspot.com/-cDB2d6YCMtc/TzPXIaWFeBI/AAAAAAAAAEM/0mOvOJvKNaU/s1600/SM58%20Polar%20Pattern.jpg
http://learningexchange.ptc.com/tutorials/tutorial_212/Figure09.png
http://www.mathworks.de/matlabcentral/fileexchange/screenshots/3824/original.jpg
http://static.musiciansfriend.com/derivates/6/001/204/424/DV019_Jpg_Regular_271281_polar_pattern.jpg
Faking it by creating a formatter seems needlessly complicated, especially since the plot itself works fine.
efiring commented on Apr 19, 2014
I agree that we should be able to make these db plots without any fuss. All that is needed is an appropriate Locator (and Formatter, if you want to include the "db" labels). The default RadialLocator is appropriate for ordinary polar coordinates. One can replace it with a MaxNLocator, or anything else. A potential problem with existing locators for this purpose is that they might tend to put a tick and label at or too close to the actual center.
tacaswell commented on Jun 29, 2014
@ffteja @endolith I have created a MEP for this (https://github.com/matplotlib/matplotlib/wiki/MEP24) and would like your input on it.
Realistically, there is no way this is going to get done for 1.4, punting to 1.5.x.
ffteja commented on May 11, 2015
Hi tacaswell.
Any update on the topic since?
tacaswell commented on May 11, 2015
No one (that I am aware of) has shown interest in implementing this.
The MEP has moved to http://matplotlib.org/devdocs/devel/MEP/MEP24.html / https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP which still needs to be fleshed out.