matplotlib-devel Mailing List for matplotlib (Page 3)

We've built 0.87 with Python 2.4.2/GCC 3.4.3 on Solaris, HP-UX, Tru64
UNIX, IRIX, and Redhat Linux. It works fine on all platforms except
HP-UX/PA (HP-UX 11.23/IA64 works fine). Some of the examples, like
two_scales.py, work fine if run once. However, with
~/.matplotlib/ttffont.cache existing, a second run of two_scales.py
(or any other example), fails with the following:
 terminate called after throwing an instance of 'Py::RuntimeError'
Anyone have any ideas?
-- 
albert chin (ch...@th...)

For those of you who don't follow the user's list.... Thanks Charlie
for doing this
Notable notes:
 - Built against numpy-0.9.5
 - A wealth of bugfixes
http://sourceforge.net/project/showfiles.php?group_id=80706
===============================================================
2006年02月22日 Released 0.87
2006年02月21日 Fixed portrait/landscape orientation in postscript backend - DSD
2006年02月21日 fix bug introduced in yesterday's bug fix - SC
2006年02月20日 backend_gtk.py FigureCanvasGTK.draw(): fix bug reported by
 David Tremouilles - SC
2006年02月20日 Remove the "pygtk.require('2.4')" error from
 examples/embedding_in_gtk2.py - SC
2006年02月18日 backend_gtk.py FigureCanvasGTK.draw(): simplify to use (rather than
 duplicate) the expose_event() drawing code - SC
2006年02月12日 Added stagger or waterfall plot capability to LineCollection;
 illustrated in examples/collections.py. - EF
2006年02月11日 Massive cleanup of the usetex code in the postscript
backend. Possibly
 fixed the clipping issue users were reporting with older versions of
 ghostscript - DSD
2006年02月11日 Added autolim kwarg to axes.add_collection. Changed
 collection get_verts() methods accordingly. - EF
2006年02月09日 added a temporary rc parameter text.dvipnghack, to allow
Mac users to get nice
 results with the usetex option. - DSD
2006年02月09日 Fixed a bug related to setting font sizes with the usetex
option. - DSD
2006年02月09日 Fixed a bug related to usetex's latex code. - DSD
2006年02月09日 Modified behavior of font.size rc setting. You should
define font.size in pts,
 which will set the "medium" or default fontsize. Special
text sizes like axis
 labels or tick labels can be given relative font sizes like
small, large,
 x-large, etc. and will scale accordingly. - DSD
2006年02月08日 Added py2exe specific datapath check again. Also added new
 py2exe helper function get_py2exe_datafiles for use in py2exe
 setup.py scripts. - CM
2006年02月02日 Added box function to pylab
2006年02月02日 Fixed a problem in setupext.py, tk library formatted in unicode
 caused build problems - DSD
2006年02月01日 Dropped TeX engine support in usetex to focus on LaTeX. - DSD
2006年01月29日 Improved usetex option to respect the serif, sans-serif, monospace,
 and cursive rc settings. Removed the font.latex.package rc setting,
 it is no longer required - DSD
2006年01月29日 Fixed tex's caching to include font.family rc information - DSD
2006年01月29日 Fixed subpixel rendering bug in *Agg that was causing
 uneven gridlines - JDH
2006年01月28日 Added fontcmd to backend_ps's RendererPS.draw_tex, to support other
 font families in eps output - DSD
2006年01月28日 Added MaxNLocator to ticker.py, and changed contour.py to
 use it by default. - EF
2006年01月28日 Added fontcmd to backend_ps's RendererPS.draw_tex, to support other
 font families in eps output - DSD
2006年01月27日 Buffered reading of matplotlibrc parameters in order to allow
 'verbose' settings to be processed first (allows verbose.report
 during rc validation process) - DSD
2006年01月27日 Removed setuptools support from setup.py and created a
 separate setupegg.py file to replace it. - CM
2006年01月26日 Replaced the ugly datapath logic with a cleaner approach from
 http://wiki.python.org/moin/DistutilsInstallDataScattered.
 Overrides the install_data command. - CM
2006年01月24日 Don't use character typecodes in cntr.c --- changed to use
 defined typenumbers instead. - TEO
2006年01月24日 Fixed some bugs in usetex's and ps.usedistiller's dependency
2006年01月24日 Added masked array support to scatter - EF
2006年01月24日 Fixed some bugs in usetex's and ps.usedistiller's dependency
 checking - DSD

Hi Alex,
On Friday 17 February 2006 18:48, Alex Gontmakher wrote:
> Here it goes again. And sorry for the delay, I was busy with other
> things, will catch up...
> Yes, I believe it does not conflict with the savefig's
> landscape-vs-portrait handling. Some of the EPS viewers need this flag
> in order to show the plot in its original orientation (read: heads up).
>
> In addition, I find the code in lines 1049-1053 of bakend_ps.py somewhat
> strange: in my understanding, landsape means that the plot's "up"
> direction is oriented to the left, i.e., the plot is rotated 90CCW. This
> has nothing to do with the plot's width and height. However, that's not
> my code I wouldn't like to fix that myself without knowing the original
> author's intent. Comments?
I'm not the original maintainer of the postscript backend, but I agree that 
those lines were strange. I just committed my changes to cvs, 
portrait/landscape orientation should be better supported now.
Darren

