matplotlib-users Mailing List for matplotlib (Page 10)

You have to use set_ylim((0,2)) to set the y limits.
Cheers
 Tommy
On Jan 4, 2007, at 11:09 AM, Berthold H=F6llmann wrote:
> Considering the following script I would Expect a resulting y range of
> (1, 2) but I get (1, 3). Is this a bug or a feature. I'm using python
> 2.5, matplotlib 0.87.7.
>
> from matplotlib.backends.backend_agg import FigureCanvasAgg as =20
> FigureCanvas
> from matplotlib.figure import Figure
> fig =3D Figure()
> canvas =3D FigureCanvas(fig)
> ax =3D fig.add_subplot(111)
> lines =3D (ax.plot([1, 2, 3], [1, 2, 3]),)
> axes =3D fig.get_axes()[0]
> axes.set_xlim((0, 2))
> axes.set_aspect('auto', adjustable=3D'box')
> axes.grid(True)
> canvas.print_figure('out.eps')
>
> Kind regards
> Berthold
> --=20
> __ Address:
> G / \ L Germanischer Lloyd
> phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606
> fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg
>
>
> ----------------------------------------------------------------------=20=
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Considering the following script I would Expect a resulting y range of
(1, 2) but I get (1, 3). Is this a bug or a feature. I'm using python
2.5, matplotlib 0.87.7.
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure
fig = Figure()
canvas = FigureCanvas(fig)
ax = fig.add_subplot(111)
lines = (ax.plot([1, 2, 3], [1, 2, 3]),)
axes = fig.get_axes()[0]
axes.set_xlim((0, 2))
axes.set_aspect('auto', adjustable='box')
axes.grid(True)
canvas.print_figure('out.eps')
Kind regards
Berthold
-- 
 __ Address:
 G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg

Nils Wagner wrote:
> Hi,
>
> I have tried to install matplotlib on a x86_64 machine
> using openSUSE10.2.
>
> python setup.py yields
>
> Package pygtk-2.0 was not found in the pkg-config search 
> path.
> Perhaps you should add the directory containing 
> `pygtk-2.0.pc'
> to the PKG_CONFIG_PATH environment variable
>
> echo $PKG_CONFIG_PATH
> /opt/gnome/lib64/pkgconfig
>
> ls -l /opt/gnome/lib64/pkgconfig
> insgesamt 208
> -rw-r--r-- 1 root root 244 27. Nov 22:57 atkmm-1.6.pc
> -rw-r--r-- 1 root root 259 27. Nov 19:36 atk.pc
> -rw-r--r-- 1 root root 419 25. Nov 15:58 
> bonobo-activation-2.0.pc
> -rw-r--r-- 1 root root 243 27. Nov 22:27 cairomm-1.0.pc
> -rw-r--r-- 1 root root 276 27. Nov 22:24 gconf-2.0.pc
> -rw-r--r-- 1 root root 264 28. Nov 03:37 gdict-1.0.pc
> -rw-r--r-- 1 root root 322 27. Nov 22:05 gdk-2.0.pc
> -rw-r--r-- 1 root root 321 27. Nov 22:57 gdkmm-2.4.pc
> -rw-r--r-- 1 root root 262 27. Nov 19:44 gdk.pc
> -rw-r--r-- 1 root root 283 27. Nov 22:05 gdk-pixbuf-2.0.pc
> -rw-r--r-- 1 root root 296 27. Nov 22:04 
> gdk-pixbuf-xlib-2.0.pc
> -rw-r--r-- 1 root root 322 27. Nov 22:05 gdk-x11-2.0.pc
> -rw-r--r-- 1 root root 406 28. Nov 03:44 gimp-2.0.pc
> -rw-r--r-- 1 root root 270 28. Nov 03:44 gimpthumb-2.0.pc
> -rw-r--r-- 1 root root 284 28. Nov 03:44 gimpui-2.0.pc
> -rw-r--r-- 1 root root 334 25. Nov 14:32 glib-2.0.pc
> -rw-r--r-- 1 root root 287 27. Nov 22:30 glibmm-2.4.pc
> -rw-r--r-- 1 root root 237 25. Nov 12:54 glib.pc
> -rw-r--r-- 1 root root 277 25. Nov 14:32 gmodule-2.0.pc
> -rw-r--r-- 1 root root 277 25. Nov 14:32 
> gmodule-export-2.0.pc
> -rw-r--r-- 1 root root 256 25. Nov 14:32 
> gmodule-no-export-2.0.pc
> -rw-r--r-- 1 root root 234 25. Nov 12:54 gmodule.pc
> -rw-r--r-- 1 root root 181 28. Nov 03:46 gnome-mount.pc
> -rw-r--r-- 1 root root 349 28. Nov 00:22 gnome-vfs-2.0.pc
> -rw-r--r-- 1 root root 403 28. Nov 00:22 
> gnome-vfs-module-2.0.pc
> -rw-r--r-- 1 root root 244 25. Nov 14:32 gobject-2.0.pc
> -rw-r--r-- 1 root root 239 25. Nov 14:32 gthread-2.0.pc
> -rw-r--r-- 1 root root 236 25. Nov 12:54 gthread.pc
> -rw-r--r-- 1 root root 346 27. Nov 22:05 gtk+-2.0.pc
> -rw-r--r-- 1 root root 180 27. Nov 23:09 gtk-engines-2.pc
> -rw-r--r-- 1 root root 312 27. Nov 22:58 gtkmm-2.4.pc
> -rw-r--r-- 1 root root 195 27. Nov 19:44 gtk+.pc
> -rw-r--r-- 1 root root 318 27. Nov 22:05 
> gtk+-unix-print-2.0.pc
> -rw-r--r-- 1 root root 346 27. Nov 22:05 gtk+-x11-2.0.pc
> -rw-r--r-- 1 root root 239 27. Nov 22:09 imlibgdk.pc
> -rw-r--r-- 1 root root 356 27. Nov 22:09 imlib.pc
> -rw-r--r-- 1 root root 414 25. Nov 15:58 libbonobo-2.0.pc
> -rw-r--r-- 1 root root 333 28. Nov 00:49 libgnome-2.0.pc
> -rw-r--r-- 1 root root 236 25. Nov 15:20 libIDL-2.0.pc
> -rw-r--r-- 1 root root 310 27. Nov 23:13 
> libmetacity-private.pc
> -rw-r--r-- 1 root root 358 25. Nov 15:32 ORBit-2.0.pc
> -rw-r--r-- 1 root root 304 25. Nov 15:32 
> ORBit-CosNaming-2.0.pc
> -rw-r--r-- 1 root root 308 25. Nov 15:31 ORBit-idl-2.0.pc
> -rw-r--r-- 1 root root 305 25. Nov 15:32 
> ORBit-imodule-2.0.pc
> -rw-r--r-- 1 root root 268 27. Nov 21:44 pangocairo.pc
> -rw-r--r-- 1 root root 289 27. Nov 21:44 pangoft2.pc
> -rw-r--r-- 1 root root 265 27. Nov 22:57 pangomm-1.4.pc
> -rw-r--r-- 1 root root 314 27. Nov 21:44 pango.pc
> -rw-r--r-- 1 root root 286 27. Nov 21:44 pangoxft.pc
> -rw-r--r-- 1 root root 260 27. Nov 21:44 pangox.pc
> -rw-r--r-- 1 root root 280 25. Nov 13:00 sigc++-2.0.pc
> -rw-r--r-- 1 root root 355 26. Nov 03:28 totem-plparser.pc
>
>
> but locate pygtk-2.0.pc returns nothing.
>
> How can I resolve this problem ?
>
> Nils
>
> 
Nils: Install the package that has pygtk-2.0.pc in it. 
(python-gtk-devel perhaps?).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Hi,
I have tried to install matplotlib on a x86_64 machine
using openSUSE10.2.
python setup.py yields
Package pygtk-2.0 was not found in the pkg-config search=20
path.
Perhaps you should add the directory containing=20
`pygtk-2.0.pc'
to the PKG_CONFIG_PATH environment variable
echo $PKG_CONFIG_PATH
/opt/gnome/lib64/pkgconfig
ls -l /opt/gnome/lib64/pkgconfig
insgesamt 208
-rw-r--r-- 1 root root 244 27. Nov 22:57 atkmm-1.6.pc
-rw-r--r-- 1 root root 259 27. Nov 19:36 atk.pc
-rw-r--r-- 1 root root 419 25. Nov 15:58=20
bonobo-activation-2.0.pc
-rw-r--r-- 1 root root 243 27. Nov 22:27 cairomm-1.0.pc
-rw-r--r-- 1 root root 276 27. Nov 22:24 gconf-2.0.pc
-rw-r--r-- 1 root root 264 28. Nov 03:37 gdict-1.0.pc
-rw-r--r-- 1 root root 322 27. Nov 22:05 gdk-2.0.pc
-rw-r--r-- 1 root root 321 27. Nov 22:57 gdkmm-2.4.pc
-rw-r--r-- 1 root root 262 27. Nov 19:44 gdk.pc
-rw-r--r-- 1 root root 283 27. Nov 22:05 gdk-pixbuf-2.0.pc
-rw-r--r-- 1 root root 296 27. Nov 22:04=20
gdk-pixbuf-xlib-2.0.pc
-rw-r--r-- 1 root root 322 27. Nov 22:05 gdk-x11-2.0.pc
-rw-r--r-- 1 root root 406 28. Nov 03:44 gimp-2.0.pc
-rw-r--r-- 1 root root 270 28. Nov 03:44 gimpthumb-2.0.pc
-rw-r--r-- 1 root root 284 28. Nov 03:44 gimpui-2.0.pc
-rw-r--r-- 1 root root 334 25. Nov 14:32 glib-2.0.pc
-rw-r--r-- 1 root root 287 27. Nov 22:30 glibmm-2.4.pc
-rw-r--r-- 1 root root 237 25. Nov 12:54 glib.pc
-rw-r--r-- 1 root root 277 25. Nov 14:32 gmodule-2.0.pc
-rw-r--r-- 1 root root 277 25. Nov 14:32=20
gmodule-export-2.0.pc
-rw-r--r-- 1 root root 256 25. Nov 14:32=20
gmodule-no-export-2.0.pc
-rw-r--r-- 1 root root 234 25. Nov 12:54 gmodule.pc
-rw-r--r-- 1 root root 181 28. Nov 03:46 gnome-mount.pc
-rw-r--r-- 1 root root 349 28. Nov 00:22 gnome-vfs-2.0.pc
-rw-r--r-- 1 root root 403 28. Nov 00:22=20
gnome-vfs-module-2.0.pc
-rw-r--r-- 1 root root 244 25. Nov 14:32 gobject-2.0.pc
-rw-r--r-- 1 root root 239 25. Nov 14:32 gthread-2.0.pc
-rw-r--r-- 1 root root 236 25. Nov 12:54 gthread.pc
-rw-r--r-- 1 root root 346 27. Nov 22:05 gtk+-2.0.pc
-rw-r--r-- 1 root root 180 27. Nov 23:09 gtk-engines-2.pc
-rw-r--r-- 1 root root 312 27. Nov 22:58 gtkmm-2.4.pc
-rw-r--r-- 1 root root 195 27. Nov 19:44 gtk+.pc
-rw-r--r-- 1 root root 318 27. Nov 22:05=20
gtk+-unix-print-2.0.pc
-rw-r--r-- 1 root root 346 27. Nov 22:05 gtk+-x11-2.0.pc
-rw-r--r-- 1 root root 239 27. Nov 22:09 imlibgdk.pc
-rw-r--r-- 1 root root 356 27. Nov 22:09 imlib.pc
-rw-r--r-- 1 root root 414 25. Nov 15:58 libbonobo-2.0.pc
-rw-r--r-- 1 root root 333 28. Nov 00:49 libgnome-2.0.pc
-rw-r--r-- 1 root root 236 25. Nov 15:20 libIDL-2.0.pc
-rw-r--r-- 1 root root 310 27. Nov 23:13=20
libmetacity-private.pc
-rw-r--r-- 1 root root 358 25. Nov 15:32 ORBit-2.0.pc
-rw-r--r-- 1 root root 304 25. Nov 15:32=20
ORBit-CosNaming-2.0.pc
-rw-r--r-- 1 root root 308 25. Nov 15:31 ORBit-idl-2.0.pc
-rw-r--r-- 1 root root 305 25. Nov 15:32=20
ORBit-imodule-2.0.pc
-rw-r--r-- 1 root root 268 27. Nov 21:44 pangocairo.pc
-rw-r--r-- 1 root root 289 27. Nov 21:44 pangoft2.pc
-rw-r--r-- 1 root root 265 27. Nov 22:57 pangomm-1.4.pc
-rw-r--r-- 1 root root 314 27. Nov 21:44 pango.pc
-rw-r--r-- 1 root root 286 27. Nov 21:44 pangoxft.pc
-rw-r--r-- 1 root root 260 27. Nov 21:44 pangox.pc
-rw-r--r-- 1 root root 280 25. Nov 13:00 sigc++-2.0.pc
-rw-r--r-- 1 root root 355 26. Nov 03:28 totem-plparser.pc
but locate pygtk-2.0.pc returns nothing.
How can I resolve this problem ?
Nils

On Thursday 04 January 2007 06:13, Sven Schreiber wrote:
> belinda thom schrieb:
> > A tangential question; recently I was looking for a way to save/load
> > numeric data (often so it could be used later for building plots). I
> > found load/save better documented than numpy's to/fromfile, so used
> > that. The question, from the responsibility point of view, however,
> > is where I should be going to get this functionality. Are both
> > equally "stable"? Also, since numpy borrows from matlab, I was
> > surprised that load/save is only provided via matplotlib's mlab.py
> > (its not in numpy's matlib.py).
>
> Maybe you know that already, but in scipy there is something like
> scipy.io.read_array and write_array which is very similiar to mpl's
> load/save (IIRC).
>
> IMHO something like that would be a welcome addition to numpy, but I
> have learned that adding features to numpy is quite controversial...
> (oh, we're on the mpl list right now, ok)
>
> In the end I wrote my own csv read and write functions (see post in
> other thread), because I didn't see why my code should depend on having
> scipy or mpl installed just because of 20 or 30 lines of code.
>
> (AFAIK numpy fromfile and tofile are for binary data, not text files.
> Don't know if you want that.)
You can use numpy's tofile and fromfile for text files, you just have to add a 
delimiter kwarg. However, fromfile only returns 1D arrays.

belinda thom schrieb:
> A tangential question; recently I was looking for a way to save/load 
> numeric data (often so it could be used later for building plots). I 
> found load/save better documented than numpy's to/fromfile, so used 
> that. The question, from the responsibility point of view, however, 
> is where I should be going to get this functionality. Are both 
> equally "stable"? Also, since numpy borrows from matlab, I was 
> surprised that load/save is only provided via matplotlib's mlab.py 
> (its not in numpy's matlib.py).
> 
Maybe you know that already, but in scipy there is something like
scipy.io.read_array and write_array which is very similiar to mpl's
load/save (IIRC).
IMHO something like that would be a welcome addition to numpy, but I
have learned that adding features to numpy is quite controversial...
(oh, we're on the mpl list right now, ok)
In the end I wrote my own csv read and write functions (see post in
other thread), because I didn't see why my code should depend on having
scipy or mpl installed just because of 20 or 30 lines of code.
(AFAIK numpy fromfile and tofile are for binary data, not text files.
Don't know if you want that.)
So if you never use numpy standalone, I'd say go for mpl's load/save.
cheers,
sven

Eric -
Yeah, I agree. The words 'equal' is confusing. But it was taken from matlab.
'scaled' was my invention/doing. I thought it was better than 'equal', as it
makes the scales equal on both axes. Either way, I would like it if we can
fix the data limits in a simple way, and I think incorporating it in
'scaled' would be one option. A new option would be a good idea too.
Something like 'scaledfixed' ? Maybe too long. Or just 'scaledf' ? Code is
simple:
 elif s == 'scaledf':
 self.set_aspect('equal', adjustable='box', anchor='C')
 self.set_autoscale_on(False)
Thanks,
Mark
On 1/3/07, Eric Firing <ef...@ha...> wrote:
>
> Mark Bakker wrote:
> > The enhanced way of handling aspect ratios that Eric implemented works
> > great.
> > There is, however, one change from the old implementation that I don't
> like.
> >
> > In the old implementation, when setting axis('scaled') it also turned
> > autoscale off.
> > This makes sense (and I used it a lot). It means that you can set the
> > axis('scaled'), which means the aspect ratios are set equal and the axis
> > limits are not changed, at any point when you like the data limits. The
> > axis limits are then fixed so that every time you add something else to
> > the figure it will keep these limits.
> >
> > In the new implementation (ok, it has been there for a little while
> > now), you have to give a separate set_autoscale_on(False) command.
> > Besides the odd name of the function (you actually turn the autoscale
> > off), it is a command that should be set right away by axis('scaled').
> > If you want the autoscale to remain on, you should use axis('equal')
>
> Here is the present code fragment (slightly mangled by the mailer):
>
> elif s in ('equal', 'tight', 'scaled', 'normal', 'auto',
> 'image'):
> self.set_autoscale_on(True)
> self.set_aspect('auto')
> self.autoscale_view()
> self.apply_aspect()
> if s=='equal':
> self.set_aspect('equal', adjustable='datalim')
> elif s == 'scaled':
> self.set_aspect('equal', adjustable='box',
> anchor='C')
> elif s=='tight':
> self.autoscale_view(tight=True)
> self.set_autoscale_on(False)
> elif s == 'image':
> self.autoscale_view(tight=True)
> self.set_autoscale_on(False)
> self.set_aspect('equal', adjustable='box',
> anchor='C')
>
> At present, the difference between "equal" and "scaled" is not the
> autoscale state but the "adjustable".
>
> I don't have any objection to changing the behavior of "scaled" as you
> suggest, if that is what people want. Alternatively, yet another word
> could be used to define the behavior you want, and that behavior could
> be added. I don't find "scaled" or "equal" very descriptive or
> intuitive; nor do I find that either word suggests how autoscale should
> be set. (And I agree, "set_autoscale_on(False)" is ugly.)
>
> Eric
>

Fernando Perez wrote:
> hopefully the responsibilities will be:
>
> - ipython -> interactive work
> - numpy/scipy -> numerics
> - matploblib -> plotting
>
On Jan 3, 2007, at 10:01 AM, Christopher Barker wrote:
I sure hope so too.
> Following these ideas, in my personal use I normally do:
>
> import numpy as N
> import scipy as S
> import pylab as P
> At this point, it isn't quite possible to use just matplotlib for
> interactive use, as pylab has the functionality to manage the figure
> windows, etc, so I do use a tiny bit of pylab there, but try to 
> keep to
> the OO interface otherwise.
A tangential question; recently I was looking for a way to save/load 
numeric data (often so it could be used later for building plots). I 
found load/save better documented than numpy's to/fromfile, so used 
that. The question, from the responsibility point of view, however, 
is where I should be going to get this functionality. Are both 
equally "stable"? Also, since numpy borrows from matlab, I was 
surprised that load/save is only provided via matplotlib's mlab.py 
(its not in numpy's matlib.py).
> THe key stumbling block is docs -- most of the docs and tutorials use
> the pylab interface, so it's a bit harder to figure out what to do. 
> This
> should help get you started:
Agreed.
> http://sourceforge.net/mailarchive/message.php?msg_id=11033442
I never found that on the wiki, and have spent some time looking thru 
it.
> (Did that ever get up on the Wiki?, and/or does anyone have other 
> pointers?)
As an experienced Matlab programmer, I have found
http://37mm.no/mpy/matlab-numpy.html
quite useful, but this isn't emphasizing the OO aspect of matplotlib.
>
> -Chris

Mark Bakker wrote:
> The enhanced way of handling aspect ratios that Eric implemented works 
> great.
> There is, however, one change from the old implementation that I don't like.
> 
> In the old implementation, when setting axis('scaled') it also turned 
> autoscale off.
> This makes sense (and I used it a lot). It means that you can set the 
> axis('scaled'), which means the aspect ratios are set equal and the axis 
> limits are not changed, at any point when you like the data limits. The 
> axis limits are then fixed so that every time you add something else to 
> the figure it will keep these limits.
> 
> In the new implementation (ok, it has been there for a little while 
> now), you have to give a separate set_autoscale_on(False) command.
> Besides the odd name of the function (you actually turn the autoscale 
> off), it is a command that should be set right away by axis('scaled'). 
> If you want the autoscale to remain on, you should use axis('equal')
Here is the present code fragment (slightly mangled by the mailer):
 elif s in ('equal', 'tight', 'scaled', 'normal', 'auto', 
'image'):
 self.set_autoscale_on(True)
 self.set_aspect('auto')
 self.autoscale_view()
 self.apply_aspect()
 if s=='equal':
 self.set_aspect('equal', adjustable='datalim')
 elif s == 'scaled':
 self.set_aspect('equal', adjustable='box', anchor='C')
 elif s=='tight':
 self.autoscale_view(tight=True)
 self.set_autoscale_on(False)
 elif s == 'image':
 self.autoscale_view(tight=True)
 self.set_autoscale_on(False)
 self.set_aspect('equal', adjustable='box', anchor='C')
At present, the difference between "equal" and "scaled" is not the 
autoscale state but the "adjustable".
I don't have any objection to changing the behavior of "scaled" as you 
suggest, if that is what people want. Alternatively, yet another word 
could be used to define the behavior you want, and that behavior could 
be added. I don't find "scaled" or "equal" very descriptive or 
intuitive; nor do I find that either word suggests how autoscale should 
be set. (And I agree, "set_autoscale_on(False)" is ugly.)
Eric

The enhanced way of handling aspect ratios that Eric implemented works
great.
There is, however, one change from the old implementation that I don't like.
In the old implementation, when setting axis('scaled') it also turned
autoscale off.
This makes sense (and I used it a lot). It means that you can set the
axis('scaled'), which means the aspect ratios are set equal and the axis
limits are not changed, at any point when you like the data limits. The axis
limits are then fixed so that every time you add something else to the
figure it will keep these limits.
In the new implementation (ok, it has been there for a little while now),
you have to give a separate set_autoscale_on(False) command.
Besides the odd name of the function (you actually turn the autoscale off),
it is a command that should be set right away by axis('scaled'). If you want
the autoscale to remain on, you should use axis('equal')
Anybody else an opinion? Andrea?
Thanks, Mark

Thanks for writing the convenience function John !
I think there is a large group (like the students in my class) who use
matplotlib as a simple tool to make beautiful graphs. To compete with matlab
we need to keep simple tasks simple. I personally think that this
convenience function is a good one to add. Probably under pylab.
Anybody else want to weigh in?
Mark
On 1/3/07, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
>
> Mark> Thanks John. This works great. I think, however, that
> Mark> set_backgroundcolor would be useful. It should be easy to
> Mark> fix. If nobody speaks up, I will take a crack at it, Mark
>
> What do you have in mind, a simple convenience function that does
>
> def set_backgroundcolor(self, color):
> """
> Set the background color of the text by updating the bbox
> facecolor
>
> ACCEPTS: any matplotlib color
> """
> if self._bbox is None:
> self._bbox = dict(facecolor=color, edgecolor=color)
> else:
> self._bbox.update(dict(facecolor=color))
>
> I'm not too opposed to it, but it does violate the maxim "There should be
> one--
> and preferably only one --obvious way to do it." Of course, we
> violate this throughout mpl offerings lots of convenience functions,
> but it is something to bear in mind.
>

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> Thanks John. This works great. I think, however, that
 Mark> set_backgroundcolor would be useful. It should be easy to
 Mark> fix. If nobody speaks up, I will take a crack at it, Mark
What do you have in mind, a simple convenience function that does
 def set_backgroundcolor(self, color):
 """
 Set the background color of the text by updating the bbox facecolor
 ACCEPTS: any matplotlib color 
 """
 if self._bbox is None: 
 self._bbox = dict(facecolor=color, edgecolor=color)
 else:
 self._bbox.update(dict(facecolor=color))
I'm not too opposed to it, but it does violate the maxim "There should be one--
and preferably only one --obvious way to do it." Of course, we
violate this throughout mpl offerings lots of convenience functions,
but it is something to bear in mind.

Thanks John. This works great.
I think, however, that set_backgroundcolor would be useful.
It should be easy to fix.
If nobody speaks up, I will take a crack at it,
Mark
On 1/3/07, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
>
> Mark> Hello - I want to set the backgroundcolor of text with the
> Mark> set_backgroundcolor function. Does that actually work? I
> Mark> saw a more complicated way to do it by defining a bbox, but
> Mark> this would be much easier (if I got it to work). Here's my
> Mark> example that doesn't work. Thanks for any suggestions,
>
> Strange. When I saw your post my first thought was "hmmm, I didn't
> know we had a text background color". I looked through the text.py
> code and it is there as a property, but is totally unused. I don't
> know who added it, but apparently someone got interrupted mid-code.
> That someone could be me, but if anyone knows where this came from
> speak up; otherwise it will be removed.
>
> The bbox is the standard way to do this, and is a bit more general
> since you can set the alpha, the linewidth, the edgecolor, etc...
>
> ax.text(1,2,'hi mom', bbox=dict(facecolor='red'))
>
> JDH
>

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> Hello - I want to set the backgroundcolor of text with the
 Mark> set_backgroundcolor function. Does that actually work? I
 Mark> saw a more complicated way to do it by defining a bbox, but
 Mark> this would be much easier (if I got it to work). Here's my
 Mark> example that doesn't work. Thanks for any suggestions,
Strange. When I saw your post my first thought was "hmmm, I didn't
know we had a text background color". I looked through the text.py
code and it is there as a property, but is totally unused. I don't
know who added it, but apparently someone got interrupted mid-code.
That someone could be me, but if anyone knows where this came from
speak up; otherwise it will be removed.
The bbox is the standard way to do this, and is a bit more general
since you can set the alpha, the linewidth, the edgecolor, etc...
 ax.text(1,2,'hi mom', bbox=dict(facecolor='red'))
JDH

Hello -
I want to set the backgroundcolor of text with the set_backgroundcolor
function.
Does that actually work?
I saw a more complicated way to do it by defining a bbox, but this would be
much easier (if I got it to work).
Here's my example that doesn't work.
Thanks for any suggestions,
Mark
from pylab import *
plot([1,2,3])
t = text(1,2,'Hello')
t.set_backgroundcolor('r')
draw()

Fernando and Eric have offered very nice explanations, but I have one 
thing to add:
Fernando Perez wrote:
> hopefully the responsibilities will be:
> 
> - ipython -> interactive work
> - numpy/scipy -> numerics
> - matploblib -> plotting
I sure hope so too.
> Following these ideas, in my personal use I normally do:
> 
> import numpy as N
> import scipy as S
> import pylab as P
I do something very similar - I really believe in namespaces, "import *" 
is a "bad idea".
However, I also try to avoid pylab altogether, in favor of:
import matplotlib as MPL,
MPL.PlottingStuff()
matplotlib provides the plotting functionality in a nice OO way. pylab 
is essentially a wrapper that provides a Matlab-like procedural 
interface to matplotlib. For me, one of the reasons I use python, rather 
than Matlab is that it is a richer, more feature-full language, 
including OO. Some folks think the procedural approach is better for 
interactive use, but I'm not so sure, and I'm quite sure that the OO 
approach is better for "real programs"
At this point, it isn't quite possible to use just matplotlib for 
interactive use, as pylab has the functionality to manage the figure 
windows, etc, so I do use a tiny bit of pylab there, but try to keep to 
the OO interface otherwise.
THe key stumbling block is docs -- most of the docs and tutorials use 
the pylab interface, so it's a bit harder to figure out what to do. This 
should help get you started:
http://sourceforge.net/mailarchive/message.php?msg_id=11033442
(Did that ever get up on the Wiki?, and/or does anyone have other pointers?)
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

This should help you understand dpi, font-size, etc.
http://www.scipy.org/Cookbook/Matplotlib/AdjustingImageSize
However, I'm not sure how imshow() and SVG work together -- SVG is just 
that -- "Scalable", it doesn't have a set resolution, and I don't know 
what happens when you embed a raster graphic in it -- can someone offer 
an explanation of what MPL does with imshow and SVG?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Yo,
> 1) multiple y-scales on the left and right. mpl supports a left and
> right scale (see examples/two_scale.py) but nothing like an
> arbitrary number of scales with arbitrary positioning as you see
> in the plot you attached. This has long been on the wish list
> (and is on the goals web page) but has not yet been implemented.
> This is something chaco does quite well because it is very common
> to make these plots in geophysics. For me it is one of the few
> remaining must-have features for matplotlib 1.0. You could hack
> your own scales using matplotlib lines and text instances. Indeed
> it wouldn't be too hard and if I get some time I'll do a demo
> which may serve as a prototype for refactoring the mpl axis code.
I remember that, for a paper, I succeeded to plot two horizontal 
axis, on the bottom of the plot (see the image in attachment)
The difference with my previous mail is that the second axis (labeled 
'compression ratio') is not used for plotting. It is, actually, the 
same than the other axis (labeled 'filter size') but it gives another 
scale/kind of information.
Here is my (very ugly) code:
from pylab import *
from matplotlib.font_manager import *
list = [0.78125356, 0.78125356, 0.78125356, 0.78125356, 0.78125356, 
0.78125356, 0.78125356, 0.78125356, 0.78125356, 0.78125356]
yprops = dict(rotation=0, 
horizontalalignment='right',verticalalignment='center',x=-0.01)
axprops = dict(yticks=[])
rc('text', usetex=True)
rc('lines', markersize=16)
rc('legend', numpoints=3)
#getting data from different source files
tabBF = load('Data/Compact/BFCompact.dat')
tabRBF1 = load('Data/Compact/RBFCompact0.01.dat')
tabRBF2 = load('Data/Compact/RBFCompact0.25.dat')
tabRBF3 = load('Data/Compact/RBFCompact0.05.dat')
tabRBF4 = load('Data/Compact/RBFCompact0.1.dat')
xAxis = tabBF[:,0]
succBF = tabBF[:,1]
succRBF1 = tabRBF1[:,1]
succRBF2 = tabRBF2[:,1]
succRBF3 = tabRBF3[:,1]
succRBF4 = tabRBF4[:,1]
fig = figure(1)
#plot the figure
ax1 = fig.add_axes([0.1,0.2,0.8,0.75])
llist = ax1.plot(xAxis, list, 'k-', linewidth=1.5)
bf = ax1.plot(xAxis, succBF, 'k-x', linewidth=1.5)
rbf1 = ax1.plot(xAxis, succRBF1, 'r-d', linewidth=1.5)
rbf2 = ax1.plot(xAxis, succRBF2, 'b-^', linewidth=1.5)
rbf3 = ax1.plot(xAxis, succRBF3, 'g-<', linewidth=1.5)
rbf4 = ax1.plot(xAxis, succRBF4, 'm-o', linewidth=1.5)
axis([9, 101, -0.01, 1.01], font)
ax1.set_xlabel(r'\textbf{filter size (x 10}$^\mathbf{3}$\textbf{)}', 
font)
ax1.set_ylabel(r'\textbf{success rate}', font)
#ugly way of drawing the legend legend
leg = legend((llist[0], rbf2[0],rbf4[0], rbf3[0], rbf1[0], bf[0]), 
(r'\textbf{list}', r'\textbf{rbf -} $\beta$\textbf{=25\%}', r'\textbf 
{rbf -} $\beta$\textbf{=10\%}',r'\textbf{rbf - }$\beta$\textbf{=5\ 
%}', r'\textbf{rbf - }$\beta$\textbf{=1\%}', r'\textbf{bf}'), loc= 
(0.65,0.23), prop=FontProperties(size='26', weight='bold'))#leg = 
legend((llist[0], bf[0]), (r'\textbf{list}', r'\textbf{bf}'), loc= 
(0.65,0.23), prop=FontProperties(size='26', weight='bold'))
leg.draw_frame(False)
#draw the second x-axis
ax2 = fig.add_axes([0.1,0.1,0.8,0.01], **axprops)
ax2.set_xlabel(r'\textbf{compression ratio}', font)
toto = ['25.6', '12.8', '8.5', '6.4', '5.1', '4.2', '3.6', '3.2', 
'2.8', '2.5']
ax2.get_xaxis().set_ticks(arange(10))
ax2.get_xaxis().set_ticklabels(toto)
savefig('Success3')
This is clearly a hack (and I'm not very proud of it :-( ).
Benoit

>>>>> "Benoit" == Benoit Donnet <do...@in...> writes:
 Benoit> Do you think it is possible to do such a plot in
 Benoit> matplotlib?
Hey Benoit -- thanks for posting that image. It's good to get some
reminders of the current limitations of mpl so we can focus on
improving them. There are two things in that plot that mpl cannot
currently do.
 1) multiple y-scales on the left and right. mpl supports a left and
 right scale (see examples/two_scale.py) but nothing like an
 arbitrary number of scales with arbitrary positioning as you see
 in the plot you attached. This has long been on the wish list
 (and is on the goals web page) but has not yet been implemented.
 This is something chaco does quite well because it is very common
 to make these plots in geophysics. For me it is one of the few
 remaining must-have features for matplotlib 1.0. You could hack
 your own scales using matplotlib lines and text instances. Indeed
 it wouldn't be too hard and if I get some time I'll do a demo
 which may serve as a prototype for refactoring the mpl axis code.
 2) the horizontal legend layout - matplotlib is not very flexible in
 the legend layout and supports only vertical legends. This would
 be a nice feature. Currently the legend code can best be
 described as hairy, which is why few want to try to improve it.
As for the text table at the bottom, you could either do this with
table, probably your best choice, or with a series of side-by-side
axes, or with some custom rectangles and text instances. We've talked
before that it would be nice to have a layout engine, much like the
gtk hbox and vbox, and this would be a good candidate for it.
JDH

Hi all,
First of all, best wishes for the brand new year! I hope that 2007 
will be a great year for all of you.
Attached to this mail, there is an image representing a 'complex 
plot'. this is complex because it contains a lot of information 
(plot + table below the plot). I think the plot + table is not so 
difficult to do using matplotlib (the example table_demo.py should 
give an idea of the solution).
What is, in my opinion more is:
- the fact that the plot contains 6 vertical axis (three on the left 
and three on the right).
- the legend is above the plot and is composed of color boxes that 
refer to a given axis and line on the plot.
Do you think it is possible to do such a plot in matplotlib?
Thanks in advance for any kind of help and thanks again for the 
matplotlib library!
Best regards.
Benoit

Eric, John - thanks for your tips, it works!
petr
On Tue, 2007年01月02日 at 21:01, Eric Firing wrote:
> John Hunter wrote:
> Examples of the shrink kwarg are examples/image_masked.py and 
> examples/contour_demo.py.
> 
> As an alternative to using the shrink kwarg you can always specify axes 
> positions manually. One example is in examples/multi_image.py. 
> Attached is another example modified from image_masked.py.
>
> I have added a bit to the docstring to emphasize the function of the 
> shrink kwarg. This will usually be the easiest manual solution to the 
> problem. I have also thought a bit about adding functionality to the 
> axes.draw() method that would allow the colorbar height to track the 
> height of the mappable axes object; maybe I will try it later.
> 

belinda thom wrote:
> Hi,
> 
> Is there a way for me to keep adding the next row of a 2d array to a 
> file via load? (matlab's save had a very useful -append option).
> 
> I managed to get 2d laod/save working, e.g.
> 
> import numpy as N
> import pylab as P
> import bthom.utils as U
> # a numpy 2d array
> a = N.arange(12,dtype=N.float).reshape((3,4))
> a[0][0] = N.pi
> # checking out the matploblib save/load stuff
> P.save("data.csv", a, fmt="%.4f", delimiter=";")
> aa = P.load("data.csv", delimiter= ";")
> x,y,z,w = P.load("data.csv", delimiter=";", unpack=True)
> 
> The above took me longer than it perhaps should have b/c of advice 
> I'd gotten elsewhere recommending trying to keep numpy and pylab 
> separate when possible (to take advantage of all of numpy's features; 
> it seems numpy doesn't even have the all-to-handy load/save 
> functionality).
> 
> When I try similar tricks to write one row at a time, I'm hosed in 
> that the shape is gone:
> 
> # checking out a way to keep appending
> fname = "data1.csv"
> U.clobber_file(fname) #this thing just ensures 0 bytes in file
> f = open(fname,"a")
> nrows,ncols = a.shape
> for i in range(nrows) :
> P.save(f, a[i,:], fmt="%d", delimiter=";")
> f.close()
> aaa = P.load("data1.csv", delimiter= ";")
> 
> in particular:
> 
> % cat data1.csv
> 3
> 1
> 2
> 4
> <snip>
> 11
> 
> Thanks in advance,
> --b
> 
This is because pylab.save() writes every 1D-array (like a[i,:]) as 
"column vector". In the definition of the save() function:
[...]
 if len(X.shape)==1:
 origShape = X.shape
 X.shape = len(X), 1
[...]
This reshapes the 1D-array (len(a[i,:].shape) == 1) to a 2D-array of 
shape Nx1 and a loop over the first axis writes the rows (in this case 
one element per row) to file.
There are several ways to do what you want:
#-----------------------------------------------------------------------#
# generate data
a = N.arange(12,dtype=N.float).reshape((3,4))
a[0][0] = N.pi
P.save("data.csv", a, fmt="%.4f", delimiter=";")
# (A)
# rather hackish way, define your own save(), not
# really useful, just to show that it works
def save2(fname, X, fmt='%.18e',delimiter=' '):
 if is_string_like(fname):
 if fname.endswith('.gz'):
 import gzip
 fh = gzip.open(fname,'wb')
 else:
 fh = file(fname,'w')
 elif hasattr(fname, 'seek'):
 fh = fname
 else:
 raise ValueError('fname must be a string or file handle')
 X = N.asarray(X)
 origShape = None
 if len(X.shape)==1:
 origShape = X.shape
# >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
## X.shape = len(X), 1
 X.shape = 1, len(X)
# <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 for row in X:
 fh.write(delimiter.join([fmt%val for val in row]) + '\n')
 if origShape is not None:
 X.shape = origShape
fname = "data1.csv"
f = open(fname,"a")
nrows,ncols = a.shape
for i in range(nrows) :
 save2(f, a[i,:], fmt="%f", delimiter=";")
f.close()
aaa = P.load("data1.csv", delimiter= ";")
print aaa
print "-----------------------"
# (B)
# do it without a save() function
fname = "data2.csv"
f = open(fname,"a")
nrows,ncols = a.shape
delim = ';'
fmt = '%f'
for i in range(nrows):
 # just like in pylab.save()
 f.write(delim.join([fmt %val for val in a[i,:]]) + '\n')
f.close()
aaa = P.load("data2.csv", delimiter= ";")
print aaa
print "-----------------------"
# (C)
# probably the best: save a 1xn "row vector" per line
fname = "data3.csv"
f = open(fname,"a")
nrows,ncols = a.shape
for i in range(nrows) :
 P.save(f, a[i,:].reshape((1,ncols)), fmt="%f", delimiter=";")
f.close()
aaa = P.load("data3.csv", delimiter= ";")
print aaa
HTH
-- 
cheers,
steve
Random number generation is the art of producing pure gibberish as 
quickly as possible.

Hi,
Is there a way for me to keep adding the next row of a 2d array to a 
file via load? (matlab's save had a very useful -append option).
I managed to get 2d laod/save working, e.g.
 import numpy as N
 import pylab as P
 import bthom.utils as U
 # a numpy 2d array
 a = N.arange(12,dtype=N.float).reshape((3,4))
 a[0][0] = N.pi
 # checking out the matploblib save/load stuff
 P.save("data.csv", a, fmt="%.4f", delimiter=";")
 aa = P.load("data.csv", delimiter= ";")
 x,y,z,w = P.load("data.csv", delimiter=";", unpack=True)
The above took me longer than it perhaps should have b/c of advice 
I'd gotten elsewhere recommending trying to keep numpy and pylab 
separate when possible (to take advantage of all of numpy's features; 
it seems numpy doesn't even have the all-to-handy load/save 
functionality).
When I try similar tricks to write one row at a time, I'm hosed in 
that the shape is gone:
 # checking out a way to keep appending
 fname = "data1.csv"
 U.clobber_file(fname) #this thing just ensures 0 bytes in file
 f = open(fname,"a")
 nrows,ncols = a.shape
 for i in range(nrows) :
 P.save(f, a[i,:], fmt="%d", delimiter=";")
 f.close()
 aaa = P.load("data1.csv", delimiter= ";")
in particular:
 % cat data1.csv
 3
 1
 2
 4
 <snip>
 11
Thanks in advance,
--b

Hi,
The documentation for pylab.load mentions the load_demo.py example.
I can't find this on my distribution. I believe all Pylab examples 
live in site-packages/doc/matplotlib, for in there are files like 
log_demo.py (the only file that begins with load is 
load_converter.py, which is demonstrating using dates).
Does anyone have access to load_demo.py or does it not exist (in 
which case the documentation for load should be modified)?
Thanks,
--b

John Hunter wrote:
>>>>>> "Petr" == Petr Danecek <da...@uc...> writes:
[...]
> Petr> 2) When set_aspect() is used, the size of colorbar does not
> Petr> respect y-dimension of the graph. (See the attached
> Petr> example.) Is it possible to set the size of the colorbar
> Petr> directly?
Examples of the shrink kwarg are examples/image_masked.py and 
examples/contour_demo.py.
As an alternative to using the shrink kwarg you can always specify axes 
positions manually. One example is in examples/multi_image.py. 
Attached is another example modified from image_masked.py.
> 
> One of the examples shows how to do this if I recall correctly, but I
> don't remember which one. Eric Firing wrote it so I'm sure he'll be
> along shortly to point you to the light. Eric -- perhaps we should
> also add a snippet to the colorbar docstring since this is a common
> request.
I have added a bit to the docstring to emphasize the function of the 
shrink kwarg. This will usually be the easiest manual solution to the 
problem. I have also thought a bit about adding functionality to the 
axes.draw() method that would allow the colorbar height to track the 
height of the mappable axes object; maybe I will try it later.
Eric