matplotlib-users Mailing List for matplotlib

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@fi...> writes:
 Flavio> Thanks John, with your patch, it is now possible to plot
 Flavio> vectors with shape(n,1)(column vector). However, vectors
 Flavio> of shape (1,n)(row vector) give the following error:
OK, thanks for the info. I think I've got a working solution now, at
least as far as plot and friends (semilogx, semilogy, and loglog, all
of which use plot plus a scale change) are concerned. There may
still be problems in the other plot commands (scatter, hist, bar, etc
since I haven't tested these yet). I've added the following to my
unit test code
from matplotlib.matlab import *
y1 = arange(10)
y1.shape = 1,10
y2 = arange(10)
y2.shape = 10,1
subplot(411)
plot(y1)
subplot(412)
plot(y2)
subplot(413)
plot(y1, y2)
subplot(414)
X = rand(10,10)
plot(X[:,1], X[1,:], 'o')
savefig('shapes')
I'll try and write some test code for the other plot commands as time
permits. In the meantime, if you know of any other failures, let me
know.
JDH 

> I agree. The current design of matplotlib doesn't really support this
> kind of use because it redraws the entire figure every time and does
> too much duplicate work at the python level. It shouldn't be too hard
> to add some specialized functions for agg that support strip charts.
> I've been planning to do it because we have a need for it here, and
> there is some general on c.l.python for this kind of plotting feature
> in python.
>
> So I can start mulling over the design, can you tell me what kinds of
> real time updates you need - only solid lines or arbitrary symbols
> like 'o' too? Anything else besides line plots?
>
> I'm envisioning some extension code that talks directly to the data
> source and to the agg backend, updating only part of the canvas. The
> blitting functions for GTK/WX/Tk Agg would have to be extended to blit
> only a region of the canvas.
We'd also be interested in updates to real-time graph capabilities. 
We've just started examining Python + wxPython as a platform for 
control of some of our robotic systems. I've gotten a real-time bar 
graph running now, but it's awfully inefficient. I modified the basic 
dynamic_demo_wx.py file to update regularly, and at a forced 10 FPS it 
locks out the wxPython interface on my dual 2 GHZ Mac G5. No way it 
should do that ...
We'd also be interested in strip charts, mostly line based. We'd want 
to do multiple lines per chart. A capability to move through time, or 
zooming, might be useful, but certainly not necessary in a first rev 
(just mentioning it for now).
For bar graphs, we have to update at a given rate (typically up to 
about 25Hz), with different colors per bar (I have yet to do this part 
in the example I'm working on - think of multilpe temperatures being 
displayed, and different colors indicating different zones, per bar; 
nominal, caution, danger).
Having said all that, we're currently using wxPython, and I don't yet 
understand how AGG fits in the picture with matplotlib. :-(
TIA
Stephen

On Fri, 2004年05月28日 at 10:56, John Hunter wrote:
> >>>>> "Gary" == Gary Pajer <pa...@in...> writes:
> 
> Gary> I took out a wristwatch and timed it instead of guessing. I
> Gary> get three frames per second. It's about 4x from where we
> Gary> started, but still slow. I guess I'm just underpowered,
> Gary> although a couple of years ago this was a powerhouse. It
> Gary> seems that matplotlib may not be suited to this task. I
> Gary> don't think it should take 2 GHz just to power a stripchart.
> 
> One more comment here, mainly for Todd. 
> 
> Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
> anim_tk.py, where both scripts are doing the same thing. The profiler
> reveals a good chunk of the time is in
> 
> 103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)
> 
> This may be a tk limitation, but I just wanted to point it out to you
> in case there are any optimizations you can apply to that function.
I tried a few things, but I didn't find anymore performance blunders 
so barring the kind of optimization Perry mentioned, I think we're
stuck. I think most of the time is going into Tk_PhotoPutBlock.
> I'll include the anim_tk.py I'm using for profiling below.
I only got 11-12 FPS (for tkagg) on a 1.7 Ghz Pentium-IV...
Todd

>>>>> "Flavio" == Flavio Codeco Coelho <fcc...@fi...> writes:
 Flavio> Matplotlib 0.54.1 still has trouble plotting column or row
 Flavio> vectors:
Try replacing matplotlib.lines.set_data with the following and let me
know if it passes all your tests. You will need to add ravel to the
list of functions imported from numerix at the top of the lines
module.
 def set_data(self, x, y):
 try: del self._xc, self._yc
 except AttributeError: pass
 self._x = asarray(x, Float)
 self._y = asarray(y, Float)
 if len(self._x.shape)>1: self._x = ravel(self._x)
 if len(self._y.shape)>1: self._y = ravel(self._y)
 if len(self._y)==1 and len(self._x)>1:
 self._y = self._y*ones(self._x.shape, Float)
 if self._useDataClipping: self._xsorted = self._is_sorted(self._x)
Thanks!
JDH

I'll get this one. I also have some tkagg/setupext related changes for
Mac OS-X.
Todd
On Fri, 2004年05月28日 at 12:55, Anthony Joseph Seward wrote:
> The default location for the tk include files is missing. The attached
> patch fixes it.

The default location for the tk include files is missing. The attached
patch fixes it.

>>>>> "James" == James Boyle <bo...@ll...> writes:
 James> Until contouring is implemented, the only way to display 2D
 James> data is by pcolor. I have two observations:
 James> (1) While trying to figure out exactly what pcolor was
 James> doing ( I did not understand the grid registration) I
 James> looked into the matlab documentation. The matlab docs
 James> explained what was going on, so that I could get my values
 James> properly aligned on the grid. This brings up a question -
 James> How close does matplotlib follow Matlab? Will there always
 James> be such a close correspondence in the implementation of
 James> functions such as I found in pcolor?
The matlab interface tries to follow matlab pretty closely, but not
religiously. For example, in matlab you can say
 plot(x,Y) 
where Y is MxN and it will plot all the data in the array. matplotlib
doesn't handle this case, currently. In the case of errorbar, it made
more sense to extend the features (eg to support x and y asymmetric
errorbars) than slavishly follow the matlab signature. 
All other things being equal I try and implement the matlab signature.
It's usually a good motivator because it encourages you to add
features at design time that you might be tempted to leave out.
Why do you ask?
 James> (2) To do quantitative representation using pcolor, a
 James> colorbar function is needed. This feature does not appear
 James> on the list of future goals, I would like it to be
 James> added. I'm not that competent, but I will give it a try
 James> myself. The first few easy things I tried did not work out.
Agreed. I just implemented this. Unzip the following in your
site-packages dir
 http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib.py-0.54.2a.zip
After you have created a pcolor, just do 
 colorbar()
This will resize your axes to make room for the colorbar and display a
vertical colorbar (I haven't yet supported horizontal colorbars, as
matlab does). If you want to use non-default limits for the colormap,
call cmap.set_clim(cmin, cmax) before the pcolor and colorbar, as in
this example
 cmap = ColormapJet(256)
 cmap.set_clim(cmin, cmax)
 pcolor(Z, cmap=cmap)
 colorbar()
Let me know how it goes!
JDH

John Hunter writes
> One more comment here, mainly for Todd. 
> 
> Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
> anim_tk.py, where both scripts are doing the same thing. The profiler
> reveals a good chunk of the time is in
> 
> 103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)
> 
> This may be a tk limitation, but I just wanted to point it out to you
> in case there are any optimizations you can apply to that function.
> 
> I'll include the anim_tk.py I'm using for profiling below.
> 
> Cheers,
> JDH
 
I do believe it is a limitation of the tk api (which the
blitting code uses) that makes writing to pixels of the 
tk window comparatively slow. It is possible to come up
with a tk interface using tkinter3000( aka wck) and some
hairy code to write directly to the window buffer. Eric
Jones has done this for the chaco implementation. Porting
it to matplotlib would take some work (how much I'm not
quite sure). It is isn't important to us right now so
we aren't going to do it for some time. If someone else
is interested they are welcome to. It does mean writing
a C or C++ implementation for each platform (i.e., X, win32, 
aqua). I know that the blitting can be improved by more 
than an order of magnitude in this way.
Perry

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:
 Gary> I took out a wristwatch and timed it instead of guessing. I
 Gary> get three frames per second. It's about 4x from where we
 Gary> started, but still slow. I guess I'm just underpowered,
 Gary> although a couple of years ago this was a powerhouse. It
 Gary> seems that matplotlib may not be suited to this task. I
 Gary> don't think it should take 2 GHz just to power a stripchart.
One more comment here, mainly for Todd. 
Todd, I get 34 FPS on anim.py with GTKAgg and only 21 FPS with the
anim_tk.py, where both scripts are doing the same thing. The profiler
reveals a good chunk of the time is in
 103 2.300 0.022 2.300 0.022 tkagg.py:4(blit)
This may be a tk limitation, but I just wanted to point it out to you
in case there are any optimizations you can apply to that function.
I'll include the anim_tk.py I'm using for profiling below.
Cheers,
JDH
#!/usr/bin/env python2.3
import matplotlib
matplotlib.use('TkAgg')
import matplotlib.matlab
import Tkinter as Tk
import matplotlib.numerix as numerix
fig = matplotlib.matlab.figure(1)
ind = numerix.arange(60)
x_tmp=[]
for i in range(100):
 x_tmp.append(numerix.sin((ind+i)*numerix.pi/15.0))
X=numerix.array(x_tmp)
lines = matplotlib.matlab.plot(X[:,0],'o')
manager = matplotlib.matlab.get_current_fig_manager()
def updatefig(*args):
 updatefig.count += 1
 lines[0].set_ydata(X[:,updatefig.count%60])
 manager.canvas.draw()
 return updatefig.count
updatefig.count=-1
manager.show()
import time
tstart = time.time()
while 1:
 cnt = updatefig()
 if cnt==100: break
 
print 'FPS', 100.0/(time.time() - tstart)

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:
 Gary> I took out a wristwatch and timed it instead of guessing. I
 Gary> get three frames per second. It's about 4x from where we
 Gary> started, but still slow. I guess I'm just underpowered,
 Gary> although a couple of years ago this was a powerhouse. It
 Gary> seems that matplotlib may not be suited to this task. I
 Gary> don't think it should take 2 GHz just to power a stripchart.
I agree. The current design of matplotlib doesn't really support this
kind of use because it redraws the entire figure every time and does
too much duplicate work at the python level. It shouldn't be too hard
to add some specialized functions for agg that support strip charts.
I've been planning to do it because we have a need for it here, and
there is some general on c.l.python for this kind of plotting feature
in python.
So I can start mulling over the design, can you tell me what kinds of
real time updates you need - only solid lines or arbitrary symbols
like 'o' too? Anything else besides line plots?
I'm envisioning some extension code that talks directly to the data
source and to the agg backend, updating only part of the canvas. The
blitting functions for GTK/WX/Tk Agg would have to be extended to blit
only a region of the canvas.
JDH

>>>>> "Gary" == Gary Pajer <pa...@in...> writes:
 Gary> It seems that I can't completely override my choice of
 Gary> backend. E.g., I have set TkAgg as my default back end.
 Gary> Yet if I modify examples/anim.py to include
 Gary> matplotlib.use('GTKAgg') or matplotlib.use('GTK') it will
 Gary> not run. A window appears, but it contains a static,
 Gary> non-changing graph. To run anim.py, I have to modify
 Gary> matplotlibrc. Same behavior the other way: with GTKAgg
 Gary> selected in matplotlibrc, I can't run Todd's anim_tk.py,
 Gary> even with TkAgg selected in the script. Am I doing
 Gary> something stupid?
It works as expected for me, both ways. I can put TkAgg in my rc and
then matplotlib.use('GTKAgg') in anim.py and it works. Ditto the
other way around. Any chance you are working in an IDE? These changes
occur at module load time, and in an IDE such as IDLE, matplotlib will
only be loaded once.
JDH

It seems that I can't completely override my choice of backend.
E.g., I have set TkAgg as my default back end. Yet if I modify
examples/anim.py to include matplotlib.use('GTKAgg') or
matplotlib.use('GTK') it will not run. A window appears, but it contains a
static, non-changing graph. To run anim.py, I have to modify matplotlibrc.
Same behavior the other way: with GTKAgg selected in matplotlibrc, I can't
run Todd's anim_tk.py, even with TkAgg selected in the script. Am I doing
something stupid?
-gary

----- Original Message ----- 
From: "John Hunter" <jdh...@ac...>
> >>>>> "Todd" == Todd Miller <jm...@st...> writes:
>
> Todd> This turned out to be really easy so now canvas.draw
> Todd> triggers a blit and functions more like the other backends.
> Todd> It's in CVS. I also found an extraneous draw() so
> Todd> performance should be better, perhaps 2x.
>
> Yep, I'm getting about 20fps on my system now. Much improved.
>
> Gary, I'm uploading a zip file which has the new matplotlib python
> code. AFAIK, all the changes were made at the python level (right
> Todd?) so you should just be able to unzip this in your site-packages
> dir to try the new code. Let me know if it works, and what kind of
> performance you are getting now.
>
> http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.zip
>
> JDH
I took out a wristwatch and timed it instead of guessing. I get three
frames per second. It's about 4x from where we started, but still slow. I
guess I'm just underpowered, although a couple of years ago this was a
powerhouse. It seems that matplotlib may not be suited to this task. I
don't think it should take 2 GHz just to power a stripchart.
I've got new hardware coming this summer. I get whatever IT gives me (until
I can find funds to buy my own), so I don't know what I'll be getting.
We'll see what happens.
I have another question, but I'll start a new thread for that ...
-gary

John Hunter wrote:
>>>>>>"Peter" == Peter Groszkowski <pgr...@ge...> writes:
>>>>>>
>
> Peter> Hi: The following script:
>
> Peter> #!/usr/bin/env python from matplotlib.matlab import *
>
> Peter> figure(1) plot([0],[0]) show()
>
>Thanks, Peter, for alerting me to this problem. I'm now adding this
>script and several other instances of plotting constants in a variety
>of guises to the unit testing scripts. I think the following fix will
>work for you. Replace matplotlib.axes.Axes.add_line with
>
> def add_line(self, l):
> "Add a line to the list of plot lines"
> self._set_artist_props(l)
> 
> xdata = l.get_xdata()
> ydata = l.get_ydata()
> if l.get_transform() != self.transData:
> xys = self._get_verts_in_data_coords(
> l.get_transform(), zip(xdata, ydata))
> self.update_datalim(xys)
> else:
> # the data are already using the data coord system - no
> # transforms necessary
> minx, maxx = min(xdata), max(xdata)
> miny, maxy = min(ydata), max(ydata)
> if minx==maxx:
> minx -= 1
> maxx += 1
>
> if miny==maxy:
> miny -= 1
> maxy += 1
> 
> corners = ( (minx, miny), (maxx, maxy) )
>
> self.update_datalim(corners)
>
> l.set_clip_box(self.bbox)
> self._lines.append(l)
>
>Passes my tests...
>
>
Just a note that the version of the above method in 0.54.1 still gives me:
Traceback (most recent call last):
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in callback
 self.draw()
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 42, in draw
 agg.draw()
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 296, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/figure.py", line 
130, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axes.py", line 607, 
in draw
 self.xaxis.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axis.py", line 463, 
in draw
 tick.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/axis.py", line 130, 
in draw
 if self.label1On: self.label1.draw(renderer)
 File "/usr/lib/python2.2/site-packages/matplotlib/text.py", line 209, 
in draw
 ismath=self.is_math_text())
 File 
"/usr/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py", 
line 200, in draw_text
 self._renderer.draw_text(
OverflowError: float too large to convert
When doint plot([0],[0]).
The above substitute fixes the problem though...
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

A quick thank you to John,
I just wanted to confirm that 0.54.1 is behaving well on my Win98 system now and I'm looking forward to playing with line styles and more use of mathtext. The speed improvements are very noticeable too.
Thanks!
Gary Ruben 
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

This is a bug fix release
 * rotated text with newlines at all angles should work correctly now
 * fixed errorbar autoscaling and capsize problem 
 * right tick labels now in correct position
 * Added Gary's errorbar color options 
 * fixed some problems relating to singleton plots and constant plots
 * Tweaked TkAgg backend so that canvas.draw() works more like the
 other backends. Fixed a bug resulting in 2 draws per figure
 manager show(). 
 * several small optimizations to improve framerates on animated
 plots.
 * fixed a gtkagg on win98/winME bug
 * added converter=None option to plot_date for dates already in epoch
 format
 * made the figure background transparent in agg so matplotlib output
 can overlay another canvas.
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=241494

>
>
>It turns out that the difference in execution times between these two
>cases is explained by the fact that the default plot style for plot is
>'-' and the default plot style for date is 'o'. 
> 
>
Yes.. changing the style to '-' fixes the performance issue... great!
>There is a small change I can make which is to allow converter to be
>None for the case in which your dates are already epoch. This will
>save some cycles, 
>
Yes.. I would certainly be for it!.. But I'm biased - all my data is 
already epoch.. ;)
-- 
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

Until contouring is implemented, the only way to display 2D data is by 
pcolor.
I have two observations:
(1) While trying to figure out exactly what pcolor was doing ( I did 
not understand the
grid registration) I looked into the matlab documentation. The matlab 
docs explained
what was going on, so that I could get my values properly aligned on 
the grid.
This brings up a question - How close does matplotlib follow Matlab? 
Will there always
be such a close correspondence in the implementation of functions such 
as I found in pcolor?
(2) To do quantitative representation using pcolor, a colorbar function 
 is needed. This feature does not
appear on the list of future goals, I would like it to be added. I'm 
not that competent, but I will
give it a try myself. The first few easy things I tried did not work 
out.

>>>>> "Philippe" == Philippe Strauss <phi...@pr...> writes:
 Philippe> Hello, I would like to use plot_date, with a 'fill'
 Philippe> style of drawing. Is it possible to do that?
date_plot doesn't do too much - it converts your dates to seconds
since the epoch and sets a date ticker and formatter. You can do the
same yourself, and then call whatever function you want. To borrow
and adapt Peter's example above. 
 import time
 from matplotlib.dates import EpochConverter
 from matplotlib.matlab import *
 from matplotlib.ticker import DateFormatter, DayLocator, HourLocator
 now=time.time()
 then=now-60*60*24*2
 dates=arange(then, now, 20) #Say have a point every 20 secs..
 vals= sin(0.001*pi*dates/60.0)
 fmt = DateFormatter('%D')
 days = DayLocator(1)
 hours = HourLocator(12)
 ax = subplot(111)
 ax.xaxis.set_major_locator(days)
 ax.xaxis.set_major_formatter(fmt)
 ax.xaxis.set_minor_locator(hours)
 fill(dates, vals)
 ax.autoscale_view()
 show()
See http://matplotlib.sf.net/matplotlib.ticker.html for more
information of tick locators and formaters. See
http://matplotlib.sf.net/matplotlib.dates.html for info on how to
convert your datetime instances to seconds since the epoch.
Cheers,
JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:
 Peter> Hi: I was wondering whether anyone else has noticed a
 Peter> performance difference between using plot_date() and
 Peter> plot(). Here is a dummy script:
It turns out that the difference in execution times between these two
cases is explained by the fact that the default plot style for plot is
'-' and the default plot style for date is 'o'. 
Drawing a long connected line is still much faster than drawing a
bunch of circles. I think if I start using collections in Line2D to
draw markers we'll see a performance boost there, but until I do it
it's hard to estimate how much. 
There is a small change I can make which is to allow converter to be
None for the case in which your dates are already epoch. This will
save some cycles, but is negligible compared to the arc drawing time
in your example; from the profiler:
 60480 7.470 0.000 7.470 0.000 backend_agg.py:117(draw_arc)
 60480 0.200 0.000 0.200 0.000 dates.py:410(epoch)
But if I can get the marker performance much better by using
collections, then the conversion step will be worth bypassing.
JDH

>>>>> "Gary" == Gary Ruben <ga...@em...> writes:
 Gary> Hi John, I can confirm that 0.54.1a fixes the crashing
 Gary> problem - thanks! However, I tested it with a few errorbar
 Gary> plots and I noticed a few things. You've changed the
 Gary> errorbar bar-ends to use markers, but the scaling is now
 Gary> different and seems no longer to be settable via the capsize
 Gary> parameter. The autoscaling no longer works either.
Doh! There was one major problem in that I had commented out the
return in maplotlib.matlab.errorbar during debugging. This explains
all your problems with working on the return lines. The body of that
function should be
 try: ret = gca().errorbar(x, y, yerr, xerr, fmt, ecolor, capsize)
 except ValueError, msg:
 msg = raise_msg_to_str(msg)
 error_msg(msg)
 else:
 draw_if_interactive()
 return ret
I don't see any problems with the capsize or autoscaling. Perhaps
with this new code you can see if you are still having troubles and
post an example.
Sorry for the troubles,
JDH

Hello,
I would like to use plot_date, with a 'fill' style of drawing.
Is it possible to do that?
Thanks
--
Philippe Strauss, ingénieur ETS, associé
phi...@pr...
http://www.practeo.ch/

Hi:
I was wondering whether anyone else has noticed a performance difference 
between using plot_date() and plot().
Here is a dummy script:
#!/usr/bin/env python
import time
from matplotlib.dates import EpochConverter
from matplotlib.matlab import *
from matplotlib.ticker import DateFormatter, DayLocator, HourLocator
useDates=0
now=time.time()
weekAgo=now-60*60*24*7
dates=arange(weekAgo, now, 10) #Say have a point every 10 secs..
vals=dates
if useDates:
 #Date plot
 fmt=DateFormatter('%D')
 days=DayLocator(1)
 hours=HourLocator(12)
 converter = EpochConverter()
 ax = subplot(111)
 plot_date(dates, vals, converter)
 ax.xaxis.set_major_locator(days)
 ax.xaxis.set_major_formatter(fmt)
 ax.xaxis.set_minor_locator(hours)
 #What will this do??
 #ax.autoscale_view()
else:
 #Regular plot
 plot(dates, vals)
ylabel('Number of points: '+str(len(dates)))
xlabel('time')
grid(True)
show()
I use python2.2 running on a 3.2 PIV with 2GB or ram and when I use 
regular plotting, this takes ~1sec. With plot_date() it takes ~8sec.
I really like the flexibility of the way dates are handled but this 
seems to be too much of a performance hit for me to use (I ofter have 
data sets of 500 000 points). So my question is whether I am perhaps 
missing something trivial and not setting things up right. I cannot run 
any of the date_demo scripts because don't have python2.3 so cannot test 
how fast they run.
I will need to setup the x-axis labeling as dates, but now it seems it 
would be faster to just update the xticslabels of a "regular" plot.
Any thoughts?
Thanks.
--
Peter Groszkowski Gemini Observatory
Tel: +1 808 974-2509 670 N. A'ohoku Place
Fax: +1 808 935-9235 Hilo, Hawai'i 96720, USA

Hi John,
I can confirm that 0.54.1a fixes the crashing problem - thanks!
However, I tested it with a few errorbar plots and I noticed a few things.
You've changed the errorbar bar-ends to use markers, but the scaling is now different and seems no longer to be settable via the capsize parameter.
The autoscaling no longer works either.
If I use the example:
--
from matplotlib.matlab import *
t = arange(0.1, 4, 0.1)
s = exp(-t)
e = 0.1*randn(len(s))
f = 0.1*randn(len(s))
l1 = errorbar(t, s, e, f)
set(l1, 'color', 'g')
show()
--
a traceback is generated:
Traceback (most recent call last):
 File "errorbar_demo.pyw", line 10, in ?
 set(l1, 'color', 'g')
 File "C:\APPS\PYTHON23\Lib\site-packages\matplotlib\matlab.py", line 1275, in set
 func = getattr(o,funcName) 
AttributeError: 'NoneType' object has no attribute 'set_color'
I'm pretty sure this worked in 0.53
If you change 
l1 = errorbar(t, s, e, f)
to
l1,l2 = errorbar(t, s, e, f)
you get another traceback:
Traceback (most recent call last):
 File "errorbar_demo.pyw", line 8, in ?
 l1,l2 = errorbar(t, s, e, f)
TypeError: unpack non-sequence
This worked in 0.53
If you remove the set() call, the plot appears, but you'll see the autoscaling is wonky.
I discovered these because I was trying to reproduce the plots on my python page <http://users.bigpond.net.au/gazzar/python.html>
When I try to reproduce the first one, I get a traceback. If I remove the l1,e1 assignment part and the legend call, no traceback occurs. I don't understand why:
The traceback produced is:
Traceback (most recent call last):
 File "_mass_matplotlib.py", line 17, in ?
 l1,e1=errorbar(m, PrimeVals(t), [NegErrs(t), PosErrs(t)], fmt='r')
TypeError: unpack non-sequence
When I try to reproduce the second plot, the plot window appears.
The scaling shown on my webpage is the autoscaling produced with 0.53 (xaxis=2->4.5, yaxis=5.?->5.32), but the autoscaling in 0.54.1a has the axis ranges of (xaxis=1->5.5, yaxis=4->6.5). Also I have to squint to see the bar-ends ;-) <- (smiley of my left eye squinting)
regards and thanks for sorting out the GTKAgg stuff,
Gary
-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> The good news is I can replicate it on my windows 98 box
 John> (and a windows ME box). I've had no troubles on XP. It is
 John> triggered by importing matplotlib.backends._gtkagg. That's
 John> all I know so far, but I should be able to figure it out
 John> from here.
I rewrote _gtkagg using cxx and this seems to have fixed the problem
(at least on my test systems). Flush the old, and try:
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.1a.win32-py2.3.exe
FYI, this should have your errorbar fixes in as well.
Good luck!
JDH