You can get this behavior you are asking for by passing "resolution=1" to polar. (This has been there for ages, but unfortunately wasn't documented until recently). We can consider making 1 the default.

There are cases in which the automatic interpolation is useful, but in the present implementation the onus is on the user to avoid this "going the long way" problem.

Mike

James Evans wrote:

## ···

Michael,

John said you were the one to go to for this one. I was wondering if you had any comments about the following?

--James Evans

All,

While looking over the polar plot code I came across the following issue: When plotting something

like 'polar( [2*pi/180, 358*pi/180], [2.0, 1.0] )' the plotted line will actually wrap around the

origin of the plot before reaching its destination. Initially I thought that this was correct

behavior. The line numerically passed through all angles between 2 and 358 degrees in a linear

fashion. However after consulting several colleagues and text books I believe that the behavior is

actually wrong.

It is my understanding that for polar plots there is no linear mapping of the axes as it is currently

implemented. Rather for a simple two-point line defined in polar coordinates, the line should

essentially take the direct route. This is highlighted by the two-point equation of a line for polar

plots:

r = ( r1*r2*sin(t2-t1) ) / ( (r1*sin(t-t1)) - (r2*sin(t-t2)) )

If you were to plug in the two points given above, then increment theta (t) from 2 degrees to 358

degrees, then convert to Cartesian cords, and plot the results, you will get the correct line that

directly crosses the zero degree line and not one that wraps around the origin.

Is the polar plot function implemented this way on purpose? Which way should it really be

implemented?

--

Michael Droettboom

Science Software Branch

Operations and Engineering Division

Space Telescope Science Institute

Operated by AURA for NASA

Ok. Thanks for the information. That does do exactly what I would expect. I would place my vote for having this be the default

behavior since this is what it means to say "go from point A to B" on a polar plot.

--James

## ···

-----Original Message-----

From: Michael Droettboom [mailto:mdroe@…31…]

Sent: Monday, February 02, 2009 8:28 AM

To: James Evans; matplotlib development list

Subject: Re: FW: Polar Plot Design Issues

You can get this behavior you are asking for by passing "resolution=1"

to polar. (This has been there for ages, but unfortunately wasn't

documented until recently). We can consider making 1 the default.

There are cases in which the automatic interpolation is useful, but in

the present implementation the onus is on the user to avoid this "going

the long way" problem.

Mike

James Evans wrote:

> Michael,

>

> John said you were the one to go to for this one. I was wondering if you had any comments about the

following?

>

> --James Evans

>

>

>> All,

>>

>> While looking over the polar plot code I came across the following issue: When plotting something

>> like 'polar( [2*pi/180, 358*pi/180], [2.0, 1.0] )' the plotted line will actually wrap around the

>> origin of the plot before reaching its destination. Initially I thought that this was correct

>> behavior. The line numerically passed through all angles between 2 and 358 degrees in a linear

>> fashion. However after consulting several colleagues and text books I believe that the behavior is

>> actually wrong.

>>

>> It is my understanding that for polar plots there is no linear mapping of the axes as it is

currently

>> implemented. Rather for a simple two-point line defined in polar coordinates, the line should

>> essentially take the direct route. This is highlighted by the two-point equation of a line for

polar

>> plots:

>>

>> r = ( r1*r2*sin(t2-t1) ) / ( (r1*sin(t-t1)) - (r2*sin(t-t2)) )

>>

>> If you were to plug in the two points given above, then increment theta (t) from 2 degrees to 358

>> degrees, then convert to Cartesian cords, and plot the results, you will get the correct line that

>> directly crosses the zero degree line and not one that wraps around the origin.

>>

>> Is the polar plot function implemented this way on purpose? Which way should it really be

>> implemented?

>>

>

>

--

Michael Droettboom

Science Software Branch

Operations and Engineering Division

Space Telescope Science Institute

Operated by AURA for NASA

Another vote here for changing resolution=1 to be the default. It seems strange to plot values on a line plot and not have the values connected. At least in my area, every polar plot of real-world data we make needs to set this flag to 1 or the wrong plot is created.

Ted

## ···

-----Original Message-----

From: Michael Droettboom [mailto:mdroe@…31…]

Sent: Monday, February 02, 2009 8:28 AM

To: James Evans; matplotlib development list

Subject: Re: [matplotlib-devel] FW: Polar Plot Design Issues

You can get this behavior you are asking for by passing "resolution=1"

to polar. (This has been there for ages, but unfortunately wasn't

documented until recently). We can consider making 1 the default.

There are cases in which the automatic interpolation is useful, but in

the present implementation the onus is on the user to avoid this "going

the long way" problem.

Mike

James Evans wrote:

> Michael,

>

> John said you were the one to go to for this one. I was wondering if

you had any comments about the following?

>

> --James Evans

>

>

>> All,

>>

>> While looking over the polar plot code I came across the following

issue: When plotting something

>> like 'polar( [2*pi/180, 358*pi/180], [2.0, 1.0] )' the plotted line

will actually wrap around the

>> origin of the plot before reaching its destination. Initially I

thought that this was correct

>> behavior. The line numerically passed through all angles between 2

and 358 degrees in a linear

>> fashion. However after consulting several colleagues and text books

I believe that the behavior is

>> actually wrong.

>>

>> It is my understanding that for polar plots there is no linear

mapping of the axes as it is currently

>> implemented. Rather for a simple two-point line defined in polar

coordinates, the line should

>> essentially take the direct route. This is highlighted by the two-

point equation of a line for polar

>> plots:

>>

>> r = ( r1*r2*sin(t2-t1) ) / ( (r1*sin(t-t1)) - (r2*sin(t-t2)) )

>>

>> If you were to plug in the two points given above, then increment

theta (t) from 2 degrees to 358

>> degrees, then convert to Cartesian cords, and plot the results, you

will get the correct line that

>> directly crosses the zero degree line and not one that wraps around

the origin.

>>

>> Is the polar plot function implemented this way on purpose? Which

way should it really be

>> implemented?

>>

>

>

--

Michael Droettboom

Science Software Branch

Operations and Engineering Division

Space Telescope Science Institute

Operated by AURA for NASA

-----------------------------------------------------------------------

-------

This SF.net email is sponsored by:

SourcForge Community

SourceForge wants to tell your story.

http://p.sf.net/sfu/sf-spreadtheword

_______________________________________________

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

matplotlib-devel List Signup and Options

No virus found in this incoming message.

Checked by AVG - www.avg.com

Version: 8.0.233 / Virus Database: 270.10.17/1931 - Release Date:

02/02/09 19:21:00