polar in a subplot

Community matplotlib-users
1

Hi all,

  If I run the attached example I obtain no polar plots, but a view like plot(t,r_1) - for what reason ?

Nils

python -i test_subplot_polar.py --verbose-helpful
$HOME=/home/nwagner
CONFIGDIR=/home/nwagner/.matplotlib
/usr/lib/python2.4/site-packages/matplotlib/__init__.py:662: UserWarning: Bad val "inputenc" on line #144
         "text.latex.unicode : inputenc # use "ucs" and "inputenc" LaTeX packages for handling
"
         in file "/home/nwagner/.matplotlib/matplotlibrc"
         Could not convert "inputenc" to boolean
   warnings.warn('Bad val "%s" on line #%d\n\t"%s"\n\tin file \
matplotlib data path /usr/lib/python2.4/site-packages/matplotlib/mpl-data
loaded rc file /home/nwagner/.matplotlib/matplotlibrc
matplotlib version 0.98.3
verbose.level helpful
interactive is False
units is False
platform is linux2
Using fontManager instance from /home/nwagner/.matplotlib/fontList.cache
backend GTKAgg version 2.5.3
findfont: Matching :family=sans-serif:style=normal:variant=normal:weight=normal:stretch=normal:size=medium to Bitstream Vera Sans (/usr/lib/python2.4/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf) with score of 1.000000
Found dvipng version 1.5

test_subplot_polar.py (198 Bytes)

2

You need to specify polar=True to the subplot commands. Try this:

from pylab import subplot, polar, linspace, show

from numpy import pi, sin, cos
t = linspace(0,2*pi,20)
r_1 = (1+sin(t))
r_2 = (1+cos(t))
subplot(211, polar=True)
polar(t,r_1) #Or can use plot()
subplot(212, polar=True)
polar(t,r_2)
show()

Ryan

···

On Tue, Dec 2, 2008 at 11:07 AM, Nils Wagner <nwagner@…1052…> wrote:

Hi all,

If I run the attached example I obtain no polar plots, but a view like plot(t,r_1) - for what reason ?

–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

3

Hi Ryan,

Thank you very much !
It would be nice to have that information in the docstring

subplot(*args, **kwargs)
     Create a subplot command, creating axes with::

       subplot(numRows, numCols, plotNum)

     where *plotNum* = 1 is the first plot number and increasing *plotNums*
     fill rows first. max(*plotNum*) == *numRows* * *numCols*

The next inquiry is related to xticks.
I have added

xticks(linspace(0,2*pi,24,endpoint=False))

The difference between consecutive xticks is varying between 14 and 16 degrees.

For what reason ?

Nils

polar.png

···

On Tue, 2 Dec 2008 11:14:48 -0600 "Ryan May" <rmay31@...287...> wrote:

On Tue, Dec 2, 2008 at 11:07 AM, Nils Wagner > <nwagner@...1052...>wrote:

Hi all,

If I run the attached example I obtain no polar plots, but a view like
plot(t,r_1) - for what reason ?

You need to specify polar=True to the subplot commands. Try this:

from pylab import subplot, polar, linspace, show
from numpy import pi, sin, cos
t = linspace(0,2*pi,20)
r_1 = (1+sin(t))
r_2 = (1+cos(t))
subplot(211, polar=True)
polar(t,r_1) #Or can use plot()
subplot(212, polar=True)
polar(t,r_2)
show()

Ryan

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

4

Thank you very much !

It would be nice to have that information in the docstring

Done.

The next inquiry is related to xticks.

I have added

xticks(linspace(0,2*pi,24,endpoint=False))

The difference between consecutive xticks is varying between 14 and 16 degrees.

For what reason ?

Looks like roundoff error. For instance:

linspace(0, 2*pi, 24)[7] * 180. / pi
104.999999999999

If you format that with ‘%d’, it becomes 104, not 105.

Is there an accepted way of doing this rounding in matplotlib that doesn’t round in odd cases?

Ryan

···

On Tue, Dec 2, 2008 at 11:27 AM, Nils Wagner <nwagner@…1052…> wrote:

–
Ryan May
Graduate Research Assistant
School of Meteorology

University of Oklahoma

5

The next inquiry is related to xticks.

I have added

xticks(linspace(0,2*pi,24,endpoint=False))

The difference between consecutive xticks is varying between 14 and 16 degrees.

The following works around the roundoff for me:

xticks(linspace(0, 360, 24, endpoint=False) * pi/180.)

Ryan

···

–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

6

Ryan May wrote:

    Thank you very much !
    It would be nice to have that information in the docstring

Done.

Thanks for updating the docstring. I actually saw this as a usability bug and have come up with a patch such that polar() (et al) will *replace* the current axes with a polar plot if it isn't already polar. This is (from the user's perspective) similar to how, for example, a histogram plot would work -- that is, you don't have to tell subplot you're about to plot a histogram.

