matplotlib-users Mailing List for matplotlib

Hi, 
using generators the fuction would go like this:
def subplots(numRows,numCols):
 cnt = 0
 for i in range(numRows):
 for j in range(numCols):
 cnt+=1
 ax=subplot(numRows,numCols,cnt)
 yield ax
right ?
- Sebastian
On Monday 13 June 2005 14:43, Nicolas Girard wrote:
> Hi again,
>
> while browsing the docs about axes, I found this example, which seems to be
> a recurrent "pattern" each time one wants to draw subplots in a figure:
>
> cnt = 0
> for i in range(numRows):
> for j in range(numCols):
> cnt+=1
> ax=subplot(numRows,numCols,cnt)
> plot(blah,blah)
> if ax.is_last_row() : xlabel('time(s)')
> if ax.is_first_col(): ylabel('volts')
>
> Indeed, I've written such code many times now. It seems to me that the use
> of subfigures could be make easier with such "subplots" function as:
>
> for ax in subplots(numRows,numCols):
> plot(blah,blah)
> if ax.is_last_row() : xlabel('time(s)')
> if ax.is_first_col(): ylabel('volts')
>
> What do you think ?
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you
> shotput a projector? How fast can you ride your desk chair down the office
> luge track? If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi again,
while browsing the docs about axes, I found this example, which seems to be a 
recurrent "pattern" each time one wants to draw subplots in a figure:
cnt = 0
for i in range(numRows):
 for j in range(numCols):
 cnt+=1
 ax=subplot(numRows,numCols,cnt)
 plot(blah,blah)
 if ax.is_last_row() : xlabel('time(s)')
 if ax.is_first_col(): ylabel('volts')
Indeed, I've written such code many times now. It seems to me that the use of 
subfigures could be make easier with such "subplots" function as:
for ax in subplots(numRows,numCols):
 plot(blah,blah)
 if ax.is_last_row() : xlabel('time(s)')
 if ax.is_first_col(): ylabel('volts')
What do you think ?

On Monday 13 June 2005 17:51, John Hunter wrote:
> I think you may be misunderstanding something. axes and subplot are
> both helper functions to create an Axes instance. You should use one
> or the other to create a given Axes, but should not use "axes" before
> "subplot" in order to change the behavior of subplot.
>
Yes, you were right, I was a bit confused by this axes stuff, which is now 
clearer to me. Thanks !
Still, I have the feeling that having both an Axis and an Axes class, while 
"axes" is the plural of "axis", might be a bit confusing
> If you do not like the way the Axes are laid out when using subplot,
> you have to do the layout manually with axes. There have been some
> helper functions and code posted on the mailing list archives to make
> this process easier (eg a tk backend GUI widget to help you configure
> subplots).
>
OK, I didn't find them but will try further.
Anyway, subfigures are drawn with a certain margin between each other, which 
must take the form of either a hardcoded constant in the source code, or a 
variable. Exposing this constant/variable to the user would allow him to 
easily change it, which sounds useful to me ;-)
I've looked into the axes-related source code for that constant/variable, but 
couldn't find it...
cheers,
nicolas

On Monday 13 June 2005 22:57, John Hunter wrote:
> Are you using the same tick locator on different axes? 
Thanks for your answer ; yes, I am
> You shouldn't be. 
Oh, really ? Then it must be that. Let me try... OK, I used
 a.yaxis.set_major_locator(LinearLocator(numticks=3))
instead of reusing the same locator, and here's the result:
 http://nicolasgirard.nerim.net/3ticks.png
As you can see, there's a big improvement but still a problem with the 
subplots on the right.
I'd suggest add to the docs the fact that a locator shouldn't be reused, 
because it's not obvious, since a valid semantics is:
 majorLocator = LinearLocator(numticks=3)
 ...
 anAxis.set_major_locator(majorLocator)
which I understood as:
 "anAxis's locator should be linear, with 3 ticks"
