matplotlib-devel Mailing List for matplotlib (Page 2)

I've spent some time on this problem and have a 44 line solution for 
generating dendrogram line segments and root ending locations, i.e. x 
and y values. The format for cluster information is a nested tuple like 
this:
 cluster=(4.5,(3.0,'c',(1.0,'a','b')),(2.0,'e',(1.5,'f','g')))
where the FP numbers are distance information and the strings are the 
names of the items being clustered. The code can also handle cluster 
data without distance information, by assuming a fixed distance of 1.0:
 cluster=(('c',('a','b')),('e',('f','g')))
The output is a list of root location and value tuples: (x,y,item) and a 
list of dendrogram line segment tuples: (x1,y1,x2,y2). I've purposely 
avoided recursion back into the function by using list stacks because 
I'm always a little leery of how much space is available on the 
[virtual] machine stack. Note that this code has not been extensively 
tested. One limitation on this dendrogram code is that only pairs of 
objects may be clustered together at a time. Obviously a lot of work 
would need to be done to apply these data to a Matplotlib plot, but I 
don't know how to do it. The output could also be used to generate 
images in SVG, Postscript, mechanical plotters, or any other vector 
oriented graphical system.
Anyway, FWIW, my code is listed, below. I'm sure it can be improved 
upon. In hopes of someone doing something useful for others with it, I 
hereby release it under the Matplotlib license, while retaining the 
copyright for my own additional use. Please let me know if there is a 
better way to submit the code.
--Tim
import sys
def dendrogram(ctree,hasDistances='yes',yincr=1.0):
 stype=type("")
 tstack=[ctree[:]] ## make a copy
 nstack=[] ## node stack
 baselist=[]
 linelist=[]
 y=0.0
 while len(tstack)>0:
 tob=tstack.pop()
 if hasDistances=='yes':
 dist=tob[0]
 tob=tob[1:]
 elif hasDistances=='ignore':
 dist=1.0
 tob=tob[1:]
 elif hasDistances=='no':
 dist=1.0
 else:
 raise Exception("unknown value '%s' for named argument 
'hasDistances'" % self.hasDistances)
 obflag=False
 for ob in tob:
 if type(ob)==stype:
 baselist.append( (0.0,y,ob) )
 nstack.append( (0.0,y,dist) )
 y+=yincr
 else:
 tstack.append(ob)
 obflag=True
 if obflag: nstack.append((dist,))
 while len(nstack)>1 and len(nstack[-1])>1 and len(nstack[-2])>1:
 x1,y1,d1=nstack.pop()
 x2,y2,d2=nstack.pop()
 if d1>d2: d=d1
 else: d=d2
 if x1>x2: xnew=x1+d
 else: xnew=x2+d
 ynew=(y1+y2)/2.0
 linelist.append((x1,y1,xnew,y1))
 linelist.append((x2,y2,xnew,y2))
 linelist.append((xnew,y1,xnew,y2))
 if len(nstack)>0 and len(nstack[-1])<=1:
 dist=nstack.pop()[0]
 nstack.append( (xnew,ynew,dist) )
 return baselist,linelist
if __name__=="__main__":
 baselist,linelist=dendrogram( 
(4.5,(3.0,'c',(1.0,'a','b')),(2.0,'e',(1.5,'f','g'))) )
 print baselist
 print
 print linelist
Jouni K. Seppänen wrote:
> Timothy <te...@xm...> writes:
>
> 
>> It appears matplotlib does not have a dendrogram plot. I may be 
>> interested in developing one, if I can get a sense for what it would 
>> take. Could someone suggest some code I could look at as a model for 
>> developing a new plot?
>> 
>
> In the file axes.py, search for the comment "Specialized plotting" and
> look at the functions after that. The first function is "bar", which
> looks quite complicated, but perhaps "stem" would be a good starting
> point.
>
> 

John Hunter wrote:
[...]
> Yes, we've often talked about using traits here and elsewhere but the
> idea has languished because it has never made it to the top of
> anyone's priority queue. I just added examples/rc_traits.py, which is
> the example code I wrote some time ago when I was exploring how to use
> traits for rc and other mpl properties. I'll also post it again here
> in case someone wants to run with it.
Apart from the (significant) questions of time and priorities, I backed 
off a couple times from investigating traits because the enthought 
package does not seem to be a nice, clean, easily-installable chunk as 
it stands, and because the last time I looked at it, it used its own 
numerix support for arrays; I suspect it still does. And there is 
always the concern about adding yet another learning curve to mpl 
development; so I still don't know whether it would be a net benefit if 
the other impediments were removed.
Eric

On 5/18/07, Darren Dale <dd...@co...> wrote:
> > Using some dedicated class-instance instead of a dict would allow for:
> > - automatic conistency checks on setting
> > - possibly even change propagation (likely faster and certainly less
> > error prone if done right: I'm not sure how many places rcParams dependent
> > results apart from the tex-stuff are cached and should be recomputed when
> > certain params change, but obviously an push/'event'-based solutin could be
> > faster than pull/polling)
> This sounds like a good proposal to me. Some other devs had considered using
> the traits package to address some of these points. Maybe they will comment.
>
> > 2. It also seems to me that having some custom config file format rather
> > than just (a literal-only subset of) python is suboptimal. Why make people
> > learn another and more limited syntax when python literals are already
> > familiar and both more powerful and easier to use
>
> If someone donated a nickel for every time I have seen this argument on the
> mailing list, we might have enough money to buy John a doughnut.
Yes, we've often talked about using traits here and elsewhere but the
idea has languished because it has never made it to the top of
anyone's priority queue. I just added examples/rc_traits.py, which is
the example code I wrote some time ago when I was exploring how to use
traits for rc and other mpl properties. I'll also post it again here
in case someone wants to run with it.
# I spent some time working on matplotlib rc properties as enthought
# traits as a precursor to porting matplotlib properties to traits.
# Here is some example code showing how to define some representative rc
# properties and construct a matplotlib artist using traits. Because
# matplotlib ships with enthought traits already, you can run this
# script with just matplotlib. Unfortunately, we do not ship the ex UI
# component so you can't test that part. I'm a bit of a traits newbie
# so there are probably better ways to do what I have done below.
import sys, os, re
import matplotlib.enthought.traits as traits
from matplotlib.cbook import is_string_like
from matplotlib.artist import Artist
doprint = True
flexible_true_trait = traits.Trait(
 True,
 { 'true': True, 't': True, 'yes': True, 'y': True, 'on': True, True: True,
 'false': False, 'f': False, 'no': False, 'n': False, 'off':
False, False: False
 } )
flexible_false_trait = traits.Trait( False, flexible_true_trait )
colors = {
 'c' : '#00bfbf',
 'b' : '#0000ff',
 'g' : '#008000',
 'k' : '#000000',
 'm' : '#bf00bf',
 'r' : '#ff0000',
 'w' : '#ffffff',
 'y' : '#bfbf00',
 'gold' : '#FFD700',
 'peachpuff' : '#FFDAB9',
 'navajowhite' : '#FFDEAD',
 }
def hex2color(s):
 "Convert hex string (like html uses, eg, #efefef) to a r,g,b tuple"
 return tuple([int(n, 16)/255.0 for n in (s[1:3], s[3:5], s[5:7])])
class RGBA(traits.HasTraits):
 # r,g,b,a in the range 0-1 with default color 0,0,0,1 (black)
 r = traits.Range(0., 1., 0.)
 g = traits.Range(0., 1., 0.)
 b = traits.Range(0., 1., 0.)
 a = traits.Range(0., 1., 1.)
 def __init__(self, r=0., g=0., b=0., a=1.):
 self.r = r
 self.g = g
 self.b = b
 self.a = a
 def __repr__(self):
 return 'r,g,b,a = (%1.2f, %1.2f, %1.2f, %1.2f)'%\
 (self.r, self.g, self.b, self.a)
def tuple_to_rgba(ob, name, val):
 tup = [float(x) for x in val]
 if len(tup)==3:
 r,g,b = tup
 return RGBA(r,g,b)
 elif len(tup)==4:
 r,g,b,a = tup
 return RGBA(r,g,b,a)
 else:
 raise ValueError
tuple_to_rgba.info = 'a RGB or RGBA tuple of floats'
def hex_to_rgba(ob, name, val):
 rgx = re.compile('^#[0-9A-Fa-f]{6}$')
 if not is_string_like(val):
 raise TypeError
 if rgx.match(val) is None:
 raise ValueError
 r,g,b = hex2color(val)
 return RGBA(r,g,b,1.0)
hex_to_rgba.info = 'a hex color string'
def colorname_to_rgba(ob, name, val):
 hex = colors[val.lower()]
 r,g,b = hex2color(hex)
 return RGBA(r,g,b,1.0)
colorname_to_rgba.info = 'a named color'
def float_to_rgba(ob, name, val):
 val = float(val)
 return RGBA(val, val, val, 1.)
float_to_rgba.info = 'a grayscale intensity'
Color = traits.Trait(RGBA(), float_to_rgba, colorname_to_rgba, RGBA,
 hex_to_rgba, tuple_to_rgba)
def file_exists(ob, name, val):
 fh = file(val, 'r')
 return val
def path_exists(ob, name, val):
 os.path.exists(val)
linestyles = ('-', '--', '-.', ':', 'steps', 'None')
TICKLEFT, TICKRIGHT, TICKUP, TICKDOWN = range(4)
linemarkers = (None, '.', ',', 'o', '^', 'v', '<', '>', 's',
 '+', 'x', 'd', 'D', '|', '_', 'h', 'H',
 'p', '1', '2', '3', '4',
 TICKLEFT,
 TICKRIGHT,
 TICKUP,
 TICKDOWN,
 'None'
 )
class LineRC(traits.HasTraits):
 linewidth = traits.Float(0.5)
 linestyle = traits.Trait(*linestyles)
 color = Color
 marker = traits.Trait(*linemarkers)
 markerfacecolor = Color
 markeredgecolor = Color
 markeredgewidth = traits.Float(0.5)
 markersize = traits.Float(6)
 antialiased = flexible_true_trait
 data_clipping = flexible_false_trait
class PatchRC(traits.HasTraits):
 linewidth = traits.Float(1.0)
 facecolor = Color
 edgecolor = Color
 antialiased = flexible_true_trait
timezones = 'UTC', 'US/Central', 'ES/Eastern' # fixme: and many more
backends = ('GTKAgg', 'Cairo', 'FltkAgg', 'GD', 'GDK', 'GTK', 'Agg',
 'GTKCairo', 'Paint', 'PS', 'SVG', 'Template', 'TkAgg',
 'WX')
class RC(traits.HasTraits):
 backend = traits.Trait(*backends)
 numerix = traits.Trait('Numeric', 'numarray')
 interactive = flexible_false_trait
 toolbar = traits.Trait('toolbar2', 'classic', None)
 timezone = traits.Trait(*timezones)
 lines = traits.Trait(LineRC())
 patch = traits.Trait(PatchRC())
rc = RC()
rc.lines.color = 'r'
if doprint:
 print 'RC'
 rc.print_traits()
 print 'RC lines'
 rc.lines.print_traits()
 print 'RC patches'
 rc.patch.print_traits()
class Patch(Artist, traits.HasTraits):
 linewidth = traits.Float(0.5)
 facecolor = Color
 fc = facecolor
 edgecolor = Color
 fill = flexible_true_trait
 def __init__(self,
 edgecolor=None,
 facecolor=None,
 linewidth=None,
 antialiased = None,
 fill=1,
 **kwargs
 ):
 Artist.__init__(self)
 if edgecolor is None: edgecolor = rc.patch.edgecolor
 if facecolor is None: facecolor = rc.patch.facecolor
 if linewidth is None: linewidth = rc.patch.linewidth
 if antialiased is None: antialiased = rc.patch.antialiased
 self.edgecolor = edgecolor
 self.facecolor = facecolor
 self.linewidth = linewidth
 self.antialiased = antialiased
 self.fill = fill
p = Patch()
p.facecolor = '#bfbf00'
p.edgecolor = 'gold'
p.facecolor = (1,.5,.5,.25)
p.facecolor = 0.25
p.fill = 'f'
print 'p.facecolor', type(p.facecolor), p.facecolor
print 'p.fill', type(p.fill), p.fill
if p.fill_: print 'fill'
else: print 'no fill'
if doprint:
 print
 print 'Patch'
 p.print_traits()

I'm moving this discussion over to mpl-dev. Its gettin too hairy for the more 
general audience.
On Friday 18 May 2007 12:02:30 pm Alexander Schmolck wrote:
> If I may make another suggestion (I don't have time to volunteer for
> implementing them in the forseeable future, but I might eventually if
> there's interest): Maybe the way configuration is handled could be
> improved:
>
> 1. It seems to me that letting users manipulate some raw dictionary
> (`rcParams`) in order to customize behavior is bad.
>
> Just now, on my first dig into matplotlib I've found a number of bugs
> that result from bad state in rcParams. As a user this has also caused me
> some wasted time, because typos and other illegal param choices are not
> caught early (but are relativley likely, because matplotlib has many and
> complex options).
>
> Using some dedicated class-instance instead of a dict would allow for:
> - automatic conistency checks on setting
> - possibly even change propagation (likely faster and certainly less
> error prone if done right: I'm not sure how many places rcParams dependent
> results apart from the tex-stuff are cached and should be recomputed when
> certain params change, but obviously an push/'event'-based solutin could be
> faster than pull/polling)
> - possibly better performance, because e.g. using immutable values would
> allow identity based checks to see if a rcParam changed and obviate
> the need to copy;
> - convenient doc lookup and searching an display of available
> alternatives (e.g. font-families etc)
> - better factoring of the matplotlibrc parsing and validation see below:
This sounds like a good proposal to me. Some other devs had considered using 
the traits package to address some of these points. Maybe they will comment. 
> 2. It also seems to me that having some custom config file format rather
> than just (a literal-only subset of) python is suboptimal. Why make people
> learn another and more limited syntax when python literals are already
> familiar and both more powerful and easier to use
If someone donated a nickel for every time I have seen this argument on the 
mailing list, we might have enough money to buy John a doughnut.
> (e.g. the latex-preamble 
> setting can't express multiple package options, because param values can't
> contain ',')? 
Thats a pretty big bug. See the disclaimer concerning preamble 
customizations :)
> It would also get rid of the IMO undesirable coupling of 
> string-parsing and type-checking that the validate_* functions do at the
> moment; really setting an rcParam should also do the latter but not the
> former (and guaranteed validation on setting would also avoid the need
> to sprinkle random checks on reading through the code).
>
> IMO it would be much nicer if there was some more declarative way to
> specify options, check their validity on setting and assoicate docs with
> them (sort of like e.g. emcs-custom vars).
>
> Valid files in the old-syntax could be translated automatically quite
> easily, so I don't think it's a compatiblity issue.
These are all good points, most of which have been brought up before. What we 
need is someone with sufficient time and motivation...
Darren

Hi Darren,
I've made the changes you requested and committed it. (I didn't realize
that mpl-data/matplotlibrc was generated from the template -- I actually
already placed a descriptive line of text in the overwritten file.)
I'm attaching a file for the examples/ directory which I'm having
trouble checking in. I'm rushing out the door for a weekend away at the
moment, so if you can check this in, that'd be great, otherwise I'll try
again when I'm back online. I think it might be an issue with the
non-ASCII characters in the file.
I'll also update the wiki page when I get back.
-Andrew
Darren Dale wrote:
> Hi Andrew,
> 
> On Thursday 17 May 2007 10:12:09 pm Andrew Straw wrote:
>> OK, here's the patch! :)
>>
>> Andrew Straw wrote:
>>> Hi All (esp. Darren),
>>>
>>> The attached patch adds unicode support for LaTeX. Given the recent
>>> discussion about adding preambles, I thought I'd run it past here first.
>>> Anyone opposed if I check this in?
> 
> No opposition, but a couple requests. Would you add a commented out line to 
> matplotlibrc.template, with some brief discussion if you think it is 
> appropriate? Also, lets make it a policy that the custom preamble always 
> appears after all other preambles in texmanager amd backend_ps.
> 
>>> Note that I specifically added the rcParam text.latex.unicode to enable
>>> this and a default False value to turn this off by default. I hope this
>>> prevents breakage for folks who don't have the ucs and inputenc latex
>>> packages installed while allowing unicode for those of us that do.
> 
> I have never used unicode with latex, will you add a nugget to 
> http://www.scipy.org/Cookbook/Matplotlib/UsingTex?
> 
> Darren

Excellent, Perry.
Thanks for your help,
Mark
On 5/18/07, Perry Greenfield <pe...@st...> wrote:
>
> We don't have anyone at the moment that can work on it, but I think
> on the order of a month or two we can. We see similar issues too. So
> if someone can deal with it before then, that would be great, but
> we'll tackle it before very long if not.
>
> Perry
>
> On May 18, 2007, at 7:21 AM, Mark Bakker wrote:
>
> > This is a well known problem, reported about a year or so ago.
> > John Hunter tried to get some help on the (TK?) mailinglist, but I
> > don't think anybody responded. I looked into it too, but couldn't find
> > a solution (that doesn't mean much, except for that it is not
> > blatently obvious).
> > It would be great if somebody would know how to fix this.
> > Strangely enough I have written a GUI myself where I use the toolbar,
> > and the save button works fine there.
> > Mark
>
>

Hi Andrew,
On Thursday 17 May 2007 10:12:09 pm Andrew Straw wrote:
> OK, here's the patch! :)
>
> Andrew Straw wrote:
> > Hi All (esp. Darren),
> >
> > The attached patch adds unicode support for LaTeX. Given the recent
> > discussion about adding preambles, I thought I'd run it past here first.
> > Anyone opposed if I check this in?
No opposition, but a couple requests. Would you add a commented out line to 
matplotlibrc.template, with some brief discussion if you think it is 
appropriate? Also, lets make it a policy that the custom preamble always 
appears after all other preambles in texmanager amd backend_ps.
> > Note that I specifically added the rcParam text.latex.unicode to enable
> > this and a default False value to turn this off by default. I hope this
> > prevents breakage for folks who don't have the ucs and inputenc latex
> > packages installed while allowing unicode for those of us that do.
I have never used unicode with latex, will you add a nugget to 
http://www.scipy.org/Cookbook/Matplotlib/UsingTex?
Darren

We don't have anyone at the moment that can work on it, but I think 
on the order of a month or two we can. We see similar issues too. So 
if someone can deal with it before then, that would be great, but 
we'll tackle it before very long if not.
Perry
On May 18, 2007, at 7:21 AM, Mark Bakker wrote:
> This is a well known problem, reported about a year or so ago.
> John Hunter tried to get some help on the (TK?) mailinglist, but I
> don't think anybody responded. I looked into it too, but couldn't find
> a solution (that doesn't mean much, except for that it is not
> blatently obvious).
> It would be great if somebody would know how to fix this.
> Strangely enough I have written a GUI myself where I use the toolbar,
> and the save button works fine there.
> Mark

This is a well known problem, reported about a year or so ago.
John Hunter tried to get some help on the (TK?) mailinglist, but I
don't think anybody responded. I looked into it too, but couldn't find
a solution (that doesn't mean much, except for that it is not
blatently obvious).
It would be great if somebody would know how to fix this.
Strangely enough I have written a GUI myself where I use the toolbar,
and the save button works fine there.
Mark
> Date: 2007年5月10日 13:31:18 -0600
> From: "Urvashi R.V." <urv...@gm...>
>
> Hi,
>
> When the "save" button is used on the matplotlib tkagg toolbar, it
> uses the "Tk" "asksavefilename" object from the "tkFileDialog" class,
> to pop up a little window that allows you to select the name and type
> of file to save. This function internally calls "figure.destroy()".
> and the currently active figure gets destroyed (but it is still visible
> and memory is not freed). The next plot then creates a new figure
> window with the same figure._num as the previous.
>
> see...
> backend_tkagg.py : line 621
> -> class NavigationToolbar2TkAgg :: def save_figure(...)
> (callback for the toolbar.bsave button)
>
> The "asksavefilename" function call, triggers Gcf.destroy(). This can
> be seen by placing a print statement in
> _pylab_helpers.py : line 16
> -> class Gcf :: def destroy(num)

OK, here's the patch! :)
Andrew Straw wrote:
> Hi All (esp. Darren),
>
> The attached patch adds unicode support for LaTeX. Given the recent
> discussion about adding preambles, I thought I'd run it past here first.
> Anyone opposed if I check this in?
>
> Note that I specifically added the rcParam text.latex.unicode to enable
> this and a default False value to turn this off by default. I hope this
> prevents breakage for folks who don't have the ucs and inputenc latex
> packages installed while allowing unicode for those of us that do.
>
> -Andrew
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi All (esp. Darren),
The attached patch adds unicode support for LaTeX. Given the recent
discussion about adding preambles, I thought I'd run it past here first.
Anyone opposed if I check this in?
Note that I specifically added the rcParam text.latex.unicode to enable
this and a default False value to turn this off by default. I hope this
prevents breakage for folks who don't have the ucs and inputenc latex
packages installed while allowing unicode for those of us that do.
-Andrew

Pierre GM wrote:
[...]
> 
> David, I wouldn't speak about compatibility, just about bugs: the problem was 
> in the implementation of .max() w/ maskedarray. The origin of the problem was 
> (is still) in umath.maximum.reduce that doesn't accept axis=None, so a numpy 
> problem ;). But I agree: switching may have some subtle consequences in 
> matplotlib (nothing that can't be quickly fiexed, however). What do Eric 
> Firing, John Hunter and the other mpl developer think ?
I think this would be a good time to make the switch. We are going to 
be stripping out the Numeric and numarray support, so let's finalize the 
new ma capabilities at the same time. I think that maskedarray is 
actually closer to being a drop-in replacement for ndarray than ma is, 
and I think it will be easier to work with. I am confident that any 
problems can be solved easily. A 15% speed penalty doesn't bother me; 
presumably it can be reduced later.
> 
> My only request would be for more users ! That's the only way I can find how 
> to improve maskedarray.
Moving maskedarray from the sandbox into svn numpy will make it easier 
for mpl devels to use it while doing and testing the mpl numpification.
(I won't be able to work on this until June.)
I suppose that it will be necessary for mpl to support both for a while, 
unfortunately, but I haven't thought this through carefully.
Eric

Pierre,
I don't think John follows the numpy list closely, so I am forwarding this.
Eric

On 5/17/07, Mark Bakker <ma...@gm...> wrote:
> I tried this on the user's list, but didn't get a response.
> I am afraid it is a bug.
> I am trying to use FancyArrow to draw an arrow with given length.
> The length I use is from 0 to 100.
> I specify length_includes_head=True.
> This works fine when I specify a width and length.
> But when I specify an overhang, the length of the arrow becomes much longer
> than 100.
> Am I using overhang incorrectly?
> Here's a script with the problem:
FancyArrow was written by a colleague of Fernando -- perhaps you an
provide a free-standing script that illustrates the problem and
Fernando can pass it on to the original author to take a look.
JDH
>
> from pylab import *
> from matplotlib.patches import FancyArrow
> axis([0,120,0,100])
> ax = gca()
> a = FancyArrow( 0, 40, 100, 0, length_includes_head=True, head_width=5,
> head_length=5)
> ax.add_patch(a)
> b = FancyArrow( 0, 60, 100, 0, length_includes_head=True, head_width=5,
> head_length=5, overhang=5)
> ax.add_patch(b)
> draw_if_interactive()
>
> Thanks, Mark
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hello list -
I tried this on the user's list, but didn't get a response.
I am afraid it is a bug.
I am trying to use FancyArrow to draw an arrow with given length.
The length I use is from 0 to 100.
I specify length_includes_head=True.
This works fine when I specify a width and length.
But when I specify an overhang, the length of the arrow becomes much longer
than 100.
Am I using overhang incorrectly?
Here's a script with the problem:
from pylab import *
from matplotlib.patches import FancyArrow
axis([0,120,0,100])
ax = gca()
a = FancyArrow( 0, 40, 100, 0, length_includes_head=True, head_width=5,
head_length=5)
ax.add_patch(a)
b = FancyArrow( 0, 60, 100, 0, length_includes_head=True, head_width=5,
head_length=5, overhang=5)
ax.add_patch(b)
draw_if_interactive()
Thanks, Mark

On 5/15/07, Fernando Perez <fpe...@gm...> wrote:
> On 5/15/07, John Hunter <jd...@gm...> wrote:
>
> > This was a bug where tkagg was switching backends to svg, but not
> > trapping the error and resetting the backend on failure. so you were
> > stuck in svg mode. Now we catch the error, switch the backend back to
> > tkagg, and then reraise.
>
> Note that I was using WXAgg where I saw it.
It looks like this is a problem across many backends, and is best
handled in backend_agg itself. I just made a few changes to agg,
tkagg, wxagg and gtkagg to fix this. If anyone encounters weirdness,
let me know.
JDH

On 5/15/07, John Hunter <jd...@gm...> wrote:
> This was a bug where tkagg was switching backends to svg, but not
> trapping the error and resetting the backend on failure. so you were
> stuck in svg mode. Now we catch the error, switch the backend back to
> tkagg, and then reraise.
Note that I was using WXAgg where I saw it.
> Fortunately, I had easy access to a platform where mathtext was
> installed to test and debug on :-)
Glad to help :)
Off to the airport...
f

On 5/12/07, Fernando Perez <fpe...@gm...> wrote:
> Hi all,
>
> the following shows a bug in the backend sate handling of mpl:
>
> plot(range(10))
> title(r'Foo $x=1$')
> savefig('foo.eps') # works fine, as expected.
> savefig('foo.svg') # doesn't work, that's OK: not implemented
> savefig('foo.eps') # now, this doesn't work anymore. That's the bug.
>
> Basically, when the SVG backend fails to properly generate the file
> with latex strings, it fails to resstore something in the backend
> state, and MPL ends up 'wedged'. After that point, the only way to
> get an EPS plot again seems to be to restart the session.
This was a bug where tkagg was switching backends to svg, but not
trapping the error and resetting the backend on failure. so you were
stuck in svg mode. Now we catch the error, switch the backend back to
tkagg, and then reraise.
Fortunately, I had easy access to a platform where mathtext was
installed to test and debug on :-)
JDH

Hi all,
the following shows a bug in the backend sate handling of mpl:
plot(range(10))
title(r'Foo $x=1$')
savefig('foo.eps') # works fine, as expected.
savefig('foo.svg') # doesn't work, that's OK: not implemented
savefig('foo.eps') # now, this doesn't work anymore. That's the bug.
Basically, when the SVG backend fails to properly generate the file
with latex strings, it fails to resstore something in the backend
state, and MPL ends up 'wedged'. After that point, the only way to
get an EPS plot again seems to be to restart the session.
Cheers,
f

Hi,
When the "save" button is used on the matplotlib tkagg toolbar, it
uses the "Tk" "asksavefilename" object from the "tkFileDialog" class,
to pop up a little window that allows you to select the name and type
of file to save. This function internally calls "figure.destroy()".
and the currently active figure gets destroyed (but it is still visible
and memory is not freed). The next plot then creates a new figure
window with the same figure._num as the previous.
see...
backend_tkagg.py : line 621
-> class NavigationToolbar2TkAgg :: def save_figure(...)
(callback for the toolbar.bsave button)
The "asksavefilename" function call, triggers Gcf.destroy(). This can
be seen by placing a print statement in
_pylab_helpers.py : line 16
-> class Gcf :: def destroy(num)
A script to trigger this is attached
Does anyone else see this, and does anyone have a way to fix this ?
Thank you very much !
Regards,
 Urvashi Rau

Hi Eric,
I just checked out your change and it works another 0.2s faster than
what I had for my example, so I'm more than happy with the final
result. Thanks for taking the time to put my hazy ideas into practice
the right way :-)
Cheers,
Tim
On 5/10/07, Eric Firing <ef...@ha...> wrote:
> Tim,
>
> I couldn't resist; here is a numerix version of the method, which I
> committed to svn:
>
> def get_transformed_patches(self):
> # Shouldn't need all these calls to asarray;
> # the variables should be converted when stored.
> # Similar speedups with numerix should be attainable
> # in many other places.
> verts = asarray(self._verts)
> offsets = asarray(self._offsets)
> Npoly = len(offsets)
> scales = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
> Nscales = len(scales)
> if Nscales >1:
> scales = resize(scales, (Npoly, 1, 1))
> transOffset = self.get_transoffset()
> xyo = transOffset.numerix_xy(offsets)
> polys = scales * verts + xyo[:, newaxis, :]
> return polys
>
> It is faster even when there are only three polygons; and as the comment
> indicates, it would be even faster with additional numpification of the
> entire class. (Present version with 3 polys, 161 usecs vs 241 usecs;
> with 1000, 6.4 msec vs 47.3 msec.)
>
> It is also only lightly tested. I hope I haven't overlooked some
> situation that would work with the old version but not with this one.
>
> Eric
>
> Tim Leslie wrote:
> > On 5/10/07, Eric Firing <ef...@ha...> wrote:
> >> Tim,
> >>
> >> Based on a *very superficial* quick look, I have two comments:
> >>
> >> 1) Since the plan is (or was?) to have one more release before
> >> specializing to numpy-only support, the ".T" won't work at present.
> >>
> >> 2) In the following (possibly mangled by mailer),
> >>
> >> > + if Nsizes == 1:
> >> > + xy = asarray([xverts, yverts]).T * sizes[0]
> >> > + polys = [xy + offset for offset in
> >> transOffset.seq_xy_tups(self._offsets)]
> >>
> >> I think you can gain additional speedup by eliminating the list
> >> comprehension. Instead of using seq_xy_tups you can use numerix_xy to
> >> return a 2-D array (with columns x and y), and simply add that to xy.
> >>
> >
> > Thanks for the feedback Eric, I'll rework the patch with your comments
> > in mind. I also just noticed a rather glaring bug, in that I don't
> > actually have a 'return polys' after I calculate them in the special
> > case, which is somewhat embarrassing. I'll fix all this up and submit
> > a new patch later today.
> >
> > Cheers,
> >
> > Tim
> >
> >> Eric
> >>
> >>
> >> Tim Leslie wrote:
> >> > Hi All,
> >> >
> >> > I've attached a patch which optimizes a particular case of the
> >> > RegularPolyCollection.get_transformed_patches method. This is
> >> > particularly useful when using a picker on a scatter plot with ~40,000
> >> > points (as I happen to be doing) and cuts the time spent in this
> >> > function from ~4s to ~1s, which accounts for about 50% of the lag in
> >> > my particular use case.
> >> >
> >> > Similar improvements might be possible in the N > 1 case, but I don't
> >> > have a) a data set or b) the time to work them out with, so hopefully
> >> > someone is happy to check in this patch as it stands, as I think the
> >> > N==1 is probably the common case.
> >> >
> >> > If there are any problems with the patch let me know and I'll try to
> >> > fix it up. It's against latest svn (3262)
> >> >
> >> > Cheers,
> >> >
> >> > Tim
> >> >
> >> >
> >> >
> >> ------------------------------------------------------------------------
> >> >
> >> > Index: lib/matplotlib/collections.py
> >> > ===================================================================
> >> > --- lib/matplotlib/collections.py (revision 3262)
> >> > +++ lib/matplotlib/collections.py (working copy)
> >> > @@ -153,7 +153,7 @@
> >> > if not self.pickable(): return
> >> > ind = []
> >> > x, y = mouseevent.x, mouseevent.y
> >> > - for i, thispoly in enumerate(self.get_transformed_patches()):
> >> > + for i, thispoly in enumerate(self.get_transformed_patches()):
> >> > inside = nxutils.pnpoly(x, y, thispoly)
> >> > if inside: ind.append(i)
> >> > if len(ind):
> >> > @@ -167,7 +167,6 @@
> >> > The ith element in the returned sequence is a list of x,y
> >> > vertices defining the ith polygon
> >> > """
> >> > -
> >> > verts = self._verts
> >> > offsets = self._offsets
> >> > usingOffsets = offsets is not None
> >> > @@ -451,13 +450,19 @@
> >> > __init__.__doc__ = dedent(__init__.__doc__) % kwdocd
> >> >
> >> > def get_transformed_patches(self):
> >> > -
> >> > +
> >> > xverts, yverts = zip(*self._verts)
> >> > xverts = asarray(xverts)
> >> > yverts = asarray(yverts)
> >> > sizes = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
> >> > Nsizes = len(sizes)
> >> > transOffset = self.get_transoffset()
> >> > +
> >> > + # optimize this case for an approx 4x speedup
> >> > + if Nsizes == 1:
> >> > + xy = asarray([xverts, yverts]).T * sizes[0]
> >> > + polys = [xy + offset for offset in
> >> transOffset.seq_xy_tups(self._offsets)]
> >> > +
> >> > polys = []
> >> > for i, loc in enumerate(self._offsets):
> >> > xo,yo = transOffset.xy_tup(loc)
> >> >
> >> >
> >> >
> >> ------------------------------------------------------------------------
> >> >
> >> >
> >> -------------------------------------------------------------------------
> >> > This SF.net email is sponsored by DB2 Express
> >> > Download DB2 Express C - the FREE version of DB2 express and take
> >> > control of your XML. No limits. Just data. Click to get it now.
> >> > http://sourceforge.net/powerbar/db2/
> >> >
> >> >
> >> >
> >> ------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Matplotlib-devel mailing list
> >> > Mat...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
>
>

Tim,
I couldn't resist; here is a numerix version of the method, which I 
committed to svn:
 def get_transformed_patches(self):
 # Shouldn't need all these calls to asarray;
 # the variables should be converted when stored.
 # Similar speedups with numerix should be attainable
 # in many other places.
 verts = asarray(self._verts)
 offsets = asarray(self._offsets)
 Npoly = len(offsets)
 scales = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
 Nscales = len(scales)
 if Nscales >1:
 scales = resize(scales, (Npoly, 1, 1))
 transOffset = self.get_transoffset()
 xyo = transOffset.numerix_xy(offsets)
 polys = scales * verts + xyo[:, newaxis, :]
 return polys
It is faster even when there are only three polygons; and as the comment 
indicates, it would be even faster with additional numpification of the 
entire class. (Present version with 3 polys, 161 usecs vs 241 usecs; 
with 1000, 6.4 msec vs 47.3 msec.)
It is also only lightly tested. I hope I haven't overlooked some 
situation that would work with the old version but not with this one.
Eric
Tim Leslie wrote:
> On 5/10/07, Eric Firing <ef...@ha...> wrote:
>> Tim,
>>
>> Based on a *very superficial* quick look, I have two comments:
>>
>> 1) Since the plan is (or was?) to have one more release before
>> specializing to numpy-only support, the ".T" won't work at present.
>>
>> 2) In the following (possibly mangled by mailer),
>>
>> > + if Nsizes == 1:
>> > + xy = asarray([xverts, yverts]).T * sizes[0]
>> > + polys = [xy + offset for offset in
>> transOffset.seq_xy_tups(self._offsets)]
>>
>> I think you can gain additional speedup by eliminating the list
>> comprehension. Instead of using seq_xy_tups you can use numerix_xy to
>> return a 2-D array (with columns x and y), and simply add that to xy.
>>
> 
> Thanks for the feedback Eric, I'll rework the patch with your comments
> in mind. I also just noticed a rather glaring bug, in that I don't
> actually have a 'return polys' after I calculate them in the special
> case, which is somewhat embarrassing. I'll fix all this up and submit
> a new patch later today.
> 
> Cheers,
> 
> Tim
> 
>> Eric
>>
>>
>> Tim Leslie wrote:
>> > Hi All,
>> >
>> > I've attached a patch which optimizes a particular case of the
>> > RegularPolyCollection.get_transformed_patches method. This is
>> > particularly useful when using a picker on a scatter plot with ~40,000
>> > points (as I happen to be doing) and cuts the time spent in this
>> > function from ~4s to ~1s, which accounts for about 50% of the lag in
>> > my particular use case.
>> >
>> > Similar improvements might be possible in the N > 1 case, but I don't
>> > have a) a data set or b) the time to work them out with, so hopefully
>> > someone is happy to check in this patch as it stands, as I think the
>> > N==1 is probably the common case.
>> >
>> > If there are any problems with the patch let me know and I'll try to
>> > fix it up. It's against latest svn (3262)
>> >
>> > Cheers,
>> >
>> > Tim
>> >
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > Index: lib/matplotlib/collections.py
>> > ===================================================================
>> > --- lib/matplotlib/collections.py (revision 3262)
>> > +++ lib/matplotlib/collections.py (working copy)
>> > @@ -153,7 +153,7 @@
>> > if not self.pickable(): return
>> > ind = []
>> > x, y = mouseevent.x, mouseevent.y
>> > - for i, thispoly in enumerate(self.get_transformed_patches()):
>> > + for i, thispoly in enumerate(self.get_transformed_patches()):
>> > inside = nxutils.pnpoly(x, y, thispoly)
>> > if inside: ind.append(i)
>> > if len(ind):
>> > @@ -167,7 +167,6 @@
>> > The ith element in the returned sequence is a list of x,y
>> > vertices defining the ith polygon
>> > """
>> > -
>> > verts = self._verts
>> > offsets = self._offsets
>> > usingOffsets = offsets is not None
>> > @@ -451,13 +450,19 @@
>> > __init__.__doc__ = dedent(__init__.__doc__) % kwdocd
>> >
>> > def get_transformed_patches(self):
>> > -
>> > +
>> > xverts, yverts = zip(*self._verts)
>> > xverts = asarray(xverts)
>> > yverts = asarray(yverts)
>> > sizes = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
>> > Nsizes = len(sizes)
>> > transOffset = self.get_transoffset()
>> > +
>> > + # optimize this case for an approx 4x speedup
>> > + if Nsizes == 1:
>> > + xy = asarray([xverts, yverts]).T * sizes[0]
>> > + polys = [xy + offset for offset in 
>> transOffset.seq_xy_tups(self._offsets)]
>> > +
>> > polys = []
>> > for i, loc in enumerate(self._offsets):
>> > xo,yo = transOffset.xy_tup(loc)
>> >
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > 
>> -------------------------------------------------------------------------
>> > This SF.net email is sponsored by DB2 Express
>> > Download DB2 Express C - the FREE version of DB2 express and take
>> > control of your XML. No limits. Just data. Click to get it now.
>> > http://sourceforge.net/powerbar/db2/
>> >
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>

Tim Leslie wrote:
> On 5/10/07, Eric Firing <ef...@ha...> wrote:
>> Tim,
>>
>> Based on a *very superficial* quick look, I have two comments:
>>
>> 1) Since the plan is (or was?) to have one more release before
>> specializing to numpy-only support, the ".T" won't work at present.
>>
>> 2) In the following (possibly mangled by mailer),
>>
>> > + if Nsizes == 1:
>> > + xy = asarray([xverts, yverts]).T * sizes[0]
>> > + polys = [xy + offset for offset in
>> transOffset.seq_xy_tups(self._offsets)]
>>
>> I think you can gain additional speedup by eliminating the list
>> comprehension. Instead of using seq_xy_tups you can use numerix_xy to
>> return a 2-D array (with columns x and y), and simply add that to xy.
>>
> 
> Thanks for the feedback Eric, I'll rework the patch with your comments
> in mind. I also just noticed a rather glaring bug, in that I don't
> actually have a 'return polys' after I calculate them in the special
> case, which is somewhat embarrassing. I'll fix all this up and submit
> a new patch later today.
Tim,
I took a look at the original code in collections.py. It looks like it 
could be greatly streamlined by using numerix consistently, taking 
advantage of the resize function (for the sizes array) and broadcasting. 
 No loops should be needed, and the x and y coordinates never need to 