But Ryan's new docstring is not obsolete with respect to my proposed change. Both techniques will work, and in fact subplot(polar=True); polar(...) will be slightly faster since it avoids creating a linear axes which is subsequently thrown away.

Any argument against committing my change?

    The next inquiry is related to xticks.
    I have added

    xticks(linspace(0,2*pi,24,endpoint=False))

    The difference between consecutive xticks is varying between 14
    and 16 degrees.

    For what reason ?

Looks like roundoff error. For instance:

linspace(0, 2*pi, 24)[7] * 180. / pi
104.999999999999

If you format that with '%d', it becomes 104, not 105.

Is there an accepted way of doing this rounding in matplotlib that doesn't round in odd cases?

The polar theta tick formatter could be changed to call "round", I guess. Alternatively, it looks like '%0.0f' also does the right thing. I think that's generally what people would want for polar plots. This change would only affect polar theta ticks, so we don't need to worry about a change in behavior in standard Euclidean plots.

Ryan's workaround (to get around this numerically external to matplotlib) is a good suggestion as well, but I think changing the formatter may be less surprising...

Cheers,
Mike

···

On Tue, Dec 2, 2008 at 11:27 AM, Nils Wagner > <nwagner@...1052... <mailto:nwagner@…1052…>> > wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

7

Michael Droettboom wrote:

Thanks for updating the docstring. I actually saw this as a usability bug and have come up with a patch such that polar() (et al) will *replace* the current axes with a polar plot if it isn't already polar. This is (from the user's perspective) similar to how, for example, a histogram plot would work -- that is, you don't have to tell subplot you're about to plot a histogram.

But Ryan's new docstring is not obsolete with respect to my proposed change. Both techniques will work, and in fact subplot(polar=True); polar(...) will be slightly faster since it avoids creating a linear axes which is subsequently thrown away.

Any argument against committing my change?

None here. I'm +1.

The polar theta tick formatter could be changed to call "round", I guess. Alternatively, it looks like '%0.0f' also does the right thing. I think that's generally what people would want for polar plots. This change would only affect polar theta ticks, so we don't need to worry about a change in behavior in standard Euclidean plots.

Ryan's workaround (to get around this numerically external to matplotlib) is a good suggestion as well, but I think changing the formatter may be less surprising...

I like the idea of using %0.0f. If I don't hear any objections, I'll go ahead and make the change. It definitely will make things less confusing for our users.

Ryan

···

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

8

I've committed both of these things. The subplot()/polar() change seems tricky, so it may produce some breakage even though the "regression tests" are passing. Please let me know if you see anything strange after this change.

Mike

Ryan May wrote:

···

Michael Droettboom wrote:

Thanks for updating the docstring. I actually saw this as a usability bug and have come up with a patch such that polar() (et al) will *replace* the current axes with a polar plot if it isn't already polar. This is (from the user's perspective) similar to how, for example, a histogram plot would work -- that is, you don't have to tell subplot you're about to plot a histogram.

But Ryan's new docstring is not obsolete with respect to my proposed change. Both techniques will work, and in fact subplot(polar=True); polar(...) will be slightly faster since it avoids creating a linear axes which is subsequently thrown away.

Any argument against committing my change?

None here. I'm +1.

The polar theta tick formatter could be changed to call "round", I guess. Alternatively, it looks like '%0.0f' also does the right thing. I think that's generally what people would want for polar plots. This change would only affect polar theta ticks, so we don't need to worry about a change in behavior in standard Euclidean plots.

Ryan's workaround (to get around this numerically external to matplotlib) is a good suggestion as well, but I think changing the formatter may be less surprising...

I like the idea of using %0.0f. If I don't hear any objections, I'll go ahead and make the change. It definitely will make things less confusing for our users.

Ryan

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA