matplotlib-devel Mailing List for matplotlib (Page 4)

Jeff,
Jeff Whitaker wrote:
> 
> Eric: It occurred to me that there are actually 9 possibilities for 
> adjusting the location of the plot in the bounding box after fixing the 
> aspect ratio. Here's a patch to this morning's svn axes.py that adds 
> the other 7 possibilities. Does this make sense to you? If so, I can 
> go ahead and apply it.
> 
> -Jeff
Thanks, but I think it would be better to hold off.
This possibility did occur to me, but I originally left it out to keep 
things simple, both in the API and in the code. (My inclination was 
actually to make centering standard, and not even offer the 
corner-anchoring.) I think that perhaps this sort of positioning 
functionality should be factored out. Resizing and repositioning are 
more generally useful; for example, they are used in the colorbar 
function. I would like to take a look at this broader question before 
finalizing the axes aspect ratio handling.
Eric

John Hunter wrote:
>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
> 
> >> 
> >> def set_aspect(self, aspect='auto', fixLimits=None,
> >> aspect_adjusts='position'): """ aspect: 'auto' - automatic;
> 
> A minor nit: I'm not fond of underscores in kwargs, and prefer them to
> be as short and as easy to type as possible. I think "aspects" in
> "aspect_adjusts" is a bit redundant since the method is "set_aspect"
> and prefer "adjust" or something similarly simple. Also, perhaps we
> could take this opportunity while changing the API to replace
> fixLimits with fixlimits (if it survives the refactor).
> 
> I think as a general matter, we should stick to strictly lowercase, no
> underscores for kwargs where possible. Granted not all kwargs work
> this way currently, but most do and I prefer this style.
> 
> JDH
John,
OK, no problem, I will change to your kwarg style; it makes sense.
fixlimits will not survive in any case; "adjust" replaces it.
Eric

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:
 >> 
 >> def set_aspect(self, aspect='auto', fixLimits=None,
 >> aspect_adjusts='position'): """ aspect: 'auto' - automatic;
A minor nit: I'm not fond of underscores in kwargs, and prefer them to
be as short and as easy to type as possible. I think "aspects" in
"aspect_adjusts" is a bit redundant since the method is "set_aspect"
and prefer "adjust" or something similarly simple. Also, perhaps we
could take this opportunity while changing the API to replace
fixLimits with fixlimits (if it survives the refactor).
I think as a general matter, we should stick to strictly lowercase, no
underscores for kwargs where possible. Granted not all kwargs work
this way currently, but most do and I prefer this style.
JDH

Darren Dale wrote:
>Here's a bug: I need isnan to create my mask. It is provided by numerix with 
>numpy and numarray, but not Numeric. Can this be rectified?
> 
>
I just added the matplotlib._isnan extension module which is independent
of the numerix choice (although I think it'll be better to stick with a
numerix-given function, if available). Below is an example of its use.
Perhaps you can modify the Numeric-flavor numerix so that isnan is
exposed the same way as numarray and numpy -- I didn't do this because
you'll be more familiar with the details than I am.
#Example:
import matplotlib._isnan as n
import numpy
for val in [3.2,3,numpy.nan,'adsf']:
 print 'val',val
 print n.isnan64(val)
 print
Running displays the following:
val 3.2
False
val 3
False
val nan
True
val adsf
Traceback (most recent call last):
 File "testnan.py", line 6, in ?
 print n.isnan64(val)
TypeError: a float is required

Eric Firing wrote:
> All,
>
> Motivated in part by an old patch (1233294) submitted to sourceforge 
> by Nikolai Hlubek, I took a look at how aspect ratio is handled in 
> mpl, and concluded it wasn't quite right:
>
> 1) The aspect='preserve' kwarg in image caused the image to retain its 
> aspect ratio only with some resize events, not with all. The 
> implementation in the image.py code does not look right to me.
>
> 2) The aspect='equal' kwarg in axes.py did not respond to resize 
> events at all.
>
> 3) I could not understand why there should be separate "aspect" kwargs 
> for image and for axes.
>
> Therefore I have reworked the aspect-handling code in axes.py, and I 
> think it is working reasonably well. Indeed, I don't see any 
> remaining need for an "aspect" kwarg in image.py, and I would like to 
> take it out unless someone raises an objection.
>
> I have also changed the aspect-related API to make it more flexible 
> and self-explanatory:
>
> def set_aspect(self, aspect='auto', fixLimits=None,
> aspect_adjusts='position'):
> """
> aspect:
> 'auto' - automatic; fill position rectangle with data
> 'normal' - same as 'auto'; deprecated
> 'equal' - same scaling from data to plot units for x and y
> A - a circle will be stretched such that the height
> is A times the width. aspect=1 is the same as
> aspect='equal'.
>
> aspect_adjusts:
> 'position' - change width or height of bounding rectangle;
> keep it centered.
> 'box_size' - as above, but anchored to lower left
> 'datalim' - change xlim or ylim
>
> fixLimits: deprecated; False is aspect_adjusts='datalim';
> True is aspect_adjusts='position'
>
> ACCEPTS: ['auto' | 'equal' | aspect_ratio]
> ...
>
> def set_aspect_adjusts(self, aspect_adjusts = 'position'):
> """
> Must be called after set_aspect.
>
> ACCEPTS: ['position' | 'box_size' | 'datalim']
>
> ...
>
> Anticipating that some additional work will need to be done, I have 
> not yet made an entry in the CHANGELOG or API_CHANGES.
>
> In addition to removing the aspect kwarg from image.py, I would like 
> to take fixLimits out of set_aspect (above). No code in mpl or its 
> examples depends on it, but this might break some user code, so for 
> the present I have maintained compatibility.
>
> One question: is there an easy way to automatically trigger a redraw 
> in an interactive backend (e.g. ipython with gtkagg) at the end of the 
> set_aspect() method, for example? The way it works now is that one 
> can make a plot, call the set_aspect() method on the resulting axes 
> object, and the result will appear as soon as the window is 
> manipulated with the mouse; but this manipulation is needed to trigger 
> a redraw.
>
> Eric
Eric: It occurred to me that there are actually 9 possibilities for 
adjusting the location of the plot in the bounding box after fixing the 
aspect ratio. Here's a patch to this morning's svn axes.py that adds 
the other 7 possibilities. Does this make sense to you? If so, I can 
go ahead and apply it.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 >> The set_aspect function is called from axis() in pylab.py and I
 >> think somewhere in backend_basics after a zoom event.
 Eric> Thanks for pointing that out--I thought I had found
 Eric> everything, but I certainly had not. I will take a look at
 Eric> those calls; at the least, they will need to be changed
 Eric> slightly if I remove the fixLimits kwarg.
One of the drawbacks of having pass through kwargs. grep isn't as
useful as you'd like it to be. This is a docstring bug in pylab.axis,
which should be updated to reflect the fixLimits kwarg (if it survives
the refactor).
JDH

Mark,
Go ahead and test the svn version now. I still need to write the 
CHANGELOG entry, I will probably take out the fixLimits kwarg (but leave 
its functionality), and there may be some other things that need 
tweaking; but the essential functionality is in place.
Mark Bakker wrote:
> Eric -
> 
> Good to see you are taking aspect ratio handling to the next level.
> Your proposed changes sound good.
> 
> Regarding the 'fixLimits', this was implemented as the aspect ratio 
> handling was
> different when the axes limits were fixed or not. Having them fixed is 
> exceedingly useful,
> and used by quite a few people, as far as I know. But I understand this 
> will still be possible.
Yes. The default when aspect ratio is not 'auto' is to maintain the 
aspect ratio by changing the screen dimensions of the axes box, but the 
option is available to do it by changing xlim and/or ylim instead.
> 
> The code never worked when the window was resized interactively. Am I 
> understaning you
> correctly that the new code does this correctly? Across backends? That 
> would be very nice.
Yes, I think it does, but I have not tested it extensively. There is 
nothing backend-specific. The change that makes it work interactively 
is to put the aspect ratio calculations in a separate function and then 
call that function in axes.draw. I have not yet tried John's suggestion 
for triggering a redraw automatically after calling set_aspect.
> 
> The set_aspect function is called from axis() in pylab.py and I think 
> somewhere in backend_basics after a zoom event.
Thanks for pointing that out--I thought I had found everything, but I 
certainly had not. I will take a look at those calls; at the least, 
they will need to be changed slightly if I remove the fixLimits kwarg.
I will try to make another pass through the code this evening.
Eric
> 
> Let me know when you uploaded stuff that is ready for testing and I'll 
> give it a try,
> 
> Mark
> 
> On 3/20/06, *Eric Firing* <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
> John, Mark, Fernando, Nikolai,
> 
> I decided to go ahead with the next stage: I committed a few more
> changes so that I think imshow will now work the way people would like.
> To see the basic behavior most quickly, fire up ipython and do
> 
> In [1]:z = rand(20,40)
> 
> In [2]:imshow(z, aspect='auto')
> Out[2]:<matplotlib.image.AxesImage instance at 0xb5be81ec>
> 
> In [3]:imshow(z)
> Out[3]:<matplotlib.image.AxesImage instance at 0xb5c02c0c>
> 
> In the first case, as you resize the window with the mouse, the aspect
> ratio will change with the window. In the second case, the aspect ratio
> will be 1:1 regardless of what you do, including zooming. I made the
> second case the default because it seems to me that an image normally is
> meant to be viewed with a 1:1 aspect ratio--with square pixels. (I am
> assuming the display pixels are square, or close enough to it.)
> 
> (You could also do imshow(z, aspect=23.7), for example; you can specify
> any stretch factor you want.)
> 
> I left matshow with the 'auto' behavior, which is the default for
> ordinary axes, and which was its original behavior. If you would
> prefer
> 'equal' (1:1), or following the rc['image.aspect'], I would be happy to
> make that change.
> 
> Testing and comments are invited.
> 
> Thanks.
> 
> Eric
> 
> 
> 
> John Hunter wrote:
> >>>>>>"Eric" == Eric Firing < ef...@ha...
> <mailto:ef...@ha...>> writes:
> >
> >
> > Eric> All, Motivated in part by an old patch (1233294) submitted
> > Eric> to sourceforge by Nikolai Hlubek, I took a look at how
> > Eric> aspect ratio is handled in mpl, and concluded it wasn't
> > Eric> quite right:
> >
> > Just a few quick comments since I haven't had a chance to look over
> > this in any detail.
> >
> > Eric> 1) The aspect='preserve' kwarg in image caused the image to
> > Eric> retain its aspect ratio only with some resize events, not
> > Eric> with all. The implementation in the image.py code does not
> > Eric> look right to me.
> >
> >
> >
> > Eric> Therefore I have reworked the aspect-handling code in
> > Eric> axes.py, and I think it is working reasonably
> well. Indeed,
> > Eric> I don't see any remaining need for an "aspect" kwarg in
> > Eric> image.py, and I would like to take it out unless someone
> > Eric> raises an objection.
> >
> > The aspect handling of images has been known to be broken from the
> > early days, but in those days we didn't even have aspect='equal'
> > functionality, and so adding preserved aspect ratio proved to
> > daunting. Noone has revisited the issue (until now) since Mark
> Bakkar
> > finally (mostly) got proper aspect handling in the axes. So your
> > observations are on target, and the image aspect handling is an
> > anachronism that everyone quickly learned to ignore.
> >
> > Eric> def set_aspect(self, aspect='auto', fixLimits=None,
> > Eric> aspect_adjusts='position'): """ aspect: 'auto' - automatic;
> > Eric> fill position rectangle with data 'normal' - same as
> 'auto';
> > Eric> deprecated 'equal' - same scaling from data to plot units
> > Eric> for x and y A - a circle will be stretched such that the
> > Eric> height is A times the width. aspect=1 is the same as
> > Eric> aspect='equal'.
> >
> > Mark Bakkar wrote most of the aspect handling for the axes, and
> so he
> > can response most intelligently to these changes. You should
> send him
> > your original post since he may not be on this list. He's CCd above.
> >
> > Eric> One question: is there an easy way to automatically
> trigger
> > Eric> a redraw in an interactive backend (e.g. ipython with
> > Eric> gtkagg) at the end of the set_aspect() method, for example?
> > Eric> The way it works now is that one can make a plot, call the
> > Eric> set_aspect() method on the resulting axes object, and the
> > Eric> result will appear as soon as the window is manipulated
> with
> > Eric> the mouse; but this manipulation is needed to trigger a
> > Eric> redraw.
> >
> > You should be able to do something like
> >
> > if rcParams['interactive']:
> > self.figure.canvas.draw()
> >
> > where self is an Axes instance. Untested, but I think it is valid
> > across backends.
> >
> > Thanks for the submission -- I look forward to testing it.
> >
> > JDH
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking
> scripting language
> > that extends applications into web and mobile media. Attend the
> live webcast
> > and join the prime developer group breaking into this new coding
> territory!
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642>
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 

On Monday 20 March 2006 11:05, John Hunter wrote:
> I ran a test script to profile this before and after, making marker
> plots of various sizes. I think you'll be happy with the fruits of
> your labors. Because we save the effort of setting a gc for each
> marker, and thus avoid of lot of redundant function calling and state
> setting in the output file, the results are much better in time and space
>
> import time, os
> from pylab import figure, close, nx
>
> for i in 10,100,1000,10000,100000:
> fig = figure(1)
> ax = fig.add_subplot(111)
> x,y = nx.mlab.rand(2,i)
> tnow = time.time()
> ax.plot(x,y, 'o')
> fname = 'file%d.ps'
> fig.savefig(fname)
> elapsed = time.time() - tnow
> fsize = os.stat(fname)[6]
> print 'i=%06d time= %1.2fs size=%1.1fkb'%(i, elapsed, fsize/1e3)
> close(1)
>
> Old API:
> > python test.py
>
> i=000010 time= 0.33s size=142.4kb
> i=000100 time= 0.30s size=154.9kb
> i=001000 time= 0.43s size=284.1kb
> i=010000 time= 1.79s size=1575.9kb
> i=100000 time= 15.37s size=14495.6kb
>
> New API:
> > python test.py
>
> i=000010 time= 0.53s size=148.1kb
> i=000100 time= 0.29s size=146.5kb
> i=001000 time= 0.30s size=163.6kb
> i=010000 time= 0.44s size=334.5kb
> i=100000 time= 2.17s size=2044.5kb
>
> So for largish marker plots, you have about a 7x improvement in speed
> and filesize. You may want to use this script to profile and see if
> you can't eke out some extra gains. Maybe another 2x <wink>. This is
> using the default rc file.
>
> Now that we have a good implementation in a pure python backend that
> others can follow as an example, I will shortly deprecate the old API
> entirely and begin pruning the redundant methods. Considering that
> both your changes and Eric's are significant enhancements, we may wait
> to do this until one release cycle down the road, so that we don't
> delay getting these out to the wider community.
I just committed a fix for a minor bug, it didnt effect the performance. My 
results are comparable to yours. How's this for a performance boost: set 
ps.useafm : true in rc:
Old API:
i=000010 time= 0.09s size=6.2kb
i=000100 time= 0.07s size=18.0kb
i=001000 time= 0.19s size=147.2kb
i=010000 time= 1.43s size=1439.2kb
i=100000 time= 13.99s size=14358.6kb
New API:
i=000010 time= 0.16s size=11.7kb
i=000100 time= 0.07s size=9.6kb
i=001000 time= 0.06s size=26.7kb
i=010000 time= 0.13s size=197.7kb
i=100000 time= 0.75s size=1907.7kb
I dont see where I can make things any faster in draw_markers, we trimmed all 
the fat when we started on this a year ago.
Here's a bug: I need isnan to create my mask. It is provided by numerix with 
numpy and numarray, but not Numeric. Can this be rectified?
Darren

Hmm - I believe that message is from a SWIG error which is what wraps Qt 
into Python. So that would mean that the Qt object is being deleted w/o 
the python finding out about it.
> 37 figManager = Gcf.get_active()
> 38 if figManager != None:
>---> 39 figManager.canvas.draw()
This makes me think that the canvas is being deleted. I wonder if we need 
to trap the window close and somehow tell the figure manager about it?
At 08:25 AM 3/20/2006, you wrote:
>Hi Ted,
>
>Yes, the figure size is good, thanks!
>
>I still see the other problem, if I close that first plot window, and then 
>try
>to make a new plot:
>
>---------------------------------------------------------------------------
>exceptions.RuntimeError Traceback (most recent
>call last)
>
>/home/darren/<ipython console>
>
>/usr/lib64/python2.4/site-packages/matplotlib/pylab.py in plot(*args,
>**kwargs)
> 2012 try:
> 2013 ret = gca().plot(*args, **kwargs)
>-> 2014 draw_if_interactive()
> 2015 except:
> 2016 hold(b)
>
>/usr/lib/python2.4/site-packages/IPython/genutils.py in wrapper(*args, **kw)
> 805 def wrapper(*args,**kw):
> 806 wrapper.called = False
>--> 807 out = func(*args,**kw)
> 808 wrapper.called = True
> 809 return out
>
>/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py in
>draw_if_interactive()
> 37 figManager = Gcf.get_active()
> 38 if figManager != None:
>---> 39 figManager.canvas.draw()
> 40
> 41 def show( mainloop=True ):
>
>/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qtagg.py in
>draw(self)
> 113 if DEBUG: print "FigureCanvasQtAgg.draw"
> 114 self.replot = True
>--> 115 self.repaint( False )
> 116
> 117 def print_figure( self, filename, dpi=150, facecolor='w',
>edgecolor='w',
>
>RuntimeError: underlying C/C++ object has been deleted
>
>
>On Monday 20 March 2006 11:09, you wrote:
> > Darren,
> > Can you check the latest MPL? We submitted a patch that fixed a Qt
> > resizing bug and I was wondering if it has fixed any of the problems you
> > were having.
> >
> > Ted
> >
> > At 03:01 PM 2/18/2006, you wrote:
> > >I'm having two problems with the QtAgg backend. If I do:
> > > >>> from pylab import *
> > > >>> plot([1,2])
> > >
> > >[<matplotlib.lines.Line2D instance at 0x2aaab1ead830>]
> > >
> > > >>> show()
> > >
> > >My figure window should be 8in x 6in, but instead it is 6in tall and as
> > > wide as my screen will allow. So thats the first issue. The second is
> > > this: if I close that window, and then do
> > >
> > > >>> plot([1,2])
> > >
> > >[<matplotlib.lines.Line2D instance at 0x2aaab1ebbcf8>]
> > >
> > > >>> show()
> > >
> > >I get the following traceback:
> > >
> > >Traceback (most recent call last):
> > > File "<stdin>", line 1, in ?
> > > File
> > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py",
> > >line 47, in show
> > > manager.window.show()
> > >RuntimeError: underlying C/C++ object has been deleted
> > >
> > >I'm using qt version 3.3.4, with cvs mpl 0.86.2, on a gentoo linux system.
> > >The
> > >only nondefault rc setting is the choice of backend.
> > >
> > >Darren
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > > files for problems? Stop! Download the new AJAX search engine that
> > > makes searching your log files as easy as surfing the web. DOWNLOAD
> > > SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> > >_______________________________________________
> > >Matplotlib-devel mailing list
> > >Mat...@li...
> > >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> > Ted Drain Jet Propulsion Laboratory ted...@jp...
>
>--
>Darren S. Dale, Ph.D.
>Cornell High Energy Synchrotron Source
>Cornell University
>200L Wilson Lab
>Rt. 366 & Pine Tree Road
>Ithaca, NY 14853
>
>dd...@co...
>office: (607) 255-9894
>fax: (607) 255-9001
Ted Drain Jet Propulsion Laboratory ted...@jp... 

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I think I actually got the new api working with
 Darren> draw_markers and draw_lines in backend_ps. The transforms
 Darren> are done by passing the results of transform.as_vec6_val
 Darren> to postscript. I would appreciate it if someone would test
 Darren> it out and give me feedback. In order to do so, update
 Darren> from svn and unmask backend_ps.RendererPS._draw_markers
 Darren> (not _draw_markers_old) by removing the leading
 Darren> underscore. Try plotting things like
I think the best way to get people to test this is to make it the
default in backend_ps -- then all svn users will be testing it
automatically and you will hear about it when there is a problem. They
don't call it "the bleeding edge" for nothing. I made this change in
svn, revision 2173.
 Darren> plot([0,1,2,3,4],'-o'); savefig('linear.eps')
 Darren> plot([0,1,nan,3,4],'-o'); savefig('linear_nan.eps') # Not
 Darren> possible with the old API semilogy([0,1,2,3,4],'-o');
 Darren> savefig('nonlinear.eps') semilogy([0,1,nan,3,4],'-o');
 Darren> savefig('nonlinear_nan.eps') # Not possible with the old
 Darren> API
 Darren> Are there other methods that need to be updated to use the
 Darren> new API? There are a bunch of unused methods in RendererPS
 Darren> that I will clean up once things have settled, please
 Darren> ignore them for now.
Just those two methods for now. I'd also like to add draw_paths and
remove many of the redundant ones.
Regarding a question from your previous post:
 Darren> Moving on, I've been trying to follow John's work in
 Darren> __draw_lines_hide (you masked that sucker twice, is it
 Darren> that bad?). Help me understand this, are we allowed to use
 Darren> transform.numerix_x_y in the new API, or do we have to use
 Darren> transform.as_vec6_val? If I can use the former:
You are certainly allowed to use it, and any other provided method,
but for nonlinear transformations it defeats the purpose of doing the
transformation in the backend. numerix_x_y transforms the entire
array with the affine plus nonlinear transform. If it fails on any
element the entire transformation fails. To prevent this problem you
would want to do an element wise transformation and on failures set
the path state for the next element to moveto, ie skip the bad point.
We have talked in the past about writing a helper routine to generate
the postscript path in extension code if performance becomes an issue.
I ran a test script to profile this before and after, making marker
plots of various sizes. I think you'll be happy with the fruits of
your labors. Because we save the effort of setting a gc for each
marker, and thus avoid of lot of redundant function calling and state
setting in the output file, the results are much better in time and space
 import time, os
 from pylab import figure, close, nx
 for i in 10,100,1000,10000,100000:
 fig = figure(1)
 ax = fig.add_subplot(111)
 x,y = nx.mlab.rand(2,i)
 tnow = time.time()
 ax.plot(x,y, 'o')
 fname = 'file%d.ps'
 fig.savefig(fname)
 elapsed = time.time() - tnow
 fsize = os.stat(fname)[6]
 print 'i=%06d time= %1.2fs size=%1.1fkb'%(i, elapsed, fsize/1e3)
 close(1)
Old API:
 > python test.py
 i=000010 time= 0.33s size=142.4kb
 i=000100 time= 0.30s size=154.9kb
 i=001000 time= 0.43s size=284.1kb
 i=010000 time= 1.79s size=1575.9kb
 i=100000 time= 15.37s size=14495.6kb
 
New API:
 > python test.py
 i=000010 time= 0.53s size=148.1kb
 i=000100 time= 0.29s size=146.5kb
 i=001000 time= 0.30s size=163.6kb
 i=010000 time= 0.44s size=334.5kb
 i=100000 time= 2.17s size=2044.5kb
 
So for largish marker plots, you have about a 7x improvement in speed
and filesize. You may want to use this script to profile and see if
you can't eke out some extra gains. Maybe another 2x <wink>. This is
using the default rc file.
Now that we have a good implementation in a pure python backend that
others can follow as an example, I will shortly deprecate the old API
entirely and begin pruning the redundant methods. Considering that
both your changes and Eric's are significant enhancements, we may wait
to do this until one release cycle down the road, so that we don't
delay getting these out to the wider community.
Thanks,
JDH

I need to find the centers of contour levels. My current approach is 
to create a contour set:
aContourSet = pylab.contourf(xi, yi, zi, 16, cmap = pylab.cm.jet)
and then for each collection in the collections, extract the vertices 
and then find the center(s) of the polygon(s). For example:
for aCollection in aContourSet.collections:
 aListOfPolygons = decompose(aCollection.get_verts(),
 eps = eps,
 verbose = verbose)
Where decompose walks through the vertices list and extracts the 
polygons by finding all of the closed polygons in the collection. 
This algorithm starts at the beginning of the list of vertices and 
looks for the same point. If that point is found, the algorithm 
calls this a closed polygon and then starts the search over at the 
next point in the list. If no match is found, that point is assumed 
to be the only point in the polygon and the search continues at the 
next point. This process is continued until the list is exhausted. 
(See attached file for implementation details of decompose and the 
code for finding the center of a polygon.).
However when I visually examine the results, some of the contour 
centers seem to be incorrect. I know that for some polygons that the 
center is not found inside the polygon. My problem seems to be with 
the contour levels that have multiple polygons. Hence, I think that 
my code to extract the closed polygons is it fault. Is there a 
definition of how the contouring routine populates the collection? 
Or is there a easier way to find the centers of the contours?
Thanks,
Jody Winston

Hi,
with mpl 0.87.2 I get
In [1]:import matplotlib
In [2]:matplotlib.use('TK')
---------------------------------------------------------------------------
exceptions.TypeError Traceback (most
recent call last)
/home/baecker/<ipython console>
/opt/python/lib/python2.4/site-packages/matplotlib/__init__.py in use(arg)
 1096 Set the matplotlib backend to one of the _knownBackends
 1097 """
-> 1098 rcParams['backend'] = validate_backend(arg)
 1099
 1100 def get_backend():
/opt/python/lib/python2.4/site-packages/matplotlib/__init__.py in
validate_backend(s, fail_on_err)
 472 for i in backends:
 473 if s == i.lower(): return i
--> 474 if fail_on_err: raise ValueError('Backend must be %s, or %s'%
\
 475 (', '.join(backends[:-1], backends[-1])),)
 476 else: return None
TypeError: join() takes exactly one argument (2 given)
Presumably it is just a wrongly placed bracket,
 475 (', '.join(backends[:-1]), backends[-1]),)
Best, Arnd

Hello Eric,
First of all: great job done with imshow()! works great!
When playing around with it we noticed a little problem propably due to a 
rounding error. It is quite good to see when using a backend like GTK (axes 
aren't antialiased there).
When running the code below you can see a white line at the bottom
which won't disappear even when moving the plot.
import matplotlib
matplotlib.use('GTKAgg')
from pylab import show, imshow, rand
z = rand(20,20)
imshow(z,aspect='auto')
show()
So again: great job with the aspectratio but I just wanted to state this one.
Nikolai and Martin

Eric -
Good to see you are taking aspect ratio handling to the next level.
Your proposed changes sound good.
Regarding the 'fixLimits', this was implemented as the aspect ratio handlin=
g
was
different when the axes limits were fixed or not. Having them fixed is
exceedingly useful,
and used by quite a few people, as far as I know. But I understand this wil=
l
still be possible.
The code never worked when the window was resized interactively. Am I
understaning you
correctly that the new code does this correctly? Across backends? That woul=
d
be very nice.
The set_aspect function is called from axis() in pylab.py and I think
somewhere in backend_basics after a zoom event.
Let me know when you uploaded stuff that is ready for testing and I'll give
it a try,
Mark
On 3/20/06, Eric Firing <ef...@ha...> wrote:
>
> John, Mark, Fernando, Nikolai,
>
> I decided to go ahead with the next stage: I committed a few more
> changes so that I think imshow will now work the way people would like.
> To see the basic behavior most quickly, fire up ipython and do
>
> In [1]:z =3D rand(20,40)
>
> In [2]:imshow(z, aspect=3D'auto')
> Out[2]:<matplotlib.image.AxesImage instance at 0xb5be81ec>
>
> In [3]:imshow(z)
> Out[3]:<matplotlib.image.AxesImage instance at 0xb5c02c0c>
>
> In the first case, as you resize the window with the mouse, the aspect
> ratio will change with the window. In the second case, the aspect ratio
> will be 1:1 regardless of what you do, including zooming. I made the
> second case the default because it seems to me that an image normally is
> meant to be viewed with a 1:1 aspect ratio--with square pixels. (I am
> assuming the display pixels are square, or close enough to it.)
>
> (You could also do imshow(z, aspect=3D23.7), for example; you can specify
> any stretch factor you want.)
>
> I left matshow with the 'auto' behavior, which is the default for
> ordinary axes, and which was its original behavior. If you would prefer
> 'equal' (1:1), or following the rc['image.aspect'], I would be happy to
> make that change.
>
> Testing and comments are invited.
>
> Thanks.
>
> Eric
>
>
>
> John Hunter wrote:
> >>>>>>"Eric" =3D=3D Eric Firing <ef...@ha...> writes:
> >
> >
> > Eric> All, Motivated in part by an old patch (1233294) submitted
> > Eric> to sourceforge by Nikolai Hlubek, I took a look at how
> > Eric> aspect ratio is handled in mpl, and concluded it wasn't
> > Eric> quite right:
> >
> > Just a few quick comments since I haven't had a chance to look over
> > this in any detail.
> >
> > Eric> 1) The aspect=3D'preserve' kwarg in image caused the image to
> > Eric> retain its aspect ratio only with some resize events, not
> > Eric> with all. The implementation in the image.py code does not
> > Eric> look right to me.
> >
> >
> >
> > Eric> Therefore I have reworked the aspect-handling code in
> > Eric> axes.py, and I think it is working reasonably well. Indeed,
> > Eric> I don't see any remaining need for an "aspect" kwarg in
> > Eric> image.py, and I would like to take it out unless someone
> > Eric> raises an objection.
> >
> > The aspect handling of images has been known to be broken from the
> > early days, but in those days we didn't even have aspect=3D'equal'
> > functionality, and so adding preserved aspect ratio proved to
> > daunting. Noone has revisited the issue (until now) since Mark Bakkar
> > finally (mostly) got proper aspect handling in the axes. So your
> > observations are on target, and the image aspect handling is an
> > anachronism that everyone quickly learned to ignore.
> >
> > Eric> def set_aspect(self, aspect=3D'auto', fixLimits=3DNone,
> > Eric> aspect_adjusts=3D'position'): """ aspect: 'auto' - automatic;
> > Eric> fill position rectangle with data 'normal' - same as 'auto';
> > Eric> deprecated 'equal' - same scaling from data to plot units
> > Eric> for x and y A - a circle will be stretched such that the
> > Eric> height is A times the width. aspect=3D1 is the same as
> > Eric> aspect=3D'equal'.
> >
> > Mark Bakkar wrote most of the aspect handling for the axes, and so he
> > can response most intelligently to these changes. You should send him
> > your original post since he may not be on this list. He's CCd above.
> >
> > Eric> One question: is there an easy way to automatically trigger
> > Eric> a redraw in an interactive backend (e.g. ipython with
> > Eric> gtkagg) at the end of the set_aspect() method, for example?
> > Eric> The way it works now is that one can make a plot, call the
> > Eric> set_aspect() method on the resulting axes object, and the
> > Eric> result will appear as soon as the window is manipulated with
> > Eric> the mouse; but this manipulation is needed to trigger a
> > Eric> redraw.
> >
> > You should be able to do something like
> >
> > if rcParams['interactive']:
> > self.figure.canvas.draw()
> >
> > where self is an Axes instance. Untested, but I think it is valid
> > across backends.
> >
> > Thanks for the submission -- I look forward to testing it.
> >
> > JDH
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > that extends applications into web and mobile media. Attend the live
> webcast
> > and join the prime developer group breaking into this new coding
> territory!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

John, Mark, Fernando, Nikolai,
I decided to go ahead with the next stage: I committed a few more 
changes so that I think imshow will now work the way people would like. 
 To see the basic behavior most quickly, fire up ipython and do
In [1]:z = rand(20,40)
In [2]:imshow(z, aspect='auto')
Out[2]:<matplotlib.image.AxesImage instance at 0xb5be81ec>
In [3]:imshow(z)
Out[3]:<matplotlib.image.AxesImage instance at 0xb5c02c0c>
In the first case, as you resize the window with the mouse, the aspect 
ratio will change with the window. In the second case, the aspect ratio 
will be 1:1 regardless of what you do, including zooming. I made the 
second case the default because it seems to me that an image normally is 
meant to be viewed with a 1:1 aspect ratio--with square pixels. (I am 
assuming the display pixels are square, or close enough to it.)
(You could also do imshow(z, aspect=23.7), for example; you can specify 
any stretch factor you want.)
I left matshow with the 'auto' behavior, which is the default for 
ordinary axes, and which was its original behavior. If you would prefer 
'equal' (1:1), or following the rc['image.aspect'], I would be happy to 
make that change.
Testing and comments are invited.
Thanks.
Eric
John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
> Eric> All, Motivated in part by an old patch (1233294) submitted
> Eric> to sourceforge by Nikolai Hlubek, I took a look at how
> Eric> aspect ratio is handled in mpl, and concluded it wasn't
> Eric> quite right:
> 
> Just a few quick comments since I haven't had a chance to look over
> this in any detail.
> 
> Eric> 1) The aspect='preserve' kwarg in image caused the image to
> Eric> retain its aspect ratio only with some resize events, not
> Eric> with all. The implementation in the image.py code does not
> Eric> look right to me.
> 
> 
> 
> Eric> Therefore I have reworked the aspect-handling code in
> Eric> axes.py, and I think it is working reasonably well. Indeed,
> Eric> I don't see any remaining need for an "aspect" kwarg in
> Eric> image.py, and I would like to take it out unless someone
> Eric> raises an objection.
> 
> The aspect handling of images has been known to be broken from the
> early days, but in those days we didn't even have aspect='equal'
> functionality, and so adding preserved aspect ratio proved to
> daunting. Noone has revisited the issue (until now) since Mark Bakkar
> finally (mostly) got proper aspect handling in the axes. So your
> observations are on target, and the image aspect handling is an
> anachronism that everyone quickly learned to ignore.
> 
> Eric> def set_aspect(self, aspect='auto', fixLimits=None,
> Eric> aspect_adjusts='position'): """ aspect: 'auto' - automatic;
> Eric> fill position rectangle with data 'normal' - same as 'auto';
> Eric> deprecated 'equal' - same scaling from data to plot units
> Eric> for x and y A - a circle will be stretched such that the
> Eric> height is A times the width. aspect=1 is the same as
> Eric> aspect='equal'.
> 
> Mark Bakkar wrote most of the aspect handling for the axes, and so he
> can response most intelligently to these changes. You should send him
> your original post since he may not be on this list. He's CCd above.
> 
> Eric> One question: is there an easy way to automatically trigger
> Eric> a redraw in an interactive backend (e.g. ipython with
> Eric> gtkagg) at the end of the set_aspect() method, for example?
> Eric> The way it works now is that one can make a plot, call the
> Eric> set_aspect() method on the resulting axes object, and the
> Eric> result will appear as soon as the window is manipulated with
> Eric> the mouse; but this manipulation is needed to trigger a
> Eric> redraw.
> 
> You should be able to do something like 
> 
> if rcParams['interactive']:
> self.figure.canvas.draw()
> 
> where self is an Axes instance. Untested, but I think it is valid
> across backends.
> 
> Thanks for the submission -- I look forward to testing it.
> 
> JDH
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> All, Motivated in part by an old patch (1233294) submitted
 Eric> to sourceforge by Nikolai Hlubek, I took a look at how
 Eric> aspect ratio is handled in mpl, and concluded it wasn't
 Eric> quite right:
Just a few quick comments since I haven't had a chance to look over
this in any detail.
 Eric> 1) The aspect='preserve' kwarg in image caused the image to
 Eric> retain its aspect ratio only with some resize events, not
 Eric> with all. The implementation in the image.py code does not
 Eric> look right to me.
 Eric> Therefore I have reworked the aspect-handling code in
 Eric> axes.py, and I think it is working reasonably well. Indeed,
 Eric> I don't see any remaining need for an "aspect" kwarg in
 Eric> image.py, and I would like to take it out unless someone
 Eric> raises an objection.
The aspect handling of images has been known to be broken from the
early days, but in those days we didn't even have aspect='equal'
functionality, and so adding preserved aspect ratio proved to
daunting. Noone has revisited the issue (until now) since Mark Bakkar
finally (mostly) got proper aspect handling in the axes. So your
observations are on target, and the image aspect handling is an
anachronism that everyone quickly learned to ignore.
 Eric> def set_aspect(self, aspect='auto', fixLimits=None,
 Eric> aspect_adjusts='position'): """ aspect: 'auto' - automatic;
 Eric> fill position rectangle with data 'normal' - same as 'auto';
 Eric> deprecated 'equal' - same scaling from data to plot units
 Eric> for x and y A - a circle will be stretched such that the
 Eric> height is A times the width. aspect=1 is the same as
 Eric> aspect='equal'.
Mark Bakkar wrote most of the aspect handling for the axes, and so he
can response most intelligently to these changes. You should send him
your original post since he may not be on this list. He's CCd above.
 Eric> One question: is there an easy way to automatically trigger
 Eric> a redraw in an interactive backend (e.g. ipython with
 Eric> gtkagg) at the end of the set_aspect() method, for example?
 Eric> The way it works now is that one can make a plot, call the
 Eric> set_aspect() method on the resulting axes object, and the
 Eric> result will appear as soon as the window is manipulated with
 Eric> the mouse; but this manipulation is needed to trigger a
 Eric> redraw.
You should be able to do something like 
 if rcParams['interactive']:
 self.figure.canvas.draw()
where self is an Axes instance. Untested, but I think it is valid
across backends.
Thanks for the submission -- I look forward to testing it.
JDH

I think I actually got the new api working with draw_markers and draw_lines in 
backend_ps. The transforms are done by passing the results of 
transform.as_vec6_val to postscript. I would appreciate it if someone would 
test it out and give me feedback. In order to do so, update from svn and 
unmask backend_ps.RendererPS._draw_markers (not _draw_markers_old) by 
removing the leading underscore. Try plotting things like
plot([0,1,2,3,4],'-o'); savefig('linear.eps')
plot([0,1,nan,3,4],'-o'); savefig('linear_nan.eps') # Not possible with the 
old API
semilogy([0,1,2,3,4],'-o'); savefig('nonlinear.eps')
semilogy([0,1,nan,3,4],'-o'); savefig('nonlinear_nan.eps') # Not possible with 
the old API
Are there other methods that need to be updated to use the new API? There are 
a bunch of unused methods in RendererPS that I will clean up once things have 
settled, please ignore them for now.
Darren

All,
Motivated in part by an old patch (1233294) submitted to sourceforge by 
Nikolai Hlubek, I took a look at how aspect ratio is handled in mpl, and 
concluded it wasn't quite right:
1) The aspect='preserve' kwarg in image caused the image to retain its 
aspect ratio only with some resize events, not with all. The 
implementation in the image.py code does not look right to me.
2) The aspect='equal' kwarg in axes.py did not respond to resize events 
at all.
3) I could not understand why there should be separate "aspect" kwargs 
for image and for axes.
Therefore I have reworked the aspect-handling code in axes.py, and I 
think it is working reasonably well. Indeed, I don't see any remaining 
need for an "aspect" kwarg in image.py, and I would like to take it out 
unless someone raises an objection.
I have also changed the aspect-related API to make it more flexible and 
self-explanatory:
 def set_aspect(self, aspect='auto', fixLimits=None,
 aspect_adjusts='position'):
 """
 aspect:
 'auto' - automatic; fill position rectangle with data
 'normal' - same as 'auto'; deprecated
 'equal' - same scaling from data to plot units for x and y
 A - a circle will be stretched such that the height
 is A times the width. aspect=1 is the same as
 aspect='equal'.
 aspect_adjusts:
 'position' - change width or height of bounding rectangle;
 keep it centered.
 'box_size' - as above, but anchored to lower left
 'datalim' - change xlim or ylim
 fixLimits: deprecated; False is aspect_adjusts='datalim';
 True is aspect_adjusts='position'
 ACCEPTS: ['auto' | 'equal' | aspect_ratio]
...
 def set_aspect_adjusts(self, aspect_adjusts = 'position'):
 """
 Must be called after set_aspect.
 ACCEPTS: ['position' | 'box_size' | 'datalim']
...
Anticipating that some additional work will need to be done, I have not 
yet made an entry in the CHANGELOG or API_CHANGES.
In addition to removing the aspect kwarg from image.py, I would like to 
take fixLimits out of set_aspect (above). No code in mpl or its 
examples depends on it, but this might break some user code, so for the 
present I have maintained compatibility.
One question: is there an easy way to automatically trigger a redraw in 
an interactive backend (e.g. ipython with gtkagg) at the end of the 
set_aspect() method, for example? The way it works now is that one can 
make a plot, call the set_aspect() method on the resulting axes object, 
and the result will appear as soon as the window is manipulated with the 
mouse; but this manipulation is needed to trigger a redraw.
Eric

On Sunday 19 March 2006 3:14 pm, Andrew Straw wrote:
> Darren Dale wrote:
> >For backend_ps, we want to make use of the transform's numerix methods.
> >
> > if transform.need_nonlinear():
> > x,y,mask =3D transform.nonlinear_only_numerix(x, y,
> > returnMask=3D1) else:
> > mask =3D ones(x.shape)
> > x,y =3D transform.numerix_x_y(x, y)
> >
> >If I do semilogy([0,1,2,3]), the mask will be [0,1,1,1]. If I do
> >semilogy([1,2,nan,4]), I would have expected a mask that looked like
> >[1,1,0,1], but it returns [1,1,1,1].
>
> I just committed a patch that should make this work. nan support is done
> in a case-by-case basis at the C level. So this is another case.
>
> >Wouldnt it make life easy if
> >transform.nonlinear_only_numerix and transform.numerix_x_y both returned=
 a
> >mask with zeros where x or y is a nan or inf?
>
> I'm not sure this is the right thing to do for inf (or -inf) -- I can
> imagine transforms that accept inf and return something useful (such as
> a reciprocal transform). Maybe we don't use any such transforms
> currently, but that doesn't mean we should prevent that case in the
> future. Is the inf case important for you?
I don't know. For a reciprocal transform, I suppose inf shouldn't effect th=
e=20
mask, but then we can plot the results of the transform. If we can't plot t=
he=20
transformed value, I think the mask should reflect it.
Moving on, I've been trying to follow John's work in __draw_lines_hide (you=
=20
masked that sucker twice, is it that bad?). Help me understand this, are we=
=20
allowed to use transform.numerix_x_y in the new API, or do we have to use=20
transform.as_vec6_val? If I can use the former:
=A0 =A0 =A0 =A0 print x,y
=A0 =A0 =A0 =A0 if transform.need_nonlinear():
=A0 =A0 =A0 =A0 =A0 =A0 x,y,mask =3D transform.nonlinear_only_numerix(x, y,=
 returnMask=3D1)
=A0 =A0 =A0 =A0 =A0 =A0 print x, y
=A0 =A0 =A0 =A0 else:
=A0 =A0 =A0 =A0 =A0 =A0 mask =3D ones(x.shape)
=A0 =A0 =A0 =A0 x, y =3D transform.numerix_x_y(x, y)
=A0 =A0 =A0 =A0 print x, y=20
that returns a "ValueError: Domain error on Transformation::numerix_x_y"=20
message when I try to do semilog plots. Linear plots look fine.
If I should be using the latter, well, I'm playing with it, but I'm spillin=
g=20
blue ink all over the place.

Darren Dale wrote:
>For backend_ps, we want to make use of the transform's numerix methods.
>
> if transform.need_nonlinear():
> x,y,mask = transform.nonlinear_only_numerix(x, y, returnMask=1)
> else:
> mask = ones(x.shape)
> x,y = transform.numerix_x_y(x, y)
>
>If I do semilogy([0,1,2,3]), the mask will be [0,1,1,1]. If I do 
>semilogy([1,2,nan,4]), I would have expected a mask that looked like 
>[1,1,0,1], but it returns [1,1,1,1]. 
>
I just committed a patch that should make this work. nan support is done
in a case-by-case basis at the C level. So this is another case.
>Wouldnt it make life easy if 
>transform.nonlinear_only_numerix and transform.numerix_x_y both returned a 
>mask with zeros where x or y is a nan or inf? 
>
I'm not sure this is the right thing to do for inf (or -inf) -- I can
imagine transforms that accept inf and return something useful (such as
a reciprocal transform). Maybe we don't use any such transforms
currently, but that doesn't mean we should prevent that case in the
future. Is the inf case important for you?
Cheers!
Andrew

I'm playing with the new API in backend_ps today. I'm trying to make 
draw_markers work:
On Tuesday 14 March 2006 1:38 pm, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
> Eric> Here is a simple illustration of the problem and
> Eric> inconsistency, using just the first few points in
> Eric> Tennessee's plot and a few lines from his script. With a
> Eric> log scale for y, the Agg backends are leaving gaps (breaking
> Eric> the line) at the points where y==0; the PS and SVG backends
> Eric> are removing those points, but *not* breaking the line. I
> Eric> think the Agg behavior is much better. But maybe it would
> Eric> be better yet to raise an exception, forcing the user to
> Eric> deal with the error explicitly. For example, the user might
> Eric> want to change the zero values to a very small number, and
> Eric> then explicitly set the y range to exclude the small
> Eric> numbers. This is illustrated in the second subplot.
>
> This issue has a long history, which I'll summarize here. In the old
> days, we raised an exception when non-positive numbers were passed to
> log plotting. Most people found this objectionable, and prefer to see
> the valid points plotted rather than nothing (though a warning would
> be nice). This is what matlab does. I needed to make some
> architectural changes to support this, because the transformations
> happened in the lines class which passed the transformed data to the
> backend.
>
> I looked into filtering the data in the lines class (basically what
> you did for ma data) but did not think it would be fast enough,
> because we potentially would have had to create a lot of line
> segments.
>
> So I changed the backend API and modified draw_lines to take the
> transformation as an argument. Then the backend can do the following
> (eg _backend_agg)
>
> if (needNonlinear)
> try {
> 	mpltransform->nonlinear_only_api(&thisx, &thisy);
> }
> catch (...) {
> 	moveto = true;
> 	continue;
> }
>
> Ie if there is a nonlinear transformation that raises an exception,
> the path state is changed from lineto to moveto. This is very fast,
> at least an order of magnitude faster than trying to compute the
> segments at the python level I suspect.
For backend_ps, we want to make use of the transform's numerix methods.
 if transform.need_nonlinear():
 x,y,mask = transform.nonlinear_only_numerix(x, y, returnMask=1)
 else:
 mask = ones(x.shape)
 x,y = transform.numerix_x_y(x, y)
If I do semilogy([0,1,2,3]), the mask will be [0,1,1,1]. If I do 
semilogy([1,2,nan,4]), I would have expected a mask that looked like 
[1,1,0,1], but it returns [1,1,1,1]. Wouldnt it make life easy if 
transform.nonlinear_only_numerix and transform.numerix_x_y both returned a 
mask with zeros where x or y is a nan or inf? Then I can filter out the 
un-drawable markers with something like
 to_draw = izip(x[start:end],y[start:end],mask[start:end])
 ps = ['%1.3f %1.3f marker' % (xp, yp) for xp, yp, m in to_draw i m]
I could do something similar for draw_lines, using Johns suggestion above. 
This would mask nans, infs and log(x<=0) without the need for masked arrays, 
and would provide an opportunity to issue a warning about the bad values (if 
that is actually desireable).
Darren
(There is a lot going on in the transforms that I'm still trying to wrap my 
head around, so please feel free to correct me where my assumptions are 
incorrect or naive.)

Ahah, I have seen this problem before several times on win32 but never sat
down to
nail down the problem. It also occurs, as described, on win32, mpl 0.86.1fo=
r
py2.3.
After you use the save button the entire axis is forgotten. gca() doesn't
work, xlabel,
or anything.
Mark
Fernando Perez wrote:
In [1]: plot(range(10))
Out[1]: [<matplotlib.lines.Line2D instance at 0x41ccd12c>]
At this point, click on the save button and save the figure to any filename=
.
Do NOT try savefig(), as it does NOT cause the problem.
Now, try
close('all')

Hi all,
I just rebuilt mpl on my ubuntu laptop with current SVN, and noticed a bug 
related to window management. Here's how to reproduce it:
- Backend: TkAgg
- Interactively start ipython -pylab
In [1]: plot(range(10))
Out[1]: [<matplotlib.lines.Line2D instance at 0x41ccd12c>]
At this point, click on the save button and save the figure to any filename. 
Do NOT try savefig(), as it does NOT cause the problem.
Now, try
close('all')
The window doesn't close. In fact, if you type figure(1), you'll get a 
SECOND window named (1). The original figure 1 has become inaccessible. 
Something is getting corrupted in the internal window management lists.
I tried GTKAgg and the problem is not present there, so it seems Tk-specific. 
 In 0.83 (what I have at work), this bug was not present either.
Cheers,
f

John Hunter wrote:
>>>>>>"James" == James Evans <jre...@ea...> writes:
>>>>>> 
>>>>>>
>
> James> The patch is as follows: -- In several places arrays are
> James> initialized with a variable for the length. As per
> James> Stroustrup arrays can only be specified with constants or
> James> using 'new' .
>
>Hey James, I notice you have 3 patches with the title 
>
> Strict C/C++ Conformance
>
>Have all of these been resolved by the patch Andrew applied? If so,
>I'll close them.
> 
>
Hmm, I only applied the one that was emailed to this list. I assume 
you're talking about patches on the SourceForge tracker? I haven't 
touched those...

Hi,
I wrote a random walk program which you will find below. When I run it from the terminal, it gives error which I am not able to figure out what could be wrong. From the bash shell, I give a command 
 >python2.4 random.py
It gives error:
-----------------------------------------------------------------------------------------
 Traceback (most recent call last):
 File "random.py", line 2, in ?
 from pylab import *
 File "/usr/lib/python2.4/site-packages/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 196, in ?
 import mlab #so I can override hist, psd, etc...
 File "/usr/lib/python2.4/site-packages/matplotlib/mlab.py", line 58, in ?
 import sys, random
 File "/home/ofenerci/workspace/random.py", line 11, in ?
 if (rand() > 0.5):
NameError: name 'rand' is not defined
[3] Done gedit random.py
-------------------------------------------------------------------------------------------------------------
When I write the program step by step inside the python shell or run it inside the python-idle, everything goes smoothly and it doesn't give any error. I don't know why gives error, If I run it from the terminal.
thanks,
Ahmet Nurlu
Random.py Program:
---------------------------------------------------------------------------
from pylab import *
npts=1000
nplot=10
for i in range(0,nplot):
 
 xplot=[]
 x=0.0
 for i in range(0,npts):
 if (rand() > 0.5):
 x=x+1
 else:
 x=x-1
 xplot.append(x)
 plot(xplot,'g')
 hold(True)
show()
-------------------------------------------------------------------------
		
---------------------------------
Relax. Yahoo! Mail virus scanning helps detect nasty viruses!