be separated; it might still be worthwhile to special-case the Nsizes==1 
case to avoid the call to resize. I am not sure whether there would be 
any problem with returning a 3-D array instead of a list of 2-D arrays; 
if so, that conversion could be done with a list comprehension at the end.
My impression is that that for small arrays, lists and tuples are faster 
than using numerix, and the reverse for large arrays, but I don't know 
where the switchover is. There many places in mpl (including other 
methods of RegularPolyCollection) where zips and list comprehensions and 
explicit loops could be eliminated by using numerix consistently; I 
don't know in how many of these it would be good to make this change. 
Lists are much more flexible, and there are places where that 
flexibility is needed.
Eric
> 
> Cheers,
> 
> Tim
> 
>> Eric
>>
>>
>> Tim Leslie wrote:
>> > Hi All,
>> >
>> > I've attached a patch which optimizes a particular case of the
>> > RegularPolyCollection.get_transformed_patches method. This is
>> > particularly useful when using a picker on a scatter plot with ~40,000
>> > points (as I happen to be doing) and cuts the time spent in this
>> > function from ~4s to ~1s, which accounts for about 50% of the lag in
>> > my particular use case.
>> >
>> > Similar improvements might be possible in the N > 1 case, but I don't
>> > have a) a data set or b) the time to work them out with, so hopefully
>> > someone is happy to check in this patch as it stands, as I think the
>> > N==1 is probably the common case.
>> >
>> > If there are any problems with the patch let me know and I'll try to
>> > fix it up. It's against latest svn (3262)
>> >
>> > Cheers,
>> >
>> > Tim
>> >
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > Index: lib/matplotlib/collections.py
>> > ===================================================================
>> > --- lib/matplotlib/collections.py (revision 3262)
>> > +++ lib/matplotlib/collections.py (working copy)
>> > @@ -153,7 +153,7 @@
>> > if not self.pickable(): return
>> > ind = []
>> > x, y = mouseevent.x, mouseevent.y
>> > - for i, thispoly in enumerate(self.get_transformed_patches()):
>> > + for i, thispoly in enumerate(self.get_transformed_patches()):
>> > inside = nxutils.pnpoly(x, y, thispoly)
>> > if inside: ind.append(i)
>> > if len(ind):
>> > @@ -167,7 +167,6 @@
>> > The ith element in the returned sequence is a list of x,y
>> > vertices defining the ith polygon
>> > """
>> > -
>> > verts = self._verts
>> > offsets = self._offsets
>> > usingOffsets = offsets is not None
>> > @@ -451,13 +450,19 @@
>> > __init__.__doc__ = dedent(__init__.__doc__) % kwdocd
>> >
>> > def get_transformed_patches(self):
>> > -
>> > +
>> > xverts, yverts = zip(*self._verts)
>> > xverts = asarray(xverts)
>> > yverts = asarray(yverts)
>> > sizes = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
>> > Nsizes = len(sizes)
>> > transOffset = self.get_transoffset()
>> > +
>> > + # optimize this case for an approx 4x speedup
>> > + if Nsizes == 1:
>> > + xy = asarray([xverts, yverts]).T * sizes[0]
>> > + polys = [xy + offset for offset in 
>> transOffset.seq_xy_tups(self._offsets)]
>> > +
>> > polys = []
>> > for i, loc in enumerate(self._offsets):
>> > xo,yo = transOffset.xy_tup(loc)
>> >
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > 
>> -------------------------------------------------------------------------
>> > This SF.net email is sponsored by DB2 Express
>> > Download DB2 Express C - the FREE version of DB2 express and take
>> > control of your XML. No limits. Just data. Click to get it now.
>> > http://sourceforge.net/powerbar/db2/
>> >
>> >
>> > 
>> ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>

On 5/10/07, Eric Firing <ef...@ha...> wrote:
> Tim,
>
> Based on a *very superficial* quick look, I have two comments:
>
> 1) Since the plan is (or was?) to have one more release before
> specializing to numpy-only support, the ".T" won't work at present.
>
> 2) In the following (possibly mangled by mailer),
>
> > + if Nsizes == 1:
> > + xy = asarray([xverts, yverts]).T * sizes[0]
> > + polys = [xy + offset for offset in
> transOffset.seq_xy_tups(self._offsets)]
>
> I think you can gain additional speedup by eliminating the list
> comprehension. Instead of using seq_xy_tups you can use numerix_xy to
> return a 2-D array (with columns x and y), and simply add that to xy.
>
Thanks for the feedback Eric, I'll rework the patch with your comments
in mind. I also just noticed a rather glaring bug, in that I don't
actually have a 'return polys' after I calculate them in the special
case, which is somewhat embarrassing. I'll fix all this up and submit
a new patch later today.
Cheers,
Tim
> Eric
>
>
> Tim Leslie wrote:
> > Hi All,
> >
> > I've attached a patch which optimizes a particular case of the
> > RegularPolyCollection.get_transformed_patches method. This is
> > particularly useful when using a picker on a scatter plot with ~40,000
> > points (as I happen to be doing) and cuts the time spent in this
> > function from ~4s to ~1s, which accounts for about 50% of the lag in
> > my particular use case.
> >
> > Similar improvements might be possible in the N > 1 case, but I don't
> > have a) a data set or b) the time to work them out with, so hopefully
> > someone is happy to check in this patch as it stands, as I think the
> > N==1 is probably the common case.
> >
> > If there are any problems with the patch let me know and I'll try to
> > fix it up. It's against latest svn (3262)
> >
> > Cheers,
> >
> > Tim
> >
> >
> > ------------------------------------------------------------------------
> >
> > Index: lib/matplotlib/collections.py
> > ===================================================================
> > --- lib/matplotlib/collections.py (revision 3262)
> > +++ lib/matplotlib/collections.py (working copy)
> > @@ -153,7 +153,7 @@
> > if not self.pickable(): return
> > ind = []
> > x, y = mouseevent.x, mouseevent.y
> > - for i, thispoly in enumerate(self.get_transformed_patches()):
> > + for i, thispoly in enumerate(self.get_transformed_patches()):
> > inside = nxutils.pnpoly(x, y, thispoly)
> > if inside: ind.append(i)
> > if len(ind):
> > @@ -167,7 +167,6 @@
> > The ith element in the returned sequence is a list of x,y
> > vertices defining the ith polygon
> > """
> > -
> > verts = self._verts
> > offsets = self._offsets
> > usingOffsets = offsets is not None
> > @@ -451,13 +450,19 @@
> > __init__.__doc__ = dedent(__init__.__doc__) % kwdocd
> >
> > def get_transformed_patches(self):
> > -
> > +
> > xverts, yverts = zip(*self._verts)
> > xverts = asarray(xverts)
> > yverts = asarray(yverts)
> > sizes = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
> > Nsizes = len(sizes)
> > transOffset = self.get_transoffset()
> > +
> > + # optimize this case for an approx 4x speedup
> > + if Nsizes == 1:
> > + xy = asarray([xverts, yverts]).T * sizes[0]
> > + polys = [xy + offset for offset in transOffset.seq_xy_tups(self._offsets)]
> > +
> > polys = []
> > for i, loc in enumerate(self._offsets):
> > xo,yo = transOffset.xy_tup(loc)
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Tim,
Based on a *very superficial* quick look, I have two comments:
1) Since the plan is (or was?) to have one more release before 
specializing to numpy-only support, the ".T" won't work at present.
2) In the following (possibly mangled by mailer),
 > + if Nsizes == 1:
 > + xy = asarray([xverts, yverts]).T * sizes[0]
 > + polys = [xy + offset for offset in 
transOffset.seq_xy_tups(self._offsets)]
I think you can gain additional speedup by eliminating the list 
comprehension. Instead of using seq_xy_tups you can use numerix_xy to 
return a 2-D array (with columns x and y), and simply add that to xy.
Eric
Tim Leslie wrote:
> Hi All,
> 
> I've attached a patch which optimizes a particular case of the
> RegularPolyCollection.get_transformed_patches method. This is
> particularly useful when using a picker on a scatter plot with ~40,000
> points (as I happen to be doing) and cuts the time spent in this
> function from ~4s to ~1s, which accounts for about 50% of the lag in
> my particular use case.
> 
> Similar improvements might be possible in the N > 1 case, but I don't
> have a) a data set or b) the time to work them out with, so hopefully
> someone is happy to check in this patch as it stands, as I think the
> N==1 is probably the common case.
> 
> If there are any problems with the patch let me know and I'll try to
> fix it up. It's against latest svn (3262)
> 
> Cheers,
> 
> Tim
> 
> 
> ------------------------------------------------------------------------
> 
> Index: lib/matplotlib/collections.py
> ===================================================================
> --- lib/matplotlib/collections.py	(revision 3262)
> +++ lib/matplotlib/collections.py	(working copy)
> @@ -153,7 +153,7 @@
> if not self.pickable(): return
> ind = []
> x, y = mouseevent.x, mouseevent.y
> - for i, thispoly in enumerate(self.get_transformed_patches()): 
> + for i, thispoly in enumerate(self.get_transformed_patches()):
> inside = nxutils.pnpoly(x, y, thispoly)
> if inside: ind.append(i)
> if len(ind):
> @@ -167,7 +167,6 @@
> The ith element in the returned sequence is a list of x,y
> vertices defining the ith polygon
> """
> -
> verts = self._verts
> offsets = self._offsets
> usingOffsets = offsets is not None
> @@ -451,13 +450,19 @@
> __init__.__doc__ = dedent(__init__.__doc__) % kwdocd
> 
> def get_transformed_patches(self):
> - 
> +
> xverts, yverts = zip(*self._verts)
> xverts = asarray(xverts)
> yverts = asarray(yverts)
> sizes = sqrt(asarray(self._sizes)*self._dpi.get()/72.0)
> Nsizes = len(sizes)
> transOffset = self.get_transoffset()
> +
> + # optimize this case for an approx 4x speedup
> + if Nsizes == 1:
> + xy = asarray([xverts, yverts]).T * sizes[0]
> + polys = [xy + offset for offset in transOffset.seq_xy_tups(self._offsets)]
> +
> polys = []
> for i, loc in enumerate(self._offsets):
> xo,yo = transOffset.xy_tup(loc)
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel