matplotlib-devel Mailing List for matplotlib

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> double lastx(-2.0), lasty(-2.0); @@ -1339,9 +1341,15 @@
 Darren> }
 Darren> catch (...) { moveto = true; + skippoint = true;
 Darren> continue;
 Darren> }
 Darren> - + else + if (MPL_isnan64(thisx) || MPL_isnan64(thisy)) {
 Darren> + moveto = true; + skippoint = true;
I don't think you need skippoint. A combination of setting "moveto"
with "continue" should suffice. continue implicitly skips the point,
and setting the moveto flag indicates to agg not to connect the
previous with the next point.
 catch (...) {
 moveto = true;
 continue;
 }
 else
 if (MPL_isnan64(thisx) || MPL_isnan64(thisy)) {
 moveto = true;
 continue;
 }
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I havent modified extension code before, and this change
 Darren> would affect all the *agg backends, so I dont want to
 Darren> commit before checking.
Here is a quick checklist of things to consider before committing Agg changes
 1) makes a plot that you can interact with
 2) passes backend_driver.py screening for Agg
 3) passes unit/memleak_hawaii3.py with no appreciable memory leak
 4) does something useful....
If it satisfies these, in my view it is suitable for public consumption.
JDH

On Monday 20 March 2006 16:45, you wrote:
> Darren Dale wrote:
> >Thank you, Andrew (Baker's Dozen) Straw.
>
> Hey, stop thanking me! ;) Seriously, it's me who should be thanking you
> for all the work you're doing on the PS and latex fronts. I'm just glad
> I can do a couple of minor things to help you along the way.
>
> >Does this look about right?
> >
> >
> >def isnan(a):
> > return reshape(array([isnan64(i) for i in ravel(a)],'b'), shape(a))
>
> It looks fine to me -- it matches the behavior of numpy's isnan.
I modified _nc_imports.py and numerix/__init__.py. As of svn 2179, we have an 
isnan for every numerix flavor (numpy and numarray use their own). That means 
that the postscript backend can use nan's to mask points, if you use the new 
API.
I also found a way to patch _backend_agg.cpp to make it break lines around 
nan's. I havent modified extension code before, and this change would affect 
all the *agg backends, so I dont want to commit before checking. Here's the 
diff:
Index: src/_backend_agg.cpp
===================================================================
--- src/_backend_agg.cpp (revision 2178)
+++ src/_backend_agg.cpp (working copy)
@@ -23,6 +23,7 @@
 #include "_backend_agg.h"
 #include "_transforms.h"
 #include "mplutils.h"
+#include "MPL_isnan.h"
 #include "swig_runtime.h"
@@ -1324,6 +1325,7 @@
 double thisx, thisy;
 bool moveto = true;
+ bool skippoint = false;
 double heightd = height;
 double lastx(-2.0), lasty(-2.0);
@@ -1339,9 +1341,15 @@
 }
 catch (...) {
 moveto = true;
+ skippoint = true;
 continue;
 }
-
+ else
+ if (MPL_isnan64(thisx) || MPL_isnan64(thisy)) {
+ moveto = true;
+ skippoint = true;
+ }
+
 //use agg's transformer?
 xytrans.transform(&thisx, &thisy);
 thisy = heightd - thisy; //flipy
@@ -1367,8 +1375,9 @@
 path.move_to(thisx, thisy);
 else
 path.line_to(thisx, thisy);
-
- moveto = false;
+ if (!skippoint)
+ moveto = false;
+ skippoint = false;
 //std::cout << "draw lines " << thisx << " " << thisy << std::endl;
 }

Andrew Straw wrote:
> Eric Firing wrote:
> 
> 
>>John Hunter wrote:
>>
>>
>>>Eric, what is the status of the aspect code w/ respect to the presence
>>>of colorbars, or more generally, multiple axes? 
>>
>>
>>John,
>>
>>Broken! I assumed it would be OK, but now I see that is not the case.
>>I know why, and I can fix it easily on my next pass. But this does
>>highlight the question of more complex positioning situations.
> 
> 
> Hi Eric,
> 
> I don't know if you're aware of this, but Axes.set_position() seems to
> have broken in the last day or two, also.
> 
> Cheers!
> Andrew
Andrew,
Thanks--it makes sense that it would (and it is the reason for the 
colorbar problem), but I am embarrassed that I didn't spot it myself 
before committing changes.
Eric

Eric Firing wrote:
> John Hunter wrote:
>
>> Eric, what is the status of the aspect code w/ respect to the presence
>> of colorbars, or more generally, multiple axes? 
>
>
> John,
>
> Broken! I assumed it would be OK, but now I see that is not the case.
> I know why, and I can fix it easily on my next pass. But this does
> highlight the question of more complex positioning situations.
Hi Eric,
I don't know if you're aware of this, but Axes.set_position() seems to
have broken in the last day or two, also.
Cheers!
Andrew

Darren Dale wrote:
>Thank you, Andrew (Baker's Dozen) Straw.
> 
>
Hey, stop thanking me! ;) Seriously, it's me who should be thanking you
for all the work you're doing on the PS and latex fronts. I'm just glad
I can do a couple of minor things to help you along the way.
>Does this look about right?
> 
>
>def isnan(a):
> return reshape(array([isnan64(i) for i in ravel(a)],'b'), shape(a))
> 
>
It looks fine to me -- it matches the behavior of numpy's isnan.

On Monday 20 March 2006 13:40, Andrew Straw wrote:
> 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
Thank you, Andrew (Baker's Dozen) Straw.
Does this look about right?
def isnan(a):
 return reshape(array([isnan64(i) for i in ravel(a)],'b'), shape(a))
In [1]: a=ones((3,3,3),'d')
In [2]: a[0,0,0]=array(0.0)/0
In [3]: isnan(a)
Out[3]:
[[[1,0,0,]
 [0,0,0,]
 [0,0,0,]]
 [[0,0,0,]
 [0,0,0,]
 [0,0,0,]]
 [[0,0,0,]
 [0,0,0,]
 [0,0,0,]]]

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> Eric> be factored out. Resizing and repositioning are more
> Eric> generally useful; for example, they are used in the colorbar
> Eric> function. I would like to take a look at this broader
> Eric> question before finalizing the axes aspect ratio handling.
> 
> Eric, what is the status of the aspect code w/ respect to the presence
> of colorbars, or more generally, multiple axes? 
John,
Broken! I assumed it would be OK, but now I see that is not the case. 
I know why, and I can fix it easily on my next pass. But this does 
highlight the question of more complex positioning situations.
Eric

John Hunter wrote:
>>>>>>"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
John,
Yes, I will try to check all relevant docstrings on my next pass--this 
evening, if all goes well.
At least some of the things I missed were greppable; I just didn't spend 
enough time to check everything carefully.
Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> be factored out. Resizing and repositioning are more
 Eric> generally useful; for example, they are used in the colorbar
 Eric> function. I would like to take a look at this broader
 Eric> question before finalizing the axes aspect ratio handling.
Eric, what is the status of the aspect code w/ respect to the presence
of colorbars, or more generally, multiple axes? 
JDH

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