Menu
▾
▴
matplotlib-users
|
From: Nils W. <nw...@ia...> - 2008-12-02 17:07:31
Attachments:
test_subplot_polar.py
|
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
|
|
From: Ryan M. <rm...@gm...> - 2008-12-02 17:14:55
|
On Tue, Dec 2, 2008 at 11:07 AM, Nils Wagner <nw...@ia...>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 |
|
From: Nils W. <nw...@ia...> - 2008-12-02 17:27:42
Attachments:
polar.png
|
On Tue, 2 Dec 2008 11:14:48 -0600
"Ryan May" <rm...@gm...> wrote:
> On Tue, Dec 2, 2008 at 11:07 AM, Nils Wagner
> <nw...@ia...>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
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
|
|
From: Ryan M. <rm...@gm...> - 2008-12-02 18:12:05
|
On Tue, Dec 2, 2008 at 11:27 AM, Nils Wagner <nw...@ia...>wrote: > 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 -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma |
|
From: Ryan M. <rm...@gm...> - 2008-12-02 18:15:30
|
> > 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 |
|
From: Michael D. <md...@st...> - 2008-12-02 18:27:31
|
Ryan May wrote: > On Tue, Dec 2, 2008 at 11:27 AM, Nils Wagner > <nw...@ia... <mailto:nw...@ia...>> > 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 -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA |
|
From: Ryan M. <rm...@gm...> - 2008-12-02 19:07:14
|
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 |
|
From: Michael D. <md...@st...> - 2008-12-02 20:11:06
|
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 |
