Skip to content

Allow negative radial grid values in polar.py #2203

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dtimson opened this issue Jul 5, 2013 · 19 comments
Closed

Allow negative radial grid values in polar.py #2203

dtimson opened this issue Jul 5, 2013 · 19 comments
Assignees
Milestone

Comments

@dtimson
Copy link

dtimson commented Jul 5, 2013

In PolarAxes.set_rgrids(), remove the test for rmin <= 0.

Explanation: while it is possible to plot negative values in a polar plot (e.g. antenna gain down to -30 dB, as a function of azimuth), placing radial grids at negative values is rejected, for no apparent reason.

@tacaswell
Copy link
Member

related to issue #2133

@bfroehle
Copy link
Contributor

bfroehle commented Jul 8, 2013

I just came across this issue. I've been using a workaround in the mean time.

>>> ax.set_rgrids(range(-40, 40, 10))
...
ValueError: radial grids must be strictly positive
>>> ax.set_yticks(range(-40, 40, 10))  # Works great!

@dtimson
Copy link
Author

dtimson commented Jul 8, 2013

It's natural to want to plot this:

It's an antenna gain pattern, plotting gain in dB, going down to -25dB in
value at the two nulls. Gridlines are at -10, -20, -30.

This was plotted just by removing the test for rmin <= 0 in
PolarAxes.set_rgrids(), in polar.py

On 7 July 2013 16:53, Thomas A Caswell notifications@github.com wrote:

related to issue #2133#2133


Reply to this email directly or view it on GitHubhttps://github.com//issues/2203#issuecomment-20572708
.

Dan Timson
System Architect
CRFS Ltd
Building 7200
Cambridge Research Park
Beach Drive
Cambridge
CB25 9TL

Tel: +44 (0)1223 815615
Direct: +44 (0)1223 815522
e: dtimson@crfs.com
w: www.crfs.com

@tacaswell
Copy link
Member

I would argue that if there is a 'natural' way to deal with negative radius values, it should be via reflection as discussed in the other issue. I don't know what the best solution it is not obvious. @dmcdougall you have thoughts?

@WeatherGod
Copy link
Member

Why not something along these lines. Reflect any data that falls below
rmin instead of automatically reflecting only those values less than zero?
Or would it make more sense that it should clip those values?

@bfroehle
Copy link
Contributor

bfroehle commented Jul 8, 2013

Personally I have little use for reflected values at all, but it may be counter intuitive to some. For me, I'd advocate clipping data that falls below rmin (just like we would clip data that falls below ymin).

I see polar plots as essentially a Cartesian plot which has been mapped into a circle, or even more preferably an annulus (however I don't see how to create a polar plot in the shape of an annulus here).

@dtimson
Copy link
Author

dtimson commented Jul 8, 2013

I agree - clipping (i.e. if y<rmin, then set y=rmin) is the most
appropriate. For engineering plots of dB vs angle, large negative values
mean negligible signal levels, so it's OK if they all map to the origin of
the polar plot. This gives nice looking plots, as you would want.

On 8 July 2013 19:29, Bradley M. Froehle notifications@github.com wrote:

Personally I have little use for reflected values at all, but it may be
counter intuitive to some. For me, I'd advocate clipping data that falls
below rmin (just like we would clip data that falls below ymin).

I see polar plots as essentially a Cartesian plot which has been mapped
into a circle, or even more preferably an annulus (however I don't see how
to create a polar plot in the shape of an annulus here).


Reply to this email directly or view it on GitHubhttps://github.com//issues/2203#issuecomment-20625987
.

Dan Timson
System Architect
CRFS Ltd
Building 7200
Cambridge Research Park
Beach Drive
Cambridge
CB25 9TL

Tel: +44 (0)1223 815615
Direct: +44 (0)1223 815522
e: dtimson@crfs.com
w: www.crfs.com

@mdboom
Copy link
Member

mdboom commented Jul 16, 2013

So, the current behavior (in 1.2.1 and 1.3.0) is to clip values < rmin. If so, what is the value of plotting gridlines at negative values?

@bfroehle
Copy link
Contributor

@mdboom We are suggesting that in certain fields it is often useful for rmin to be negative.

One way to think about this is that for plotting things are drawn in the physical location (theta, r - rmin) but labeled as r. For example, this plot would have rmin = -15 and rmax = 0.

@tacaswell
Copy link
Member

MEP: https://github.com/matplotlib/matplotlib/wiki/MEP24

@bfroehle @dtimson I have created a MEP to deal with this and would like both of your inputs.

It is highly unlikely this will get done for 1.4.0, punting to 1.5.x.

@tacaswell tacaswell modified the milestones: v1.5.x, v1.4.0 Jun 29, 2014
@dtimson
Copy link
Author

dtimson commented Jul 18, 2014

I've taken a look at what's in MEP24. I don't think you need a specified
minimum value of r: just allow any value, and leave it up to the user to
ensure their dataset takes the values they want to plot. After all, this is
what happens for Cartesian plots.

As I said in an email just over a year ago, all that's needed (I assume) is
to remove the test for rmin <= 0 in PolarAxes.set_rgrids(), in polar.py.

Dan

On 29 June 2014 03:41, Thomas A Caswell notifications@github.com wrote:

MEP: https://github.com/matplotlib/matplotlib/wiki/MEP24

@bfroehle https://github.com/bfroehle @dtimson
https://github.com/dtimson I have created a MEP to deal with this and
would like both of your inputs.

It is highly unlikely this will get done for 1.4.0, punting to 1.5.x.


Reply to this email directly or view it on GitHub
#2203 (comment)
.

Dan Timson
System Architect
CRFS Ltd
Building 7200
Cambridge Research Park
Beach Drive
Cambridge
CB25 9TL

Tel: +44 (0)1223 815615
Direct: +44 (0)1223 815522
e: dtimson@crfs.com
w: www.crfs.com

@tacaswell
Copy link
Member

@dtimson I don't understand what you mean. The reason we clip r<=0 is that it negative r values were turning into effective rotations by pi.

This is not a bit of the code base I am familiar with nor use on a regular basis, could you put together a PR showing what you are suggesting?

@dtimson
Copy link
Author

dtimson commented Jul 18, 2014

OK, if you've got people putting in radial coords with negative radii (!),
it would be shame to break their code. So use clipping if you like.

Dan

On 18 July 2014 13:13, Thomas A Caswell notifications@github.com wrote:

@dtimson https://github.com/dtimson I don't understand what you mean.
The reason we clip r<=0 is that it negative r values were turning into
effective rotations by pi.

This is not a bit of the code base I am familiar with nor use on a regular
basis, could you put together a PR showing what you are suggesting?


Reply to this email directly or view it on GitHub
#2203 (comment)
.

Dan Timson
System Architect
CRFS Ltd
Building 7200
Cambridge Research Park
Beach Drive
Cambridge
CB25 9TL

Tel: +44 (0)1223 815615
Direct: +44 (0)1223 815522
e: dtimson@crfs.com
w: www.crfs.com

@WeatherGod
Copy link
Member

The issue was that we have two competing feature requests here.

  1. Treat the radial as a regular cartesian number line that is just simply
    anchored at whatever the minimum r value is (thus allowing negative values
    in situations such as log scale).
  2. Treat the negative radials as a rotation by pi.

The original behavior way back when did neither of these, IIRC.
Unfortunately, I don't see how we can implement both as they seem to be
mutually exclusive. I am not sure how to proceed. Perhaps we can get some
inspirations from other projects such as Matlab, R's ggplot, and mathmatica?

Cheers!
Ben Root

On Fri, Jul 18, 2014 at 9:13 AM, dtimson notifications@github.com wrote:

OK, if you've got people putting in radial coords with negative radii (!),
it would be shame to break their code. So use clipping if you like.

Dan

On 18 July 2014 13:13, Thomas A Caswell notifications@github.com wrote:

@dtimson https://github.com/dtimson I don't understand what you mean.
The reason we clip r<=0 is that it negative r values were turning into
effective rotations by pi.

This is not a bit of the code base I am familiar with nor use on a
regular
basis, could you put together a PR showing what you are suggesting?


Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/issues/2203#issuecomment-49423918>

.

Dan Timson
System Architect
CRFS Ltd
Building 7200
Cambridge Research Park
Beach Drive
Cambridge
CB25 9TL

Tel: +44 (0)1223 815615
Direct: +44 (0)1223 815522
e: dtimson@crfs.com
w: www.crfs.com

Reply to this email directly or view it on GitHub
#2203 (comment)
.

@dtimson
Copy link
Author

dtimson commented Jul 18, 2014

Is there anyone who actually wants option 2, treating negative radials as a
rotation by pi? If not, let's just go with option 1. allowing negative
values. The option 2 behaviour would in any case be easily achievable by
minor processing of the input data.

Dan

On 18 July 2014 15:01, Benjamin Root notifications@github.com wrote:

The issue was that we have two competing feature requests here.

  1. Treat the radial as a regular cartesian number line that is just simply
    anchored at whatever the minimum r value is (thus allowing negative values
    in situations such as log scale).
  2. Treat the negative radials as a rotation by pi.

The original behavior way back when did neither of these, IIRC.
Unfortunately, I don't see how we can implement both as they seem to be
mutually exclusive. I am not sure how to proceed. Perhaps we can get some
inspirations from other projects such as Matlab, R's ggplot, and
mathmatica?

Cheers!
Ben Root

On Fri, Jul 18, 2014 at 9:13 AM, dtimson notifications@github.com
wrote:

OK, if you've got people putting in radial coords with negative radii
(!),
it would be shame to break their code. So use clipping if you like.

Dan

On 18 July 2014 13:13, Thomas A Caswell notifications@github.com
wrote:

@dtimson https://github.com/dtimson I don't understand what you
mean.
The reason we clip r<=0 is that it negative r values were turning into
effective rotations by pi.

This is not a bit of the code base I am familiar with nor use on a
regular
basis, could you put together a PR showing what you are suggesting?


Reply to this email directly or view it on GitHub
<

https://github.com/matplotlib/matplotlib/issues/2203#issuecomment-49423918>

.

Dan Timson
System Architect
CRFS Ltd
Building 7200
Cambridge Research Park
Beach Drive
Cambridge
CB25 9TL

Tel: +44 (0)1223 815615
Direct: +44 (0)1223 815522
e: dtimson@crfs.com
w: www.crfs.com

Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/issues/2203#issuecomment-49428874>

.


Reply to this email directly or view it on GitHub
#2203 (comment)
.

Dan Timson
System Architect
CRFS Ltd
Building 7200
Cambridge Research Park
Beach Drive
Cambridge
CB25 9TL

Tel: +44 (0)1223 815615
Direct: +44 (0)1223 815522
e: dtimson@crfs.com
w: www.crfs.com

@endolith
Copy link
Contributor

Is it possible to have a rminclip={True, False, 'auto'} parameter and support both? If you set the rmin=0 and have clip=False, it goes through the origin and produces an effective rotation by pi. If you have the rmin=-100, and clip=True, then it shows negative dB until they hit -100 and then clips them so they don't go through the origin. 'auto' would be False if rmin == 0 and True otherwise?

In dB polar plots, negative and positive radii produce the same magnitude decibel value, so you sometimes see them show polarity as different colors: http://www.sweetwater.com/insync/media/2013/05/supercardioid.gif

Is there anyone who actually wants option 2, treating negative radials as a rotation by pi?

Isn't that necessary to make things like http://mathworld.wolfram.com/Rose.html ?

@gabrielgrant
Copy link

@dtimson to answer your question: I, for one, was expecting that negative radial values be plotted as rotations by pi. When using radial plots to show vectors, it is standard that a negative magnitude be shown as a positive vector in the opposite direction.

@QuLogic QuLogic mentioned this issue Jul 15, 2015
3 tasks
@QuLogic QuLogic self-assigned this Nov 15, 2016
@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@dstansby
Copy link
Member

I think this is now fixed by #4699 @QuLogic ?

@QuLogic
Copy link
Member

QuLogic commented Nov 12, 2017

Yes, dunno why it wasn't tagged before.

@QuLogic QuLogic closed this as completed Nov 12, 2017
@QuLogic QuLogic modified the milestones: v2.2, 2.1 (next point release) Nov 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants