matplotlib-users Mailing List for matplotlib

>>>>> "Sarah" == Sarah Mount <mou...@gm...> writes:
 Sarah> Ah! Well, I guess I just didn't read the doc's
 Sarah> properly. pylab.close() seems to do the
 Sarah> trick. Interestingly, the amount of garbage still seems to
 Sarah> grow monotonically, but much, much slower and everything
 Sarah> seems to be kept in memory and not swap.
Or perhaps the docs just weren't explicit enough!
I added the following to the pylab.figure docstring:
 If you are creating many figures, make sure you explicitly call "close"
 on the figures you are not using, because this will enable pylab
 to properly clean up the memory.
JDH

On 07/03/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Sarah" =3D=3D Sarah Mount <mou...@gm...> writes:
>
> Sarah> Hi all, is there some way to clean up all the memory used
> Sarah> by matplotlib? I currently have a script which creates a
> Sarah> bunch of plots and it seems to use an increasing amount of
> Sarah> memory until my m/c runs out of memory and swap space. I'm
> Sarah> forcing the gc to collect after every plot is generated
> Sarah> (and saved to disc) and that doesn't help. Looking through
> Sarah> the list of types that the gc is holding it seems like the
> Sarah> vast majority of them are objects generated by
> Sarah> matplotlib. I'm pretty sure now that it's not an issue with
> Sarah> the data structures I'm creating, so ... any ideas?
>
> Are you using pylab? If so, most likely you are creating but not
> closing figures. You need to pair every use of pylab figure with a
> pylab close. Feel free to post an example script.
Ah! Well, I guess I just didn't read the doc's properly. pylab.close()
seems to do the trick. Interestingly, the amount of garbage still
seems to grow monotonically, but much, much slower and everything
seems to be kept in memory and not swap.
Thanks for such a speedy response!
Sarah
--
http://www.mis.coventry.ac.uk/research/imd/
http://varspool.blogspot.com

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> Good -- this indicated matplotlib proper is not leaking, so
 John> it is a figure management problem. You may want to inspect
 John> _pylab_helpers to see if it is storing references you don't
 John> want it to.
Here is a little demo to help you if you want to poke into the pylab
helpers data structures. Note you should not manipulate these
structures directly, but through the pylab API
In [2]: import matplotlib._pylab_helpers as ph
In [3]: ph.Gcf.figs
Out[3]: {}
In [4]: figure()
Out[4]: <matplotlib.figure.Figure instance at 0xb5b91e4c>
In [5]: ph.Gcf.figs
Out[5]: {1: <matplotlib.backends.backend_gtkagg.FigureManagerGTKAgg
instance at 0xb5b91f4c>}
In [6]: figure()
Out[6]: <matplotlib.figure.Figure instance at 0xb5b9180c>
In [7]: ph.Gcf.figs
Out[7]:
{1: <matplotlib.backends.backend_gtkagg.FigureManagerGTKAgg instance
at 0xb5b91f4c>,
 2: <matplotlib.backends.backend_gtkagg.FigureManagerGTKAgg instance
 at 0xb5b91b4c>}
In [8]: close(1)
In [9]: ph.Gcf.figs
Out[9]: {2: <matplotlib.backends.backend_gtkagg.FigureManagerGTKAgg
instance at 0xb5b91b4c>}
JDH

>>>>> "Sarah" == Sarah Mount <mou...@gm...> writes:
 Sarah> Hi all, is there some way to clean up all the memory used
 Sarah> by matplotlib? I currently have a script which creates a
 Sarah> bunch of plots and it seems to use an increasing amount of
 Sarah> memory until my m/c runs out of memory and swap space. I'm
 Sarah> forcing the gc to collect after every plot is generated
 Sarah> (and saved to disc) and that doesn't help. Looking through
 Sarah> the list of types that the gc is holding it seems like the
 Sarah> vast majority of them are objects generated by
 Sarah> matplotlib. I'm pretty sure now that it's not an issue with
 Sarah> the data structures I'm creating, so ... any ideas?