> You should try and create a standalone script that exposes your 
> bug.
Okay, I'll do it, but perhaps not before the next week-end...
cheers,
nicolas

>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:
 Nicolas> On Friday 10 June 2005 00:13, Nicolas Girard wrote:
 >> There's an other annoying bug with this script. For the
 >> subplots on columns 2 and 3 I asked the yaxis to have only but
 >> 3 ticks, using:
 >> 
 >> majorLocator = LinearLocator(numticks=3)
 >> 
 >> ... a=subplot(nbvals,3,i)
 >> a.yaxis.set_major_locator(majorLocator)
 >> 
 >> which works, but as the figure gets refreshed, the ticks
 >> disappear, and at the end only part of them remain
 >> visible. I've encounetered this with the standard Agg backend,
 >> with either interactive and non-interactive mode. Saving as
 >> jpeg, png and ps didn't help, as you can see here:
 >> 
 >> http://nicolasgirard.nerim.net/out.png
 >> 
 >> 
 Nicolas> Unfortunately, this problem remains, even after updating
 Nicolas> my sandbox and trying Baptiste Carvello's patch :-/
Are you using the same tick locator on different axes? You shouldn't
be. You should try and create a standalone script that exposes your
bug.
JDH

Kevin,
Please try mpl version 0.81 and the current basemap package. There were 
big changes in contourf and routines it uses between 0.80 and 0.81.
Eric

On Friday 10 June 2005 00:13, Nicolas Girard wrote:
> There's an other annoying bug with this script. For the subplots on columns
> 2 and 3 I asked the yaxis to have only but 3 ticks, using:
>
> majorLocator = LinearLocator(numticks=3)
>
> ...
> a=subplot(nbvals,3,i)
> a.yaxis.set_major_locator(majorLocator)
>
> which works, but as the figure gets refreshed, the ticks disappear, and at
> the end only part of them remain visible. I've encounetered this with the
> standard Agg backend, with either interactive and non-interactive mode.
> Saving as jpeg, png and ps didn't help, as you can see here:
>
> http://nicolasgirard.nerim.net/out.png
>
>
Unfortunately, this problem remains, even after updating my sandbox and trying 
Baptiste Carvello's patch :-/
cheers,
nicolas

On Monday 13 June 2005 17:33, John Hunter wrote:
> Your problem is here:
>
> setp(a.get_yticklabels(), visible=False)
>
> By making your yticklabels invisible, they are still used in
> determining the position of the ylabel, but they aren't displayed
> (this may be a mpl bug, I haven't thought about it enough). What you
> want to do is turn off the tick labels altogether.
>
> ax.set_yticklabels([])
>
John,
thanks for your answer : it solved the problem !
cheers,
nicolas

>>>>> "John" == John Hunter <jdh...@ac...> writes:
>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
 Arnd> If there is a simpler way to achieve this, I would of course
 Arnd> be interested. In general I think it would be nice to
 Arnd> change the joinstyle with a simple command, either globally
 Arnd> or even better on a line-by-line basis. Is this possible
 Arnd> already now in some way?
 John> There is no better way. I have been holding off on exposing
 John> this because I didn't see a clear way to handle it because
 John> dashed and solid lines have different default cap and join
 John> styles. It is now clear that c good solution is to expose
 John> dash_capstyle, dash_joinstyle, solid_capstyle,
 John> solid_joinstyle, as rc params and line properties.
 John> Any forseeable problems with this approach?
Hey Arnd,
OK, I went ahead with this approach (lines.py CVS revision 1.32 or
later). Only lightly tested. I'm already having fun with the new
kwargs to axes, as this testscript illustrates
 from pylab import *
 rc('lines', lw=3)
 y = [0.1, 0.9, 0.1, 0.9]
 axd = dict(xlim=(0,2), ylim=(0,1), autoscale_on=False)
 ax1 = subplot(311, **axd)
 plot(y, solid_joinstyle='miter')
 axd.update(dict(sharex=ax1, sharey=ax1))
 subplot(312, **axd)
 plot(y, solid_joinstyle='round')
 subplot(313, **axd)
 plot(y, solid_joinstyle='bevel')
 show()
JDH

On 6/13/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Dave" =3D=3D Dave <da...@gm...> writes:
>=20
> Dave> I'm getting a "crash" when using ipython and pylab on WinXP.
> Dave> The problem shows up when I have a subplot and try to use
> Dave> ylim to change the axis scale. Here's an example (after
> Dave> plotting some data).
>=20
> Dave> In [2]: ylim() Out[2]: (0.0, 30000000000.0)
>=20
> Dave> In [3]: xlim(-6, 6) Out[3]: (-6, 6)
>=20
> Dave> (axis scsale changes as expected)
>=20
> Dave> In [4]: ylim(0, 1000)
>=20
> Dave> ( crash - i.e., CPU use goes to 100%, prompt does not
> Dave> return, Tkinter and ipython windows unresponsive)
>=20
>=20
> My guess is that you have data at 30000000000.0 and when you zoom in
> to 1000 the data is so far out of the view lim that it is overflowing
> an integer in the extension code. This is a know bug, but if you post
> a complete example on the sf site in the bug report section that
> exposes us, it will help us fix it sooner rather than later.
>=20
> Thanks,
> JDH
>=20
I'll see if I can reproduce it wirth a nice simple example suitable
for debug. If so I'll post to sf. Thanks.
By the way, the new autoscale flag will be used and appreciated here
just as soon as I can add it to my scripts.
- David

If anyone could assist me in understanding what issues result in the error 
message below , I would be very grateful.
"Cannot automatically convert masked array to Numeric because data
 is masked in one or more locations"
(error raised by Numeric, but within matplotlib core)
I frequently run into this error message when I try to use matplotlib to 
produce contour graphs. Does anyone have a more detailed explanation of what 
issues prompt this error? What confuses me is that the same script (posted 
below, FWIW) may or may not produce this error depending on which datafile I 
try to graph? I also get this message if I use the Numeric function where() 
to generate any array used by the contour() function.
Thanks,
 Kevin Mueller
 Univ. Illinois, Dept. Atmospheric Sciences, Urbana/Champaign
#######################
traceback:
(python 2.4.1, Numeric 24b, matplotlib 0.80, linux)
#######################
Traceback (most recent call last):
 File "/home/manabe/a/kjmuelle/scripts/latlonslice.py", line 39, in ?
 badmask=outmask,cmap=cm.jet,colors=None)
 File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/toolkits/basemap/basemap.py", 
line 1030, in contourf
 levels, colls = pylab.contourf(*args, **kwargs)
 File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/pylab.py", 
line 1679, in contourf
 ret = gca().contourf(*args, **kwargs)
 File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/axes.py", 
line 1248, in contourf
 return self._contourHelper.contourf(*args, **kwargs)
 File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/contour.py", 
line 879, in contourf
 lev, cmap)
 File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/contour.py", 
line 629, in _process_colors
 mappable.autoscale()
 File "/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/cm.py", 
line 456, in autoscale
 self.norm.autoscale(self._A)
 File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/matplotlib/colors.py", 
line 580, in autoscale
 rval = ravel(A)
 File 
"/home/manabe/a/kjmuelle/lib/python2.4/site-packages/Numeric/Numeric.py", 
line 543, in ravel
 return reshape(m, (-1,))
 File "/home/manabe/a/kjmuelle/lib/python2.4/site-packages/Numeric/MA/MA.py", 
line 632, in __array__
 raise MAError, \
MA.MA.MAError: Cannot automatically convert masked array to Numeric because 
data
 is masked in one or more locations.
############################
WHEN RUNNING THIS SCRIPT:
############################
from Scientific.IO import NetCDF as nc
import Numeric as nm
from pylab import *
import sys,os.path
it=0 # time index
ik=0 # depth index
tracer="DIC" # tracer name
if not len(sys.argv)>1:
 print "Error: no datafile arguments given"
else:
 datapaths = sys.argv[1:]
for datapath in datapaths:
 f = nc.NetCDFFile(datapath)
 outdata = f.variables[tracer].getValue()[it,ik,:,:]
 outmask = f.variables["TMASK"].getValue()[ik,:,:]
 gdepth = f.variables["z_t"].getValue()
 f.close()
 X,Y,Z = nm.arange(-180,181,4),nm.arange(-90,91,2),gdepth*.01
 clf()
 levels,colors = contourf(X,Y,outdata,
 badmask=outmask,cmap=cm.jet,colors=None)
 levels,colors = contour(X,Y,outdata,
 badmask=outmask,colors='k')
 colorbar(tickfmt="%.1e")
 gtitle = "%s: at depth %i, %s" % (os.path.split(datapath[1],-Z[ik],tracer)
 title(gtitle)
 show()

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
 Arnd> If there is a simpler way to achieve this, I would of course
 Arnd> be interested. In general I think it would be nice to
 Arnd> change the joinstyle with a simple command, either globally
 Arnd> or even better on a line-by-line basis. Is this possible
 Arnd> already now in some way?
There is no better way. I have been holding off on exposing this
because I didn't see a clear way to handle it because dashed and solid
lines have different default cap and join styles. It is now clear
that c good solution is to expose dash_capstyle, dash_joinstyle,
solid_capstyle, solid_joinstyle, as rc params and line properties.
Any forseeable problems with this approach?
JDH

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
 Arnd> Well, difficult to estimate from my side, as I don't know
 Arnd> how much extra code it would be.
 >> From a (=my) user perspective I think it would be nice,
 Arnd> because I have a couple of situations where one plot should
 Arnd> stay with the same range in x and y whereas another plot
 Arnd> next to it should autoscale.
Perhaps then the best solution is just to expose that property (and
all other axes properties) in the subplot and axes functions. This
seems like the cleanest, easiest implementation to me. I just checked
this into CVS (axes.py revision 1.112).
So you can do, eg, 
 subplot(111, autoscale_on=False)
As usual, you get a quick synopsis of settable props, you can do
In [2]: ax = gca()
In [3]: setp(ax)
 alpha: float
 autoscale_on: True|False
 axis_bgcolor: any matplotlib color - see help(colors)
 axis_off: void
 axis_on: void
 clip_box: a matplotlib.transform.Bbox instance
 clip_on: [True | False]
 cursor_props: a (float, color) tuple
 figure: a Figure instance
 frame_on: True|False
 label: any string
 lod: [True | False]
 position: len(4) sequence of floats
 title: str
 transform: a matplotlib.transform transformation instance
 visible: [True | False]
 xlabel: str
 xlim: len(2) sequence of floats
 xscale: str
 xticklabels: sequence of strings
 xticks: sequence of floats
 ylabel: str
 ylim: len(2) sequence of floats
 yscale: str
 yticklabels: sequence of strings
 yticks: sequence of floats
 zorder: any number
Thus you can do now do fun things like
 subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
 xlim=(-1,1), ylim =(0,10) )
Very nice!
JDH

On 2005年6月13日, John Hunter wrote:
> >>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
>
> Arnd> Just one more question on this: is there an even simpler way
> Arnd> to activate this than via fig = figure(figsize=(6,6)) ax =
> Arnd> fig.add_axes([0.1, 0.1, 0.8, 0.8])
> Arnd> ax.set_autoscale_on(False) ? For example, could one apply a
> Arnd> general autoscale(False) to the following plot(s)/subplots?
>
> I can think of two ways this could be implemented. Make it an rc
> property, and when any new axes are created they would use the rc
> default.
Personally I don't use rc properties much, only if I can't avoid
them (Reasoning: I want to keep my plot-files portable
from one machine to the other without carrying the rc files
around. Setting rc properties from within the programm
is an alternative, but not _my_ preferred one).
> Alternatively, one could make it a figure method, which
> would apply to all of its axes. Eg if you did
>
> fig.autoscale(False)
>
> then autoscaling would be turned off on all existing axes and would be
> off by default for any new ones created.
I do like this one - does this also mean that autoscale=False
can be given as additional argument to the figure command?
In addition it would be nice to set this type of option
for the subplot command.
> I am not sure if this is a sufficiently useful configuration option to
> justify the extra code. What do you think?
Well, difficult to estimate from my side, as I don't know how
much extra code it would be.
From a (=my) user perspective I think it would be nice,
because I have a couple of situations
where one plot should stay with the same range in x and y
whereas another plot next to it should autoscale.
Best,
Arnd