Works perfectly using the cvs version!
Great!
Thanks again,
David
2006年2月21日, Steve Chaplin <ste...@ya...>:
> The previous fix was not quite right.
> self._need_redraw =3D True
> should come before
> if GTK_WIDGET_DRAWABLE(self):
>
> It is now (hopefully) fixed in CVS.
>
> regards,
> Steve
>
>

On Mon, 2006年02月20日 at 20:38 -0800,
mat...@li... wrote:
> Hi,
> No more traceback with the matplolib cvs version. 
> However, I observe now some strange behavior. 
> I join a new example code.
> When you launch the script and press replot button (circle should
> become a line in both tab), then switch to the second tab everything
> ok. But back to the first tab and press replot (line should become a
> circle in both tab), switch to the second tab... still see a line. If
> you use the "pan" tool in the toolbar and move a bit the graph then
> the figure is the updated and become a circle.
> 
> Regards,
> 
> David
The previous fix was not quite right.
 self._need_redraw = True
should come before
 if GTK_WIDGET_DRAWABLE(self):
It is now (hopefully) fixed in CVS.
regards,
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Tom" == Tom Denniston <tom...@al...> writes:
 Tom> I am generating a few hundred graphs and doing so takes on
 Tom> the order of about 10-15 minutes. Which seems to me rather
 Tom> slow. When I profile my code it identifies the calls to
 Tom> get_yticklabels and get_xticklabels as taking over 90% of the
 Tom> time. This seems strange but my calls to these functions are
 Tom> merely a sort round about way of setting the font size of the
 Tom> axis tick labels and suppressing the text for the
 Tom> xticklabels. Is there a more efficient and cleaner way to do
 Tom> this? artist.setp(axes.get_yticklabels(), visible=True,
 Tom> fontsize=7) artist.setp(axes.get_xticklabels(),
 Tom> visible=False)
This is a known performance bottleneck. There are two reasons it is
slow. Every tick label is handled as an independent object, when they
in most cases share most of their properties (font size, orientation)
and so could be better handled as a TextCollection, which does not
exist yet. The second reason is that the text layout engine is doing
layout for newline separated strings with an arbitrary rotation for
every tick label, which is almost never used. So some special case
optimizations to handle the no rotation, no newline text instances
(basically just bypass the layout machinery) would help a lot here.
Are you using matplotlib mathtext also, by chance? This slows things
down a bit too, though is better in recent versions.
JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> It goes deeper -- even Figure.add_axes() returns an old
 Andrew> Axes instance if the rect given has been seen before. I'd
 Andrew> argue that people delving into the OO innards of
 Andrew> matplotlib should be able to handle keeping a reference to
 Andrew> instances of Axes they've created. Can we change this
 Andrew> behavior or would it cause massive breakage somewhere?
This used to be handled in pylab helpers, but because there was some
desire for OO matplotlib and pylab to have the same functionality, and
to simplify the code, I moved the current axes handling into the
figure class. The core of the current axes handling is what is
causing the problem you have.
Did you see this in the add_axes docstring
 Eg, if you want two axes that are
 otherwise identical to be added to the axes, make sure you give them
 unique labels:
 add_axes((l,b,w,h), label='1')
 add_axes((l,b,w,h), label='2')
Ie, the problem and the workaround are explicitly mentioned in the
add_axes docs, and since the functionality is fairly core, I am
inclined to leave it. One might do
for i,data enumerate(mydata):
 a = fig.add_axes(somerect, label='axes%d'%i)
and then update some rect later.
JDH

Hi,
No more traceback with the matplolib cvs version.
However, I observe now some strange behavior.
I join a new example code.
 When you launch the script and press replot button (circle should become a
line in both tab), then switch to the second tab everything ok. But back to
the first tab and press replot (line should become a circle in both tab),
switch to the second tab... still see a line. If you use the "pan" tool in
the toolbar and move a bit the graph then the figure is the updated and
become a circle.
Regards,
David
2006年2月20日, Steve Chaplin <ste...@ya...>:
>
> On Sun, 2006年02月19日 at 22:09 -0800,
> mat...@li... wrote:
> > Here is a quick and dirty minimal code reproducing the problem.
> >
> > David
> [snip ...]
>
> It is slightly obscure - why would you write a callback to display an
> widget in a notebook tab which is not visible? However, the
> FigureCanvasGTK should be able to handle this case so it is a bug.
>
> The problem is with the "canvas2.draw()" line.
> When you run the test the second canvas widget is not immediately
> displayed, so it does not get realized() and its gdk.Window has not been
> created which causes problems with code which uses the gdk.Window. The
> expose_event() code checks for this case with
> if GTK_WIDGET_DRAWABLE(self):
> but FigureCanvasGTK.draw() was missing this check.
>
> Its fixed now in CVS (I also simplified the draw() code a little).
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