Are you using pylab? If so, most likely you are creating but not
closing figures. You need to pair every use of pylab figure with a
pylab close. Feel free to post an example script.
 Sarah> If it helps, I'm using matplotlib 0.87 on Fedora Core 4
 Sarah> with numpy 0.9.5. I've run the memory test code in
 Sarah> http://matplotlib.sourceforge.net/faq.html#LEAKS and got
 Sarah> the following:
 Sarah> Average memory consumed per loop: -0.1083k bytes
Good -- this indicated matplotlib proper is not leaking, so it is a
figure management problem. You may want to inspect _pylab_helpers to
see if it is storing references you don't want it to.
Another alternative is to not use pylab for figure management. The
best approach here depends on what kinds of batch figures you are
trying to create (GUI vs hardcopy).
JDH

Hi all,
is there some way to clean up all the memory used by matplotlib? I
currently have a script which creates a bunch of plots and it seems to
use an increasing amount of memory until my m/c runs out of memory and
swap space. I'm forcing the gc to collect after every plot is
generated (and saved to disc) and that doesn't help. Looking through
the list of types that the gc is holding it seems like the vast
majority of them are objects generated by matplotlib. I'm pretty sure
now that it's not an issue with the data structures I'm creating, so
... any ideas?
If it helps, I'm using matplotlib 0.87 on Fedora Core 4 with numpy
0.9.5. I've run the memory test code in
http://matplotlib.sourceforge.net/faq.html#LEAKS and got the
following:
Average memory consumed per loop: -0.1083k bytes
Many thanks!
Sarah
--
http://www.mis.coventry.ac.uk/research/imd/
http://varspool.blogspot.com

>>>>> "mike" == mike cantor <mc...@st...> writes:
 mike> Hi, I'd like to use the colormap interface in a different
 mike> way than it's used in plotting images. I am plotting a
 mike> series of curves (using regular old plot), each of which
 mike> corresponds to the behavior of a biological circuit under a
 mike> different level of "inducer", ranging from around 0-100. I
 mike> want to assign the color of each line according to the
 mike> inducer value, and I want to try out different colormaps to
 mike> see which I like best.
 mike> All I really want is a method that, for a given colormap
 mike> (jet, pink, hot, hsv, etc), takes a number between 0,1 as
 mike> input and returns the corresponding RGB value, which I can
 mike> then use a 'color' argument in a plotting command. (I was
In [6]: import matplotlib.cm as cm
In [7]: cm.jet(.5)
Out[7]: (0.49019607843137247, 1.0, 0.47754585705249841, 1.0)
 mike> sort of hoping that the colormap object itself would provide
 mike> such a method but I couldn't find any description of it's
 mike> interface).
The class documentation is available at
 http://matplotlib.sourceforge.net/classdocs.html
in particular, take a look at
 http://matplotlib.sourceforge.net/matplotlib.colors.html#LinearSegmentedColormap
"jet" in the example above, is an instance of the
LinearSegmentedColormap colormap class, and the __call__ method
returns the data you are interested in for scalars or sequences.
JDH

>>>>> "steve" == steve schmerler <me...@gm...> writes:
 steve> No, all capital greek letters are upright.
This looks like a mathtext bug then. To fix it, you need to update
the entries in _mathtext_data.py. In that file there is a dictionary 
mapping symbol names to fontnames, glyphindex, eg for \Omega
 r'\Omega' : ('cmmi10', 23),
as you can see, we are pulling it from the italics file. What you
need to do is find out which cm* font file contains the Omega you
want, and what the glyph index of Omega is. There is a comment in the
_mathtext_data file that gives some guidance, namely
# this dict maps symbol names to fontnames, glyphindex. To get the
# glyph index from the character code, you have to use a reverse
# dictionary grom font.get_charmaps, eg,
"""
from matplotlib.ft2font import FT2Font
font = FT2Font('/usr/lib/python2.4/site-packages/matplotlib/mpl-data/cmr10.ttf')
codes = font.get_charmap().items()
rd = dict([(charcode, glyphind) for glyphind,charcode in codes])
items = rd.items()
items.sort()
for charcode, glyphind in items:
 print charcode, glyphind
"""
So if you know the character code of the glyph you want, you can use
this code to get the right glyph index.
If you would like to take a stab at fixing these for the upper case
greek letters, that would be great.
Thanks,
JDH

Hi,
I'd like to use the colormap interface in a different way than it's used in 
plotting images. I am plotting a series of curves (using regular old 
plot), each of which corresponds to the behavior of a biological circuit 
under a different level of "inducer", ranging from around 0-100. I want to 
assign the color of each line according to the inducer value, and I want to 
try out different colormaps to see which I like best.
All I really want is a method that, for a given colormap (jet, pink, hot, 
hsv, etc), takes a number between 0,1 as input and returns the 
corresponding RGB value, which I can then use a 'color' argument in a 
plotting command. (I was sort of hoping that the colormap object itself 
would provide such a method but I couldn't find any description of it's 
interface).
Any ideas?
Thanks,
-mike

>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:
 Christopher> However, John's version is pretty nice too:
 Christopher> fig = pylab.figure(1) ax = fig.add_subplot(111,
 Christopher> xlim=(-0.25,2.0), ylim=(0.0,1.3), aspect=('scaled',
 Christopher> True), autoscale_on=False) ax.plot((0,.2,.3,.4,1.5),
 Christopher> (0,.5,.3,.92,.48))
 Christopher> keyword arguments are very pythonic!
The downside of having to use kwargs like this is that you have to
know about them in advance.
We could support
 ax.xlim = 0,1
Simply by defining the appropriate __getattr__ and __setattr__
functions with the existing code base in just a few lines of code.
There would be a couple of cases where we might see some name clashes
but there wouldn't be many, and we could easily fix these and
deprecate the old usage.
If you want to take a stab at this, I think it would be preferable
to writing "another interface". Better to improve the OO interface we
have....
The heavy reliance on setters and getters dates to the fact that I was
a C++ programmer before I was a python programmer, and I wrote
matplotlib fairly early into my diving into python. I started writing
it around python2.1 and python properties were not yet part of the
language. So historically that is why we have our own hacked up
version of properties based on these setters and getters. Since there
is a lot of code built around them at this point (particularly for
those doing a lot of OO matplotlib including yours truly) I am
hesitant to completely break it. 
We have talked many times about doing something different, namely we
came very close to using enthought traits at one point, but hesitated
to pull the final trigger because they hadn't publicly released it and
there was no public user base so we weren't sure what the support
would be going forward. There has now been a public release but as
far as I know no widespread community adoption yet.
My inclination at this point is to take the path of least resistance
and simply make properties out of the existing setters and getters. I
think we could use python properties for this or do our own
getattr/setattr magic. I would also be amenable to using traits.
JDH

Hi
I have an issue that's really driving me crazy. I reported this for 
various recent mpl versions and I really hope someone has any hint as to 
what might cause this:
Some time ago I installed (Debian sarge) the mpl 0.82 .debs
(by placing deb http://anakonda.altervista.org/debian packages/ in my
/etc/apt/sources.list) .
Now I wanted to make a "clean" install of the recent mpl (svn 0.87.1). 
So what I did was deinstalling the debs
	dpkg -l | grep matplotlib
	dpkg -P <all mpl packages>
and then removing everything else left which is related to mpl:
	updatedb
	locate matplotlib
	rm -r <stuff>
After that I installed 0.87.1 as usual (python setup.py build/install).
Now testing my fresh install
	ipython -pylab
	plot([1,2,3])
	xlabel("lala")
I found the xlabel not centered but on the leftmost side of the axis.
My current "workarround" is to install the 0.82 debs *first* and the 
recent version (from source) afterwards *without* deinstalling the 0.82 
packages. If I do this the problem goes away!?
Is 0.82 writing some (config) files that 0.87.1 should not read but
does? Thanks for any hint.
cheers,
steve
-- 
Random number generation is the art of producing pure gibberish as 
quickly as possible.

Helge -
You are absolutely right. When you resize the window, the scale gets
messed-up. It can be fixed by giving the axis('scaled') command again, but
it is a thorn in my eye.
What we need is some kind of event handler for a window resize.
Is there event handling built in the backend-basics that keeps track of
whether a window gets resized? Shouldn't there be an event handler for
window-resized?
I am mostly interested in Tkinter. Anybody know that the event is?
Thanks,
Mark
--__--__--
>
> Hi,
> I miss the equivalent to "axis image" in matlab, axis('scaled') is
> very close to beeing
> the same except it does not preserve figure axis ranges and ratio when
> I resize my window.
>
> what methods are called after a window resize event in gtkagg anyway?
>
> Helge
>
>

Hi,
I agree with you that it'll be better to use only pythonic stuff instead 
matlab but there are a lack of information to do it. It's sometimes 
difficult to find any informatin to use correctly matplotlib with an OO 
approach especially when you don't know very well python and the OO 
programmation.
N.
Christopher Barker wrote:
> Nikolai Hlubek wrote:
>> Christopher Barker wrote:
>
>>> Using the OO interface everywhere would make the whole thing more
>>> consistent:
>
>> If a procedural interface is provided whats wrong with using it?
>
> If you ask me, it never should have been provided! But the question 
> here is: do we want to add more and more to pylab, until it replicates 
> all the OO functionality -- I think not. But then, if we don't, then 
> you get the situation you've encountered, having to occasionally drop 
> into the OO interface to do more advanced things.
>
> That's why I think encouraging people to use pylab is not such a great 
> idea. I have an example of this taken to the extreme-- A colleague of 
> mine wrote a bunch of fairly involved pylab-based code to create PNG 
> plots. Later, he decided to put them into a wxPython app, but you 
> can't use pylab embedded in wxPython, so he ended up creating the 
> PNGs, then loading them into wxPython from disk. If he had just used 
> the OO interface to begin with, he'd have had a very easy time 
> adapting it to embedded use. (it's still not that hard, but there is a 
> perceived big distinction)
>
>> And besides, who uses an interface which reminds of disposal of bodily
>> wastes? ;-)
>
> You do have a point there. Unfortunately, the pylab interface was 
> designed with usability in mind, while the OO interface, less so. 
> However, the reason I use python rather than matlab is that I like the 
> language much better, and this means (among other things):
>
> name spaces
> OO
>
> I've toyed with the idea of writing yet another interface to MPL that 
> would be as pythonic (rather than Matlabish) as possible. Your example 
> might look something like this:
>
> import OOlab
>
> fig = OOlab.figure(1)
> ax = fig.subplot(111)
>
> ax.limits = (-0.25, 2.0, 0.0, 1.3)
> ax.aspect = 'scaled'
> ax.autoscale = False
> ax.plot((0,.2,.3,.4,1.5), (0,.5,.3,.92,.48))
>
>
> key here is using name spaces and properties....
>
> However, John's version is pretty nice too:
>
> fig = pylab.figure(1)
> ax = fig.add_subplot(111,
> xlim=(-0.25,2.0), ylim=(0.0,1.3),
> aspect=('scaled', True), autoscale_on=False)
> ax.plot((0,.2,.3,.4,1.5), (0,.5,.3,.92,.48))
>
> keyword arguments are very pythonic!
>
> -Chris
>
>
>

John Hunter wrote:
>>>>>>"Darren" == Darren Dale <dd...@co...> writes:
> 
> 
> Darren> As I mentioned for Ryan's question, try manually
> Darren> positioning your axes to leave enough room for your axes
> Darren> labels in the figure window.
> 
> Yep. We don't use any smarts to make sure text doesn't get clipped
> off the bottom. Raise the bottom of your subplot by adjusting the
> "bottom" of the subplot params
> 
> figure.subplot.bottom : 0.1 # the bottom of the subplots of the figure
> 
> You can either adjust the rc param, or use the subplots_adjust command
> 
> See examples ganged_plots.py and subplots_adjust.py
> 
Hmmm OK, I'll have a look. Thanks.
> >> 2) Is it possible for the "\Omega" in "image_omega.png" to be
> >> upright (like it would be for usetex=True) and not inclined?
> 
> It probably is possible. Does TeX not use an italicized \Omega in
> math mode?
> 
No, all capital greek letters are upright.
cheers,
steve

Nikolai Hlubek wrote:
> Christopher Barker wrote:
>> Using the OO interface everywhere would make the whole thing more
>> consistent:
> If a procedural interface is provided whats wrong with using it?
If you ask me, it never should have been provided! But the question here 
is: do we want to add more and more to pylab, until it replicates all 
the OO functionality -- I think not. But then, if we don't, then you get 
 the situation you've encountered, having to occasionally drop into the 
OO interface to do more advanced things.
That's why I think encouraging people to use pylab is not such a great 
idea. I have an example of this taken to the extreme-- A colleague of 
mine wrote a bunch of fairly involved pylab-based code to create PNG 
plots. Later, he decided to put them into a wxPython app, but you can't 
use pylab embedded in wxPython, so he ended up creating the PNGs, then 
loading them into wxPython from disk. If he had just used the OO 
interface to begin with, he'd have had a very easy time adapting it to 
embedded use. (it's still not that hard, but there is a perceived big 
distinction)
> And besides, who uses an interface which reminds of disposal of bodily
> wastes? ;-)
You do have a point there. Unfortunately, the pylab interface was 
designed with usability in mind, while the OO interface, less so. 
However, the reason I use python rather than matlab is that I like the 
language much better, and this means (among other things):
name spaces
OO
I've toyed with the idea of writing yet another interface to MPL that 
would be as pythonic (rather than Matlabish) as possible. Your example 
might look something like this:
import OOlab
fig = OOlab.figure(1)
ax = fig.subplot(111)
ax.limits = (-0.25, 2.0, 0.0, 1.3)
ax.aspect = 'scaled'
ax.autoscale = False
ax.plot((0,.2,.3,.4,1.5), (0,.5,.3,.92,.48))
key here is using name spaces and properties....
However, John's version is pretty nice too:
 fig = pylab.figure(1)
 ax = fig.add_subplot(111,
 xlim=(-0.25,2.0), ylim=(0.0,1.3),
 aspect=('scaled', True), autoscale_on=False)
 ax.plot((0,.2,.3,.4,1.5), (0,.5,.3,.92,.48))
keyword arguments are very pythonic!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Bugfix release including imshow problem from 0.87.
This is the first release from the new subversion repository. The cvs
tree is dead at this point.
http://sourceforge.net/project/showfiles.php?group_id=3D80706
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2006年03月07日 Released 0.87.1
2006年03月04日 backend_cairo.py:
 fix get_rgb() bug reported by Keith Briggs.
 Require pycairo 1.0.2.
 Support saving png to file-like objects. - SC
2006年03月03日 Fixed pcolor handling of vmin, vmax - EF
2006年03月02日 improve page sizing with usetex with the latex
 geometry package. Closes bug # 1441629 - DSD
2006年03月02日 Fixed dpi problem with usetex png output. Accepted a
 modified version of patch # 1441809 - DSD
2006年03月01日 Fixed axis('scaled') to deal with case xmax < xmin - JSWHIT
2006年03月01日 Added reversed colormaps (with '_r' appended to name) - JSWHIT
2006年02月27日 Improved eps bounding boxes with usetex - DSD
2006年02月27日 Test svn commit, again!
2006年02月27日 Fixed two dependency checking bugs related to usetex
 on Windows - DSD
2006年02月27日 Made the rc deprecation warnings a little more human
 readable.
2006年02月26日 Update the previous gtk.main_quit() bug fix to use gtk.main_leve=
l()
 - SC
2006年02月24日 Implemented alpha support in contour and contourf - EF
2006年02月22日 Fixed gtk main quit bug when quit was called before
 mainloop. - JDH
2006年02月22日 Small change to colors.py to workaround apparent
 bug in numpy masked array module - JW
2006年02月22日 Fixed bug in ScalarMappable.to_rgba() reported by
 Ray Jones, and fixed incorrect fix found by Jeff
 Whitaker - EF

Following John's advice to Steve in the sister thread, I was able to
get really nice results by tweaking figure.subplot.bottom and .left:
font.size : 24.0
figure.subplot.left : 0.15 # the left side of the subplots of the figure
figure.subplot.right : 0.925 # the right side of the subplots of the figu=
re
figure.subplot.bottom : 0.15 # the bottom of the subplots of the figure
figure.subplot.top : 0.925 # the top of the subplots of the figure
My rc file is attached as a starting point for people who like large
fonts (for when you have to shrink your figures into small places).
Ryan
On 3/6/06, Darren Dale <dd...@co...> wrote:
> On Monday 06 March 2006 8:13 pm, Ryan Krauss wrote:
> > I have rebulit from SVN. It turns out that my problem only happens
> > with really large fonts. I am using Darren's new font size
> > specification with font.size =3D 18 or 24 and
> > everything else set to medium or large:
> > axes.titlesize : large # fontsize of the axes title
> > axes.labelsize : medium # fontsize of the x any y labels
> > xtick.labelsize : medium # fontsize of the tick labels
> > ytick.labelsize : medium # fontsize of the tick labels
> > legend.fontsize : medium
> >
> > (I really like that new size scheme Darren.)
> >
> > with font.size =3D 18, things are o.k. with 24, they are clipped on th=
e
> > screen, in the pdf, and even a little in the png.
> >
> > This may be closely related to what Steve just posted.
>
> I think you will get better results by manually positioning your axes in =
the
> figure window. MPL only knows to fill the specified figure window with th=
e
> gray background, but since your text runs over, it causes problems.
>
> Darren
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> As I mentioned for Ryan's question, try manually
 Darren> positioning your axes to leave enough room for your axes
 Darren> labels in the figure window.
Yep. We don't use any smarts to make sure text doesn't get clipped
off the bottom. Raise the bottom of your subplot by adjusting the
"bottom" of the subplot params
figure.subplot.bottom : 0.1 # the bottom of the subplots of the figure
You can either adjust the rc param, or use the subplots_adjust command
See examples ganged_plots.py and subplots_adjust.py
 >> 2) Is it possible for the "\Omega" in "image_omega.png" to be
 >> upright (like it would be for usetex=True) and not inclined?
It probably is possible. Does TeX not use an italicized \Omega in
math mode?
JDH

Christopher Barker wrote:
> Nikolai Hlubek wrote:
> 
>> Wouldn't another 'axis' option make the
>> whole thing more consistent?
> 
> 
> <soapbox>
> 
> Using the OO interface everywhere would make the whole thing more
> consistent:
> 
> fig = pylab.figure(1)
> ax = fig.add_subplot(111)
> ax.set_xlim(-0.25,2.0)
> ax.set_ylim(0.0,1.3)
> ax.set_aspect('scaled', True)
> ax.set_autoscale_on(False)
> ax.plot((0,.2,.3,.4,1.5), (0,.5,.3,.92,.48))
> 
> <\soapbox>
> flame(on) ;-)
If a procedural interface is provided whats wrong with using it?
And besides, who uses an interface which reminds of disposal of bodily
wastes? ;-)
> flame(off)
Nikolai
-- 
"1984" is not a howto!

Hi Mark, hi everyone
The code I posted was taken from one of my programs
and for the sake of simplicity I left a few parts out.
That may have made my intention a bit unclear.
I'm sorry for that.
Here are all the relevant parts:
def main():
 if cts['show_qm']: qmx, qmy = read_qm()
 if cts['show_cm']: cmx, cmy = read_cm()
 figure(1)
 ax = subplot(111)
 axis((-0.25,2.0,0.0,1.3))
 axis('scaled')
 ax.set_autoscale_on(False)
 for i in range(100):
 if cts['show_qm']: plot((qmx[i],qmx[i]),(qmy[i],qmy[i]),'bo')
 if cts['show_cm']: plot((cmx[i],cmx[i]),(cmy[i],cmy[i]),'go')
 raw_input('Press <enter> to continue')
if __name__ == "__main__":
 ion()
 main()
 show()
The program reads two lists of points and plots them one
by one so I can compare them, which is why I need axis('scaled'). The
autoscale property on the other hand is used that the plot commands in
the for loop don't thouch the axis. The program does exactly what I want
it to do and is fast enough despite my inefficient code since it only
has to plot 100 points.
But since there is only one axis in the figure I thought it would be a
good idea if I could disable autoscaling in the way the limits and the
'scaled' property were set.
The other point I wrote this was because I couldn't find any
documentation on the autoscale behaviour except for an old thread on
this list. If autoscale would be an option of the axis command it could
be found on:
http://matplotlib.sourceforge.net/pylab_commands.html
Best regards,
Nikolai
-- 
"1984" is not a howto!

On 3/7/06, Mark Bakker <ma...@gm...> wrote:
> Nikolai -
> The axis('equal') does not fix the scales, and place the plot in the
> center (as far as I know this mimics matlab behavior). The
> axis('scaled') is a variation on this theme that does fix the scale
> and puts the plot in the lower left hand corner. Obviously, many more
> permutations are possible. If many people think another pylab option
> would be crucial we can always add one more.
Hi,
I miss the equivalent to "axis image" in matlab, axis('scaled') is
very close to beeing
the same except it does not preserve figure axis ranges and ratio when
I resize my window.
what methods are called after a window resize event in gtkagg anyway?
Helge

John Hunter wrote:
>>>>>>"Toon" == Toon Verstraelen <Too...@UG...> writes:
> Toon> I wonder if their is a cleaner way of doing this, without a
> Toon> wrapper function? Is it possible to organize multiple axes
> Toon> in a plot in another way than using the pylab.subplot
> Toon> function?
> 
> Yes, you want to use the pylab axes function
> 
> http://matplotlib.sourceforge.net/matplotlib.pylab.html#-axes
> 
> which allows you to place an axes anywhere. Still uses relative
> coords, but your arithmetic will be *much easier* than it was for
> subplots. Eg where leftrel is the relative left border and leftin is
> the left border in inches, you can compute letfrel (which is what axes
> wants) with 
> 
> leftrel = leftin / figwidth
Thanks! This makes live a lot easier.
> Toon> As an example, I have attached one of the types of plots I'm
> Toon> working on. I have to use wrapper functions like the one
> Toon> given above, to make sure that the subplots are squares and
> Toon> the horizontal and vertical distances between them are
> Toon> equal. This is luckily not a blocker, but the choice of
> Toon> working with relative coordinates, is not always ideal. A
> 
> I agree. It would be nice to be able to pass in units of your choice,
> inches, points, cm, relative, pixel, data for all locations. You can
> do this relatively easy for some datatypes (eg lines, text, etc) by
> using custom transforms, but not everywhere (eg axes positions are
> always relative).
Ok, I'll take a look at it. Is it for example also possible to use the
transforms to draw a vertical arrow 0.2 inches under a datapoint, that
is 0.3 inches long? I mean, can transforms be used to mix different units?
> Toon> of interest (entries, buttons, labels, ...). A similar
> Toon> approach in matplotlib would be a great improvement. The
> Toon> organizational widgets should have properties like margins,
> Toon> spacings, ..., that can be given in different units
> Toon> (relative or absolute). The actual widgets of interest in
> Toon> this analogy are axes, labels (for the title and
> Toon> axislabels), ticks with labels and legends.
> 
> Toon> What do you matplotlib-people think of such an idea? Is it
> Toon> completely over-engineered? Maybe some parts are already
> Toon> partially implemented? I would be happy to work out this
> Toon> idea and start implementing it. It's a rather huge job, as I
> Toon> am not yet familiar with the complete matplotlib code. Some
> Toon> discussion in advance, also with non-developers, is
> Toon> therefore more than welcome. Shoot!
> 
> You are welcome to work on this. I think it would be a nice
> addition. You might want to start by looking at the Axis code for
> example to see how the xlabel and ylabel position are chosen to not
> overlap the tick labels, as an example of how to work with the
> matplotlib bounding boxes. This kind of stuff will be essential for
> your layout algorithms.
Indeed, this won't be simple. Does someone have some information
pointers about layout engines? Without a little background, chances are
small that I will ever come up with something that makes sense. We'll see.
regards,
Toon

Nikolai -
The axis('equal') does not fix the scales, and place the plot in the
center (as far as I know this mimics matlab behavior). The
axis('scaled') is a variation on this theme that does fix the scale
and puts the plot in the lower left hand corner. Obviously, many more
permutations are possible. If many people think another pylab option
would be crucial we can always add one more.
Mark
--- From: Nikolai Hlubek <nik...@ma...>
Hi everyone
When looking at the little code example below
it can be seen see that you have to mix programming
paradigms to disable autoscaling:
 figure(1)
 ax =3D subplot(111)
 axis((-0.25,2.0,0.0,1.3))
 axis('scaled')
 ax.set_autoscale_on(False)
Wouldn't another 'axis' option make the
whole thing more consistent?
 figure(1)
 axis((-0.25,2.0,0.0,1.3))
 axis('scaled')
 axis(autoscale=3DFalse)
Best regards,
Nikolai

On Monday 06 March 2006 7:56 pm, Steve Schmerler wrote:
> Hi
>
> 1)
> Using the recent svn version I get axes labels which are partially cut
> off when using mathtext (*no* usetex) and increasing the font size (see
> attached "image_cut.png"):
>
> rcParams['xtick.labelsize'] = 18
> rcParams['ytick.labelsize'] = 18
> rcParams['axes.labelsize'] = 18
> plot([1,2,3])
> xlabel(r'$\rm{value}\ \sum\prod\Omega x_i$')
> ylabel('y-Titel')
> savefig("image_cut.png")
>
> I observed this with .png, jpg and .eps
As I mentioned for Ryan's question, try manually positioning your axes to 
leave enough room for your axes labels in the figure window.
> 2)
> Is it possible for the "\Omega" in "image_omega.png" to be upright (like
> it would be for usetex=True) and not inclined?
>
> rcParams['xtick.labelsize'] = 18
> rcParams['ytick.labelsize'] = 18
> rcParams['axes.labelsize'] = 18
> plot([1,2,3])
> xlabel(r'$\Omega$')
> ylabel('y-Titel')
> savefig("image_omega.png")
I have to punt, I dont know the answer to this one.
Darren

On Monday 06 March 2006 8:13 pm, Ryan Krauss wrote:
> I have rebulit from SVN. It turns out that my problem only happens
> with really large fonts. I am using Darren's new font size
> specification with font.size = 18 or 24 and
> everything else set to medium or large:
> axes.titlesize : large # fontsize of the axes title
> axes.labelsize : medium # fontsize of the x any y labels
> xtick.labelsize : medium # fontsize of the tick labels
> ytick.labelsize : medium # fontsize of the tick labels
> legend.fontsize : medium
>
> (I really like that new size scheme Darren.)
>
> with font.size = 18, things are o.k. with 24, they are clipped on the
> screen, in the pdf, and even a little in the png.
>
> This may be closely related to what Steve just posted.
I think you will get better results by manually positioning your axes in the 
figure window. MPL only knows to fill the specified figure window with the 
gray background, but since your text runs over, it causes problems.
Darren 

I have rebulit from SVN. It turns out that my problem only happens
with really large fonts. I am using Darren's new font size
specification with font.size =3D 18 or 24 and
everything else set to medium or large:
axes.titlesize : large # fontsize of the axes title
axes.labelsize : medium # fontsize of the x any y labels
xtick.labelsize : medium # fontsize of the tick labels
ytick.labelsize : medium # fontsize of the tick labels
legend.fontsize : medium
(I really like that new size scheme Darren.)
with font.size =3D 18, things are o.k. with 24, they are clipped on the
screen, in the pdf, and even a little in the png.
This may be closely related to what Steve just posted.
Ryan
On 3/6/06, Ryan Krauss <rya...@gm...> wrote:
> The problem is in both. I will build from svn and see what happens.
>
> Ryan
>
> On 3/6/06, Darren Dale <dd...@co...> wrote:
> > Hi Ryan,
> >
> > On Monday 06 March 2006 5:50 pm, Ryan Krauss wrote:
> > > I have a small problem when saving figures with
> > > savefig.facecolor : gray #white # figure facecolor when saving
> > > savefig.edgecolor : gray #white # figure edgecolor when saving
> > > set in my rc file.
> > >
> > > If I run
> > >
> > > t=3Darange(0,1,0.1)
> > > y=3Dsin(2*pi*t)
> > > plot(t,y)
> > > xlabel('Time (sec)')
> > > ylabel('amplitude')
> > > savefig('gray.eps')
> > >
> > > and then epstopdf gray.eps, I get the attached file with the gray
> > > border not going quite low enough. This doesn't occur when saving
> > > .png. It also seems to be o.k. if I just use xlabel('time') without
> > > the parenthesis and uppercase T.
> > >
> > > I am including the figures in a Latex beamer presenation with a dark
> > > background and I need the gray border for visability.
> > >
> > > I tried switching to gs-8.50, but the problem didn't do away. I am
> > > using version 0.86.2 which is probably cvs from a month ago.
> >
> > I cant reproduce your problem using the most recent checkout from svn. =
How
> > does your eps file look, does the problem only exist in the pdf?
> >
> > Darren
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> > that extends applications into web and mobile media. Attend the live we=
bcast
> > and join the prime developer group breaking into this new coding territ=
ory!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>