>>>>> "Dave" == Dave <da...@gm...> writes:
 Dave> I'm getting a "crash" when using ipython and pylab on WinXP.
 Dave> The problem shows up when I have a subplot and try to use
 Dave> ylim to change the axis scale. Here's an example (after
 Dave> plotting some data).
 Dave> In [2]: ylim() Out[2]: (0.0, 30000000000.0)
 Dave> In [3]: xlim(-6, 6) Out[3]: (-6, 6)
 Dave> (axis scsale changes as expected)
 Dave> In [4]: ylim(0, 1000)
 Dave> ( crash - i.e., CPU use goes to 100%, prompt does not
 Dave> return, Tkinter and ipython windows unresponsive)
My guess is that you have data at 30000000000.0 and when you zoom in
to 1000 the data is so far out of the view lim that it is overflowing
an integer in the extension code. This is a know bug, but if you post
a complete example on the sf site in the bug report section that
exposes us, it will help us fix it sooner rather than later.
Thanks,
JDH

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Hi all, rc('l',lw=1,mew=0,markersize=1)
Ficed in CVS -- I simply removed the abbrevs for the toplevel rc. Eg,
'lw' is still an 'abbrev for 'linewidth' but 'l' is not an abbrev for
'lines'. Since this wasn't working anyway, it won't break anyone's
code to "fix" it.
JDH

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
 Arnd> Just one more question on this: is there an even simpler way
 Arnd> to activate this than via fig = figure(figsize=(6,6)) ax =
 Arnd> fig.add_axes([0.1, 0.1, 0.8, 0.8])
 Arnd> ax.set_autoscale_on(False) ? For example, could one apply a
 Arnd> general autoscale(False) to the following plot(s)/subplots?
I can think of two ways this could be implemented. Make it an rc
property, and when any new axes are created they would use the rc
default. Alternatively, one could make it a figure method, which
would apply to all of its axes. Eg if you did
 fig.autoscale(False)
then autoscaling would be turned off on all existing axes and would be
off by default for any new ones created. 
I am not sure if this is a sufficiently useful configuration option to
justify the extra code. What do you think?
JDH

>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:
 Nicolas> Hi all, well, I'm sorry to wake up an old thread, but
 Nicolas> what if there are subplots in the figure ? I tried to ask
 Nicolas> axes([0.1, 0.1, 0.9, 0.9])
 Nicolas> before specifying my subplot()s, but it changed nothing.
 Nicolas> How to reduce the margin of the whole figure when it has
 Nicolas> subplots ?
I think you may be misunderstanding something. axes and subplot are
both helper functions to create an Axes instance. You should use one
or the other to create a given Axes, but should not use "axes" before
"subplot" in order to change the behavior of subplot.
If you do not like the way the Axes are laid out when using subplot,
you have to do the layout manually with axes. There have been some
helper functions and code posted on the mailing list archives to make
this process easier (eg a tk backend GUI widget to help you configure
subplots).
JDH

Your problem is here:
 setp(a.get_yticklabels(), visible=False)
By making your yticklabels invisible, they are still used in
determining the position of the ylabel, but they aren't displayed
(this may be a mpl bug, I haven't thought about it enough). What you
want to do is turn off the tick labels altogether.
 ax.set_yticklabels([])
Hope this helps,
JDH