Here it goes again. And sorry for the delay, I was busy with other 
things, will catch up...
Yes, I believe it does not conflict with the savefig's 
landscape-vs-portrait handling. Some of the EPS viewers need this flag 
in order to show the plot in its original orientation (read: heads up).
In addition, I find the code in lines 1049-1053 of bakend_ps.py somewhat 
strange: in my understanding, landsape means that the plot's "up" 
direction is oriented to the left, i.e., the plot is rotated 90CCW. This 
has nothing to do with the plot's width and height. However, that's not 
my code I wouldn't like to fix that myself without knowing the original 
author's intent. Comments?
-- Alex
Index: lib/matplotlib/backends/backend_ps.py
===================================================================
RCS file: 
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_ps.py,v
retrieving revision 1.81
diff -r1.81 backend_ps.py
1054a1055,1056
 > else:
 > print >>fh, "%%Orientation: Portrait"

Thanks for the fix. I'll try the CVS version ASAP.
The small example I sent was just to reproduce the problem.
I was not able to trace the problem myself as I'm a just a poor scientist
and not a software engineer (even if I like programming)
To make my need a bit more clear:
Roughly, I have a notebook to display my data 3 different ways, each in one
notebook tabs.
Data processing is controlled in the first notebook so after changes I have
to update the plots in the others tabs.
I could update the plot each time I make a tab visible but it will
unnecessarily slow down the switching in between tabs.
Again thank you very much for your help.
And thanks to all matplotlib developers for their great work!
Hope, Numpy/Scipy/Matplotlib/Pytables/Pyvisa/pygtk will attract more and
more users.
I strongly suggest all scientist to try this combination, it's amazingly
powerful.
David
2006年2月20日, Steve Chaplin <ste...@ya...>:
>
> On Sun, 2006年02月19日 at 22:09 -0800,
> mat...@li... wrote:
> > Here is a quick and dirty minimal code reproducing the problem.
> >
> > David
> [snip ...]
>
> It is slightly obscure - why would you write a callback to display an
> widget in a notebook tab which is not visible? However, the
> FigureCanvasGTK should be able to handle this case so it is a bug.
>
> The problem is with the "canvas2.draw()" line.
> When you run the test the second canvas widget is not immediately
> displayed, so it does not get realized() and its gdk.Window has not been
> created which causes problems with code which uses the gdk.Window. The
> expose_event() code checks for this case with
> if GTK_WIDGET_DRAWABLE(self):
> but FigureCanvasGTK.draw() was missing this check.
>
> Its fixed now in CVS (I also simplified the draw() code a little).
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.co=
m
>
>

On Sun, 2006年02月19日 at 22:09 -0800,
mat...@li... wrote:
> Here is a quick and dirty minimal code reproducing the problem.
> 
> David
[snip ...]
It is slightly obscure - why would you write a callback to display an
widget in a notebook tab which is not visible? However, the
FigureCanvasGTK should be able to handle this case so it is a bug.
The problem is with the "canvas2.draw()" line.
When you run the test the second canvas widget is not immediately
displayed, so it does not get realized() and its gdk.Window has not been
created which causes problems with code which uses the gdk.Window. The
expose_event() code checks for this case with 
 if GTK_WIDGET_DRAWABLE(self):
but FigureCanvasGTK.draw() was missing this check.
Its fixed now in CVS (I also simplified the draw() code a little).
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

 I am generating a few hundred graphs and doing so takes on the order of
about 10-15 minutes. Which seems to me rather slow. When I profile my cod=
e
it identifies the calls to get_yticklabels and get_xticklabels as taking
over 90% of the time. This seems strange but my calls to these functions
are merely a sort round about way of setting the font size of the axis tick
labels and suppressing the text for the xticklabels. Is there a more
efficient and cleaner way to do this?
 artist.setp(axes.get_yticklabels(), visible=3DTrue, fontsize=3D7)
 artist.setp(axes.get_xticklabels(), visible=3DFalse)
I am using matplotlib version 0.83.1 and the .png format for my output, if
that helps. Though the profiler seems to suggest that the output is
blazingly fast and it is only these calls to the get_?ticklabels that are
slow.

Note:
 The "crash" only occurs if you run the script and press directly the
replot button.
If you click on the second page of the notebook then back to the first and
"replot"
no problem. Though no problem at all if the "# GTK+ 2.x style draw()" is
used in
matplotlib_gtk.py
Regards,
David
2006年2月19日, David TREMOUILLES <dav...@gm...>:
>
> Here is a quick and dirty minimal code reproducing the problem.
>
> David
>
> 2006年2月17日, Steve Chaplin <ste...@ya...>:
> >
> > On Wed, 2006年02月15日 at 20:36 -0800,
> > mat...@li... wrote:
> > > Hello,
> > >
> > > I'm using matplotlib figures in several places at a time in my GT=
K
> >
> > > based app (means different page in a notebook).
> > > I have trace a bug I partially solved but still doubting if it is a
> > > matplotlib bug or a bad design of my app.
> > >
> > > Matplotlib 0.86.2
> > > pygtk-2.8.4
> > > gtk+-2.8.6
> > >
> > > Here is the problem:
> > >
> > > in matplotlib/backends/backend_gtk.py file, in
> > > class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
> > > ... in:
> > >
> > > def draw(self):
> > > # synchronous window redraw (like GTK+ 1.2 used to do)
> > > # Note: this does not follow the usual way that GTK redraws,
> > > # which is asynchronous redraw using calls to
> > > gtk_widget_queue_draw(),
> > > # which triggers an expose-event
> > >
> > > # GTK+ 2.x style draw()
> > > 1- self._need_redraw =3D True
> > > 1- self.queue_draw()
> > >
> > > # synchronous draw (needed for animation)
> > > 2- x, y, w, h =3D self.allocation
> > > 2- if w<3 or h<3: return # empty fig
> > >
> > > 2- self._pixmap_prepare (w, h)
> > > 2- self._render_figure(self._pixmap, w, h)
> > > 2- self._need_redraw =3D False
> > > 2- self.window.draw_drawable (self.style.fg_gc[self.state],
> > > 2- self._pixmap, 0, 0, 0, 0, w, h)
> > >
> > >
> > > If I use method 1- (and comment 2-) no problem, all run smoothly...
> > > But using the default method, switching on method 2- (and comment 1-)
> > > I get the followig error message when trying to redraw one of the
> > > figure
> > > (the figure is plotted correctly the first time. No change made to th=
e
> > > figure, just redrawing...)
> > >
> > > ***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
> > > GtkWarning: gdk_pixmap_new: assertion `(drawable !=3D NULL) || (depth=
 !=3D
> >
> > > -1)' failed
> > > self._pixmap_height)
> > > Traceback (most recent call last):
> > > ...
> > > self.canvas_leak.draw()
> > > File
> > > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", lin=
e
> >
> > > 250, in draw
> > > self._pixmap_prepare (w, h)
> > > File
> > > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", lin=
e
> > > 298, in _pixmap_prepare
> > > self._pixmap_height)
> > > RuntimeError: could not create GdkPixmap object
> > >
> > > Somebody has a clue ???
> > >
> > Its difficult to say if its bug in backend_gtk.py, it depends on exactl=
y
> > what your application is doing. You would need to post a minimal test
> > case that demonstrates the bug so we could see whats going on.
> >
> > Steve
> >
> > Send instant messages to your online friends
> > http://au.messenger.yahoo.com
> >
> >
>
>

Here is a quick and dirty minimal code reproducing the problem.
David
2006年2月17日, Steve Chaplin <ste...@ya...>:
>
> On Wed, 2006年02月15日 at 20:36 -0800,
> mat...@li... wrote:
> > Hello,
> >
> > I'm using matplotlib figures in several places at a time in my GTK
> > based app (means different page in a notebook).
> > I have trace a bug I partially solved but still doubting if it is a
> > matplotlib bug or a bad design of my app.
> >
> > Matplotlib 0.86.2
> > pygtk-2.8.4
> > gtk+-2.8.6
> >
> > Here is the problem:
> >
> > in matplotlib/backends/backend_gtk.py file, in
> > class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
> > ... in:
> >
> > def draw(self):
> > # synchronous window redraw (like GTK+ 1.2 used to do)
> > # Note: this does not follow the usual way that GTK redraws,
> > # which is asynchronous redraw using calls to
> > gtk_widget_queue_draw(),
> > # which triggers an expose-event
> >
> > # GTK+ 2.x style draw()
> > 1- self._need_redraw = True
> > 1- self.queue_draw()
> >
> > # synchronous draw (needed for animation)
> > 2- x, y, w, h = self.allocation
> > 2- if w<3 or h<3: return # empty fig
> >
> > 2- self._pixmap_prepare (w, h)
> > 2- self._render_figure(self._pixmap, w, h)
> > 2- self._need_redraw = False
> > 2- self.window.draw_drawable (self.style.fg_gc[self.state],
> > 2- self._pixmap, 0, 0, 0, 0, w, h)
> >
> >
> > If I use method 1- (and comment 2-) no problem, all run smoothly...
> > But using the default method, switching on method 2- (and comment 1-)
> > I get the followig error message when trying to redraw one of the
> > figure
> > (the figure is plotted correctly the first time. No change made to the
> > figure, just redrawing...)
> >
> > ***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
> > GtkWarning: gdk_pixmap_new: assertion `(drawable != NULL) || (depth !=
> > -1)' failed
> > self._pixmap_height)
> > Traceback (most recent call last):
> > ...
> > self.canvas_leak.draw()
> > File
> > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> > 250, in draw
> > self._pixmap_prepare (w, h)
> > File
> > "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> > 298, in _pixmap_prepare
> > self._pixmap_height)
> > RuntimeError: could not create GdkPixmap object
> >
> > Somebody has a clue ???
> >
> Its difficult to say if its bug in backend_gtk.py, it depends on exactly
> what your application is doing. You would need to post a minimal test
> case that demonstrates the bug so we could see whats going on.
>
> Steve
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>

Hi,
I've got a situation where I'd like to create several instances of Axes
but not set their position until later. It seems I have to jump through
hoops to actually create a new axes, contrary to my expectation:
$ ipython -pylab
In [1]: a=axes()
In [2]: a
Out[2]: <matplotlib.axes.Subplot instance at 0x2aaab158a758>
In [3]: b=axes()
In [4]: b
Out[4]: <matplotlib.axes.Subplot instance at 0x2aaab158a758>
I can see what's happening here:
 1. pylab.axes() calls subplot(111) when no arguments are given.
 2. subplot(111) uses some smarts to figure out if an Axes instance for
subplot(111) has already been given and, if so, returns a reference to that.
Both points 1 and 2 seem reasonable on their own, but when combined, as
in my example, the outcome is not intuitive. Is this behavior desired?
Does anyone depend on it?
It goes deeper -- even Figure.add_axes() returns an old Axes instance if
the rect given has been seen before. I'd argue that people delving into
the OO innards of matplotlib should be able to handle keeping a
reference to instances of Axes they've created. Can we change this
behavior or would it cause massive breakage somewhere?
Cheers!
Andrew

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 wid=
e=20
as my screen will allow. So thats the first issue. The second is this: if I=
=20
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):
=A0 File "<stdin>", line 1, in ?
=A0 File "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt=
=2Epy",=20
line 47, in show
=A0 =A0 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=20
only nondefault rc setting is the choice of backend.
Darren

Ew. Ok. No thanks. :-) I'll just stick with numpy 0.9.4 for now.
I appreciate the speedy response.
--bb
On 2/17/06, David M. Cooke <co...@ph...> wrote:
>
> Bill Baxter <wb...@gm...> writes:
>
> > After upgrading to numpy 0.9.5 (numpy-0.9.5.win32-py2.4.exe) running th=
e
> > following script causes a crash of python.exe:
> >
> > -------------test.py-----------------
> > import pylab
> > ----------------------------------------
> >
> >
> > In my .matplotlibrc file I have the following:
> > -------------
> > backend : WXAgg
> > numerix : numpy
> > -------------
> >
> >
> > Reinstalling numpy 0.9.4 fixed the problem.
> >
> > Matplotlib version is 0.86.2-win32-py2.4
> > I also tried reinstalling matplotlib, but that didn't help.
>
> You'll have to recompile matplotlib against the newer numpy.
>
> --
> |>|\/|<
>
> /------------------------------------------------------------------------=
--\
> |David M. Cooke
> http://arbutus.physics.mcmaster.ca/dmc/
> |co...@ph...
>
--
William V. Baxter III
OLM Digital
Kono Dens Building Rm 302
1-8-8 Wakabayashi Setagaya-ku
Tokyo, Japan 154-0023
+81 (3) 3422-3380

Bill Baxter <wb...@gm...> writes:
> After upgrading to numpy 0.9.5 (numpy-0.9.5.win32-py2.4.exe) running the
> following script causes a crash of python.exe:
>
> -------------test.py-----------------
> import pylab
> ----------------------------------------
>
>
> In my .matplotlibrc file I have the following:
> -------------
> backend : WXAgg
> numerix : numpy
> -------------
>
>
> Reinstalling numpy 0.9.4 fixed the problem.
>
> Matplotlib version is 0.86.2-win32-py2.4
> I also tried reinstalling matplotlib, but that didn't help.
You'll have to recompile matplotlib against the newer numpy.
-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

After upgrading to numpy 0.9.5 (numpy-0.9.5.win32-py2.4.exe) running the
following script causes a crash of python.exe:
-------------test.py-----------------
import pylab
----------------------------------------
In my .matplotlibrc file I have the following:
-------------
backend : WXAgg
numerix : numpy
-------------
Reinstalling numpy 0.9.4 fixed the problem.
Matplotlib version is 0.86.2-win32-py2.4
I also tried reinstalling matplotlib, but that didn't help.
--Bill Baxter

On Wed, 2006年02月15日 at 20:36 -0800,
mat...@li... wrote:
> Hello,
> 
> I'm using matplotlib figures in several places at a time in my GTK
> based app (means different page in a notebook).
> I have trace a bug I partially solved but still doubting if it is a
> matplotlib bug or a bad design of my app.
> 
> Matplotlib 0.86.2
> pygtk-2.8.4
> gtk+-2.8.6
> 
> Here is the problem:
> 
> in matplotlib/backends/backend_gtk.py file, in 
> class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
> ... in:
> 
> def draw(self):
> # synchronous window redraw (like GTK+ 1.2 used to do)
> # Note: this does not follow the usual way that GTK redraws,
> # which is asynchronous redraw using calls to
> gtk_widget_queue_draw(),
> # which triggers an expose-event
> 
> # GTK+ 2.x style draw()
> 1- self._need_redraw = True
> 1- self.queue_draw()
> 
> # synchronous draw (needed for animation)
> 2- x, y, w, h = self.allocation
> 2- if w<3 or h<3: return # empty fig
> 
> 2- self._pixmap_prepare (w, h)
> 2- self._render_figure(self._pixmap, w, h)
> 2- self._need_redraw = False
> 2- self.window.draw_drawable (self.style.fg_gc[self.state],
> 2- self._pixmap, 0, 0, 0, 0, w, h)
> 
> 
> If I use method 1- (and comment 2-) no problem, all run smoothly...
> But using the default method, switching on method 2- (and comment 1-)
> I get the followig error message when trying to redraw one of the
> figure
> (the figure is plotted correctly the first time. No change made to the
> figure, just redrawing...)
> 
> ***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
> GtkWarning: gdk_pixmap_new: assertion `(drawable != NULL) || (depth !=
> -1)' failed
> self._pixmap_height)
> Traceback (most recent call last):
> ... 
> self.canvas_leak.draw()
> File
> "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> 250, in draw
> self._pixmap_prepare (w, h)
> File
> "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line
> 298, in _pixmap_prepare
> self._pixmap_height)
> RuntimeError: could not create GdkPixmap object
> 
> Somebody has a clue ???
> 
Its difficult to say if its bug in backend_gtk.py, it depends on exactly
what your application is doing. You would need to post a minimal test
case that demonstrates the bug so we could see whats going on.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

"Sajec, Mike TQO" <ms...@tq...> writes:
> Instead of only accepting an (mxn) matrix (x) and creating (n) boxplots
> from the columns of (x), optionally in place of the (mxn) matrix accept
> a list of numeric arrays which can be any length, and create boxplots
> for each of the arrays in the list.
In my opinion the idea is good. You can get the same result by calling
boxplot separately for each array, but then you need to keep track of
the positions and fix the axis limits manually afterwards. E.g.,
x1 = normal(10,3,[100,3])
x2 = normal(10,5,[150,2])
x3 = normal(10,1,[1000,4])
pos = 1
for x in x1, x2, x3:
 newpos = pos + x.shape[1]
 boxplot(x, positions=range(pos, newpos))
 pos = newpos
axis([0.5, pos-0.5, 0, 30])
Your implementation seems to reshape each array to only have one
column. I think it would be more useful and less surprising to plot
each column of each array in the list, as in the example above.
-- 
Jouni

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> Starting from CVS mpl, I tested examples/quadmesh_demo.py
 Eric> and found that it worked only with numarray; Numeric and
 Eric> numpy refused to cast the Float64 X and Y arrays to Float32.
 Eric> So I fixed that in CVS by using the astype method. Now the
 Eric> demo works with numpy and numarray, but segfaults with
 Eric> Numeric. I have not tried to track the problem down; it is
 Eric> very low priority for me. Given the momentum towards numpy,
 Eric> it might not be worth tracking down at all.
I'm a little hesitant to leave in a segfault because they can be
very difficult to track down. Perhaps Alex and/or Paul can address
this.
If it proves too difficult, we should at least check for Numeric in
calls to quadmesh and generate a warning before the segfault occurs.
JDH

>>>>> "Sajec," == Sajec, Mike TQO <ms...@tq...> writes:
 Sajec> I would like to propose modifying the boxplot function as
 Sajec> follows: Instead of only accepting an (mxn) matrix (x) and
 Sajec> creating (n) boxplots from the columns of (x), optionally
 Sajec> in place of the (mxn) matrix accept a list of numeric
 Sajec> arrays which can be any length, and create boxplots for
 Sajec> each of the arrays in the list.
Since I have never used boxplot I don't feel qualified to comment on
this, so I suggest you bring it up on the user's list. If noone
objects, and you send me a patch against CVS, I'll include it.
Thanks,
JDH

Hello,
 I'm using matplotlib figures in several places at a time in my GTK base=
d
app (means different page in a notebook).
I have trace a bug I partially solved but still doubting if it is a
matplotlib bug or a bad design of my app.
Matplotlib 0.86.2
pygtk-2.8.4
gtk+-2.8.6
Here is the problem:
in matplotlib/backends/backend_gtk.py file, in
class FigureCanvasGTK (gtk.DrawingArea, FigureCanvasBase):
... in:
 def draw(self):
 # synchronous window redraw (like GTK+ 1.2 used to do)
 # Note: this does not follow the usual way that GTK redraws,
 # which is asynchronous redraw using calls to
gtk_widget_queue_draw(),
 # which triggers an expose-event
 # GTK+ 2.x style draw()
 1- self._need_redraw =3D True
 1- self.queue_draw()
 # synchronous draw (needed for animation)
 2- x, y, w, h =3D self.allocation
 2- if w<3 or h<3: return # empty fig
 2- self._pixmap_prepare (w, h)
 2- self._render_figure(self._pixmap, w, h)
 2- self._need_redraw =3D False
 2- self.window.draw_drawable (self.style.fg_gc[self.state],
 2- self._pixmap, 0, 0, 0, 0, w, h)
If I use method 1- (and comment 2-) no problem, all run smoothly...
But using the default method, switching on method 2- (and comment 1-)
I get the followig error message when trying to redraw one of the figure
(the figure is plotted correctly the first time. No change made to the
figure, just redrawing...)
***/python2.4/site-packages/matplotlib/backends/backend_gtk.py:298:
GtkWarning: gdk_pixmap_new: assertion `(drawable !=3D NULL) || (depth !=3D =
-1)'
failed
 self._pixmap_height)
Traceback (most recent call last):
...
 self.canvas_leak.draw()
 File "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py",
line 250, in draw
 self._pixmap_prepare (w, h)
 File "***/python2.4/site-packages/matplotlib/backends/backend_gtk.py",
line 298, in _pixmap_prepare
 self._pixmap_height)
RuntimeError: could not create GdkPixmap object
Somebody has a clue ???

I would like to propose modifying the boxplot function as follows:
Instead of only accepting an (mxn) matrix (x) and creating (n) boxplots
from the columns of (x), optionally in place of the (mxn) matrix accept
a list of numeric arrays which can be any length, and create boxplots
for each of the arrays in the list.
The obvious benefit in doing this is that one can easily create boxplots
to compare datasets with differing numbers of data-points.
For example:
>>from RandomArray import normal
>>x1 =3D normal(10,3,100)
>>x2 =3D normal(10,5,150)
>>x3 =3D normal(10,1,1000)
>>
>>boxplot([x1, x2, x3])
The code below implements the proposed change by modifying the boxplot
function axes.py. It works and is proof of concept if nothing else.=20
##--------------------------------------------------##
## modifications to the boxplot function in axes.py ##
##--------------------------------------------------##
 def boxplot(self, x, notch=3D0, sym=3D'b+', vert=3D1, whis=3D1.5,
 positions=3DNone, widths=3DNone):
 """
 boxplot(x, notch=3D0, sym=3D'+', vert=3D1, whis=3D1.5,
 positions=3DNone, widths=3DNone)
 Make a box and whisker plot for each column of x.
 Or
 Make a box and whisker plot for each array in list x.
 =20
 The box extends from the lower to upper quartile values
 of the data, with a line at the median. The whiskers
 extend from the box to show the range of the data. Flier
 points are those past the end of the whiskers.
 notch =3D 0 (default) produces a rectangular box plot.
 notch =3D 1 will produce a notched box plot
 sym (default 'b+') is the default symbol for flier points.
 Enter an empty string ('') if you don't want to show fliers.
 vert =3D 1 (default) makes the boxes vertical.
 vert =3D 0 makes horizontal boxes. This seems goofy, but
 that's how Matlab did it.
 whis (default 1.5) defines the length of the whiskers as
 a function of the inner quartile range. They extend to the
 most extreme data point within ( whis*(75%-25%) ) data range.
 positions (default 1,2,...,n) sets the horizontal positions of
 the boxes. The ticks and limits are automatically set to match
 the positions.
 widths is either a scalar or a vector and sets the width of
 each box. The default is 0.5, or 0.15*(distance between extreme
 positions) if that is smaller.
 x is either:=20
	 	(1) a Numeric array=20
		(2) a list of 1-dimension Numeric arrays of any length
 Returns a list of the lines added
 """
 =20
 =20
 if not self._hold: self.cla()
 holdStatus =3D self._hold
 whiskers, caps, boxes, medians, fliers =3D [], [], [], [], []
 # CASE #1: x is a numeric array
 if type(x) =3D=3D type(array([0])):
 x =3D asarray(x)
 rank =3D len(x.shape)
 if 1 =3D=3D rank:
 x.shape =3D -1, 1
 row, col =3D x.shape
 # CASE #2: x is a list of numeric arrays
 if type(x) =3D=3D type(list([0])):
 col =3D len(x) # one column for each array
 #reshape the vectors in list x if necessary =20
 for ii in range(len(x)):
 rank =3D len(x[ii].shape)
 if 1 =3D=3D rank:
 x[ii].shape =3D -1, 1 =20
 # get some plot info
 if positions is None:
 positions =3D range(1, col + 1)
 if widths is None:
 distance =3D max(positions) - min(positions)
 widths =3D min(0.15*max(distance,1.0), 0.5)
 if isinstance(widths, float) or isinstance(widths, int):
 widths =3D ones((col,), 'd') * widths
 # loop through columns, adding each to plot
 self.hold(True)
 for i,pos in enumerate(positions):
 # CASE #1: x is a numeric array=20
 if type(x)=3D=3Dtype(array([0])):
 d =3D x[:,i]
 # CASE #2: x is a list of numeric arrays =20
 if type(x)=3D=3Dtype(list([0])):
 d =3D x[i][:,0]
 row =3D len(d)
 # get median and quartiles
 q1, med, q3 =3D prctile(d,[25,50,75])
 # get high extreme
 iq =3D q3 - q1
 hi_val =3D q3 + whis*iq
 wisk_hi =3D compress( d <=3D hi_val , d )
 if len(wisk_hi) =3D=3D 0:
 wisk_hi =3D q3
 else:
 wisk_hi =3D max(wisk_hi)
 # get low extreme
 lo_val =3D q1 - whis*iq
 wisk_lo =3D compress( d >=3D lo_val, d )
 if len(wisk_lo) =3D=3D 0:
 wisk_lo =3D q1
 else:
 wisk_lo =3D min(wisk_lo)
 # get fliers - if we are showing them
 flier_hi =3D []
 flier_lo =3D []
 flier_hi_x =3D []
 flier_lo_x =3D []
 if len(sym) !=3D 0:
 flier_hi =3D compress( d > wisk_hi, d )
 flier_lo =3D compress( d < wisk_lo, d )
 flier_hi_x =3D ones(flier_hi.shape[0]) * pos
 flier_lo_x =3D ones(flier_lo.shape[0]) * pos
 # get x locations for fliers, whisker, whisker cap and box
sides
 box_x_min =3D pos - widths[i] * 0.5
 box_x_max =3D pos + widths[i] * 0.5
 wisk_x =3D ones(2) * pos
 cap_x_min =3D pos - widths[i] * 0.25
 cap_x_max =3D pos + widths[i] * 0.25
 cap_x =3D [cap_x_min, cap_x_max]
 # get y location for median
 med_y =3D [med, med]
 # calculate 'regular' plot
 if notch =3D=3D 0:
 # make our box vectors
 box_x =3D [box_x_min, box_x_max, box_x_max, box_x_min,
box_x_min ]
 box_y =3D [q1, q1, q3, q3, q1 ]
 # make our median line vectors
 med_x =3D [box_x_min, box_x_max]
 # calculate 'notch' plot
 else:
 notch_max =3D med + 1.57*iq/sqrt(row)
 notch_min =3D med - 1.57*iq/sqrt(row)
 if notch_max > q3:
 notch_max =3D q3
 if notch_min < q1:
 notch_min =3D q1
 # make our notched box vectors
 box_x =3D [box_x_min, box_x_max, box_x_max, cap_x_max,
box_x_max, box_x_max, box_x_min, box_x_min, cap_x_min, box_x_min,
box_x_min ]
 box_y =3D [q1, q1, notch_min, med, notch_max, q3, q3,
notch_max, med, notch_min, q1]
 # make our median line vectors
 med_x =3D [cap_x_min, cap_x_max]
 med_y =3D [med, med]
 # vertical or horizontal plot?
 if vert:
 def doplot(*args):
 return self.plot(*args)
 else:
 def doplot(*args):
 shuffled =3D []
 for i in range(0, len(args), 3):
 shuffled.extend([args[i+1], args[i], args[i+2]])
 return self.plot(*shuffled)
 whiskers.extend(doplot(wisk_x, [q1, wisk_lo], 'b--',
 wisk_x, [q3, wisk_hi], 'b--'))
 caps.extend(doplot(cap_x, [wisk_hi, wisk_hi], 'k-',
 cap_x, [wisk_lo, wisk_lo], 'k-'))
 boxes.extend(doplot(box_x, box_y, 'b-'))
 medians.extend(doplot(med_x, med_y, 'r-'))
 fliers.extend(doplot(flier_hi_x, flier_hi, sym,
 flier_lo_x, flier_lo, sym))
 # fix our axes/ticks up a little
 if 1 =3D=3D vert:
 setticks, setlim =3D self.set_xticks, self.set_xlim
 else:
 setticks, setlim =3D self.set_yticks, self.set_ylim
 newlimits =3D min(positions)-0.5, max(positions)+0.5
 setlim(newlimits)
 setticks(positions)
 =20
 # reset hold status
 self.hold(holdStatus)
 return dict(whiskers=3Dwhiskers, caps=3Dcaps, boxes=3Dboxes,
 medians=3Dmedians, fliers=3Dfliers)