matplotlib-users Mailing List for matplotlib (Page 5)

Joachim B Haga <cj...@st...> 
writes:
>> You may have something there. I tested different backends:
>> 
>> These show the problem: While these work fine:
>> 
>> GtkAgg WX 
>> QtAgg WXAgg 
>> CairoAgg GTK 
>> GtkCairo (yes, really) TkAgg 
Forget this list. I just discovered that -d<nonexistentbackend> 
silently defaults to GtkAgg, at least on my install (debian). So the
"problem" list probably boils down to GtkAgg. Maybe you knew that.
Steve Chaplin <ste...@ya...> writes:
> I've just fixed it in CVS, it should appear in the next matplotlib
> version. Or try installing from CVS if you need the fix now, and would
> like to test it.
Excellent! I'll wait; or, if you want me to test, tell me which file and
version it is so I can patch my install with the relevant changes.
Cheers,
Joachim.

Hi
After finally trying out Matplotlib, I am really impressed, and will stick to
it. And hear comes the first "would be nice to have" feature request:
o instead of secret keys for toggling the grid or the log-scaling of the axis,
 it would be nice to have buttons for this.
o toggling logplot on one or both axes would be nice, too, maybe with 'l' and
 'L', or with buttons
 
Thanks, Martin
-- 
Martin Lüthi an...@tn...

John Hunter wrote:
>>>>>>"James" == James Boyle <bo...@ll...> writes:
> 
> 
> James> How would one get a colorbar() with a matshow plot? That
> James> is without altering the matshow code in pylab.,py.
> 
> A good question. The naive answer is: add the gci._current line to
> the matshow code below the imshow line
> 
> im = ax.imshow(*args,**kw)
> gci._current = im
> 
> 
> and then do
> 
> In [1]: matshow(rand(12,12))
> In [2]: colorbar()
> 
> The problem, of course, is that colorbar resizes the current axes,
> which defeats the purpose of matshow. 
> 
> What one needs is a colorbar kwarg to the matshow function that makes
> extra room for the colorbar and still preserves the aspect ratio.
> This would require some arithmetic and extra work. Any takers?
Well, I've been wanting this (I mentioned it to you in SF in passing) for a 
while. But I don't know the sizing code well enough to be able to write it up 
quickly. I'm just not terribly comfortable yet with the overall internal 
design of mpl. If nobody else does it I probably will, because I need it. 
But it will likely be _weeks_ before I even have a look.
best,
f

>>>>> "john" == john <joh...@jp...> writes:
 john> Hello, I am trying to set a bar (a patched series of
 john> rectangles) with a fill pattern instead of
 john> just a solid color. Is there an easy way to do this in
 john> matplotlib?
 john> I am thinking of something like Qt's QBrush which has cross,
 john> vertical, dense, etc. patterns.
There is no support for this currently -- it wouldn't bee too hard to
add for backends that support this kind of thing. Basically, we need
to specify the API for it, and add support to backends. I have been
wanting to add gradient fills for patches (eg polygons, rectangles)
and it would be good to do both at once.
I know Ted has mentioned a desire to plot ellipses avoiding the
discretizations caused by manually computing the vertices. When the
migration to proper path drawing in mpl is complete, this would be
possible with splines or by exposing a backend draw_ellipse method.
For simplicity of design, I'm inclined to the former, but if you have
any suggestions here, let me know.
 
 john> Also, could you please tell me how to plot a rotated
 john> ellipse?
 There is no built-in support for this, but you can do it "the hard
 way" (example below).
I'm in the process of rethinking and refactoring the way mpl does
transformations, so if you have suggestions on how this could be done
better from an interface standpoint, please let me know. The code
below requires mpl CVS (but will be included in the next release,
possibly today)
 from matplotlib.agg import trans_affine
 from matplotlib.patches import Polygon
 from matplotlib.numerix import sin, cos, pi, arange
 import pylab
 rx = 2
 ry = 1
 angle = arange(0.0, 2*pi, 0.1)
 xs = rx*cos(angle)
 ys = ry*sin(angle)
 a = 2*pi*10./360. # 10 degrees
 trans = trans_affine(cos(a), sin(a), -sin(a), cos(a), 0.0, 0.0)
 verts = [tuple(trans.transform(x,y)) for x,y in zip(xs,ys)]
 poly = Polygon(verts)
 ax = pylab.subplot(111)
 ax.add_patch(poly)
 ax.autoscale_view()
 pylab.show()
JDH

>>>>> "James" == James Boyle <bo...@ll...> writes:
 James> How would one get a colorbar() with a matshow plot? That
 James> is without altering the matshow code in pylab.,py.
A good question. The naive answer is: add the gci._current line to
the matshow code below the imshow line
 im = ax.imshow(*args,**kw)
 gci._current = im
and then do
In [1]: matshow(rand(12,12))
In [2]: colorbar()
The problem, of course, is that colorbar resizes the current axes,
which defeats the purpose of matshow. 
What one needs is a colorbar kwarg to the matshow function that makes
extra room for the colorbar and still preserves the aspect ratio.
This would require some arithmetic and extra work. Any takers?
Perry and I have been discussing some ideas to make this kind of
layout easier. The problem is that the figure size is picked first,
and the axes are fractions of that. In addition to the current
functionality, it would be nice to have a figure container that
resized itself, and axes that were in physical sizes. Eg, something
like
 fig = FigureDynamic()
 ax = AxesSized(5,5) # inches
 cax = AxesSized(.5,5) # inches
 fig.hbox.add(ax)
 fig.hbox.add(cax)
 X = rand(12,12)
 ax.imshow(X) # aspect ratio is correct since axwidth=axheight
 fig.colorbar(cax)
When you add the axes, the figure window would resize itself to
accommodate them, which is the inverse of what happens currently --
the axes physical dimensions resize themselves according to the figure
physical size. I think both approaches are useful.
JDH

How would one get a colorbar() with a matshow plot?
That is without altering the matshow code in pylab.,py.
--Jim

Hi all,
A user discovered that I had built only Numeric support, and not 
numarray support, into my OS-X matplotlib package. I've fixed that, and 
you can find the new version at:
http://www.pythonmac.org/packages/matplotlib-0.72.1-py2.3-macosx10.3.zip
It supports Numeric and/or numarray, and the Tk, Wx, and Agg back-ends. 
Note that TK and Wx are a bit weird, they both can crash python when you 
close the window. I'm only using the Agg back-end myself at the moment, 
so I'm not going to figure this out, but it would be great if someone did!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hello,
 
I am trying to set a bar (a patched series of rectangles) with a fill
pattern instead of 
just a solid color. Is there an easy way to do this in matplotlib?
I am thinking of something like Qt's QBrush which has cross, vertical,
dense, etc. patterns.
 
Also, could you please tell me how to plot a rotated ellipse?
 
Thanks, 
John Schwartz (JPL, Monte project)

>>>>> "andrea" == andrea gavana <and...@ti...> writes:
 andrea> Hello John and NG,
 >> I answered this question before at
 >> 
 >> http://sourceforge.net/mailarchive/message.php?msg_id=11115023
 >> 
 andrea> Probably I did not make myself clear.
 >> In a nutshell, do not manually bind 'g' to toggle the grid.
 >> This already happens by default in matplotlib 0.72.
 andrea> I am NOT manually binding the "g" key! I have NO
 andrea> key_press_event on my routines. Similarly, the examples:
 andrea> - embedding_in_wx.py - embedding_in_wx2.py -
 andrea> wxcursor_demo.py
OK, I see. Sorry for the confusion. The default keybindings are made
in the backend FigureManager classes. All of the examples you
referenced embed matplotlib in a wx app. The ones that use the
FigureManagerWX (eg embedding_in_wx.py) have the default key bindings;
the ones that don't use FigureManagerWX (eg embedding_in_wx2.py), do
not. If you don't use the manager, you have to do the bindings you
want yourself. Eg, in embedding_in_wx2.py
 self.axes.plot(t,s)
 self.canvas = FigureCanvas(self, -1, self.figure)
 def toggle_grid(event):
 self.axes.grid()
 self.canvas.draw()
 self.canvas.mpl_connect('key_press_event', toggle_grid)
Hope this helps,
JDH
 

Hello John and NG,
>I answered this question before at
>
> http://sourceforge.net/mailarchive/message.php?msg_id=3D11115023
>
Probably I did not make myself clear.
>In a nutshell, do not manually bind 'g' to toggle the grid. This
>already happens by default in matplotlib 0.72. 
I am NOT manually binding the "g" key! I have NO key_press_event on my ro=
utines.
Similarly, the examples:
- embedding_in_wx.py
- embedding_in_wx2.py
- wxcursor_demo.py
The is NOT any key_press_event. So there is no manually binding of char
events (in my understanding). Moreover, I can click many times in the WX
window (as you suggested), but the binding of the "g" char is never activ=
ated
on the following demos:
- embedding_in_wx2.py
- wxcursor_demo.py
For the embedding_in_wx.py demo, you are right, John. You have to click
on the WX window in order to get the "g" behavior, that works. 
I don't really know why you need to click on the window to activate the
char binding... probably Robin Dunn may have an answer to this problem.
Thanks to you all.
Andrea.
 

I have this script:
from pylab import *
from numarray import *
a = arange(10)
scatter(a,a,c=a,s=60,cmap=cm.winter)
colorbar()
show()
but instead to have the brighter point in green I want to have them in 
blue. To obtain it I did a stupid things and I invert the map:
from pylab import *
from numarray import *
a = arange(10)
scatter(a,a,c=-a,s=60,cmap=cm.winter)
colorbar()
show()
but the colormap scale is in good direction green to blue but negative. 
Do you know how can I correct this perhaps it's not possible and the 
anly way to do this is to create a new color map?
Thanks,
N.

Hi,
so the scripts to see my problem with the colorbar are:
script 1:
from pylab import *
from numarray import *
a = arange(10)
scatter(a,a,c=a,s=60,cmap=cm.winter)
colorbar(orientation='horizontal')
show()
script 2:
from pylab import *
from numarray import *
a = arange(10)
scatter(a,a,c=a,s=60,cmap=cm.winter)
colorbar()
show()
The first script must have (I think) a scale for the colorbar between 0 
and 10 like it is in the vertical mode but it's only a guess and I 
probably misunderstood something else.
Thanks,
 N.

Hi,
After resolving the font_manager.py issue, I could fire up pylab on
Japanese Win 2K. However, on my Win XP Japanese PCs, there seems
some trouble remaining.
The following result was obtained with Enthogut python 2.3.3 on XP
professional Version 2002 SP1, Japanese.
On other PC with XP SP2, Japanese, I got a similar error.
So I'm afraid it is repeatable to any Japanese Win XP.
Maybe, my WinXPs are not fresh and clean. What do you think?
I'm ready to test the special debugging build which was mentioned in the
list earlier, if the binaries are sent to me.
--
Natsu
>python
Enthought Edition build 1056
Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^Z
>python simple_plot.py --verbose-helpful
matplotlib data path C:\Python23\share\matplotlib
loaded rc file C:\Python23\share\matplotlib\.matplotlibrc
matplotlib version 0.72.1
verbose.level helpful
interactive is False
platform is win32
numerix Numeric 23.3
font search path ['C:\\Python23\\share\\matplotlib']
Then a message box appears telling that python.exe is quitting.
The box has a link and a "debug" button.
The "debug" button tells that
The instruciton "0x1e07460e" refers to memory at "0x00000000".
It could not be "read". (in Japanese)
The link gudes to an other message box which tells that the error
signature is as follows:
AppName: python.exe	 AppVer: 0.0.0.0	 ModName: python23.dll
ModVer: 2.3.3150.1012	 Offset: 0007460e
>python -v
--- snip ---
>>> import pylab
--- snip ---
import matplotlib.lines # precompiled from
C:\Python23\lib\site-packages\matplotlib\lines.pyc
# C:\Python23\lib\site-packages\matplotlib\patches.pyc matches
C:\Python23\lib\site-packages\matplotlib\patches.py
import matplotlib.patches # precompiled from
C:\Python23\lib\site-packages\matplotlib\patches.pyc
# C:\Python23\lib\site-packages\matplotlib\path.pyc matches
C:\Python23\lib\site-packages\matplotlib\path.py
import matplotlib.path # precompiled from
C:\Python23\lib\site-packages\matplotlib\path.pyc
# C:\Python23\lib\site-packages\matplotlib\ticker.pyc matches
C:\Python23\lib\site-packages\matplotlib\ticker.py
import matplotlib.ticker # precompiled from
C:\Python23\lib\site-packages\matplotlib\ticker.pyc
# C:\Python23\lib\site-packages\matplotlib\font_manager.pyc matches
C:\Python23\lib\site-packages\matplotlib\font_manager.py
import matplotlib.font_manager # precompiled from
C:\Python23\lib\site-packages\matplotlib\font_manager.pyc
# C:\Python23\lib\glob.pyc matches C:\Python23\lib\glob.py
import glob # precompiled from C:\Python23\lib\glob.pyc
# C:\Python23\lib\fnmatch.pyc matches C:\Python23\lib\fnmatch.py
import fnmatch # precompiled from C:\Python23\lib\fnmatch.pyc
# C:\Python23\lib\site-packages\matplotlib\afm.pyc matches
C:\Python23\lib\site-packages\matplotlib\afm.py
import matplotlib.afm # precompiled from
C:\Python23\lib\site-packages\matplotlib\afm.pyc
import matplotlib.ft2font # dynamically loaded from
C:\Python23\lib\site-packages\matplotlib\ft2font.pyd
# C:\Python23\lib\posixpath.pyc matches C:\Python23\lib\posixpath.py
import posixpath # precompiled from C:\Python23\lib\posixpath.pyc
import _winreg # dynamically loaded from C:\Python23\DLLs\_winreg.pyd
import cPickle # builtin
Then the message box appears.

>>>>> "Natsu" == Natsu <nat...@ya...> writes:
 >> try: key, direc, any = _winreg.EnumValue( local, j) if not
 >> os.path.dirname(direc): direc = os.path.join(directory, direc)
 >> direc = os.path.abspath(direc).lower() if direc[-4:] ==
 >> '.'+fontext: items[direc] = 1 except EnvironmentError: pass
Thanks for the patch -- this will be in the next release.
 Natsu> The idea is taken from a Japanese blog.
 Natsu> http://somethingred.dip.jp/blog/239
 Natsu> The author of the Blog seems to have some idea to patch
 Natsu> _winreg, also.
 Natsu> http://somethingred.dip.jp/blog/253 -- Natsu Mizutani
Perhaps you can contact the winreg maintainers and let them know about
this...
Thanks!
JDH

>>>>> "andrea" == andrea gavana <and...@ti...> writes:
 andrea> - embedding_in_wx.py
 andrea> The "g" key works fine, the grid is shown/hidden when you
 andrea> hit this key. I'm having the same problem in my
 andrea> application, I can not show the grid for some reason, and
 andrea> it seems to me that these 2 problems are related.
 andrea> Do you have any suggestion/pointer?
I answered this question before at
 http://sourceforge.net/mailarchive/message.php?msg_id=11115023
In a nutshell, do not manually bind 'g' to toggle the grid. This
already happens by default in matplotlib 0.72. 
In WX* you have to click on the figure before any of the keypress
functionality is activated (does anyone know how to fix this?)
JDH

>>>>> "Eliot" == Eliot R Smith <es...@in...> writes:
 Eliot> The following test program dies with an error when used
 Eliot> with the arguments shown -- but cutting back the argument
 Eliot> lists by even one element allows it to work OK. So does
 Eliot> taking out the hold(False). This is with Mac OS X, Apple
 Eliot> Python 2.3, Matplotlib version 0.71, __revision__
See the release notes for matplotlib-0.72, specifically
 log plot enhancements
 Lots of work making log plots just work. You can toggle log y axes
 with the l ("ell") keypress -- nonpositive data are simply ignored
 and no longer raise. log plots should be a lot faster and more
 robust
Hope this helps!
JDH

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> I ran the script with GTKCairo and it looks fine to me.
 Steve> Perhaps you are using GTKAgg which looks like it has the
 Steve> problem. My guess is that its caused by using
 Steve> gtk.idle_add() which results in asynchronous expose_event
 Steve> updates.
I looked at this briefly and am a little confused by something. The
base class FigureCanvasGTK.expose_event has this in the doc string
 """Expose_event for all GTK backends
 Should not be overridden.
but then the derived class 
 class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg):
does in fact override it.
I inserted a debug print statement into
FigureCanvasGTKAgg.expose_event and it is not called until the loop is
over. I think this is because the call to sleep is preventing the
idle handler from ever getting engaged.
Perhaps Joachim would be better off using a gtk timer to handle his
animation. Basically, matplotlib tries to provide a GUI neutral way
to do animation (eg anim.py) but if you want to do something
semi-sophisticated like alter the timing between draws, you should use
the GUI specific functionality for this, eg gtk timers.
Here is an example
# animate increasing terms in fourier expansion of y=x
import pygtk
pygtk.require('2.0')
import gtk
import matplotlib
matplotlib.use('GTKAgg')
from matplotlib.numerix import arange, pi, sin, zeros, Float
import pylab
class Animator:
 
 def __init__(self, samples=1000, max_k=30):
 self.samples = samples
 self.max_k = max_k
 self.fig = pylab.figure()
 self.ax = self.fig.add_subplot(111)
 x = arange(0.0, 1.0, 1.0/self.samples)
 self.s = zeros((self.max_k,samples), Float)
 for k in range(1,self.max_k):
 self.s[k] = self.s[k-1]+(-1)**(k+1)*sin(pi*x*k)/k
 self.line, = self.ax.plot(x, x*1.3, linewidth=1.0)
 self.ax.grid(True)
 self.k = 1
 def draw(self, *args):
 
 self.line.set_ydata(2./pi*self.s[self.k])
 self.ax.set_title('k = '+str(self.k))
 pylab.draw()
 self.k += 1
 return self.k<self.max_k
anim = Animator()
gtk.timeout_add(100,anim.draw)
pylab.show()

>>>>> "Shidai" == Shidai Liu <shi...@gm...> writes:
 >> Greetings all, trivial problem, don't know if it's my machine
 >> problem.
 >> 
 >> <<< plot([1,2,3],'gx')
 >> 
 >> fails to plot the canvas.
 >> 
 >> Py2.3 + Pylab .70
This will be fixed in the next release -- thanks.
JDH

The following test program dies when line style 'bx-' is requested
in the 4th plotset. It works ok with 'b+-' (so fixing this is not 
urgent...)
It worked fine with 0.71.
This is with Mac OS X, Apple Python 2.3, Matplotlib version 0.72.1
--Eliot Smith, Indiana University
#---------------begin test program
from pylab import *
a=[0,20,40,60,80]
b1=[1,2,3,4,5]
b2=[6,5,4,3,2]
b3=[1,3,5,7,9]
b4=[8,6,4,2,1]
b5=[7,6,5,6,7]
plot(a,b1,'bo-', a,b2,'rs:', a,b3,'g^--',a,b4,'bx-',\
 a,b5,'yv-')
# fails with 'bx-' in 4th plotset. Works ok with 'b+-'
# message is
#Traceback (most recent call last):
# File "../testmplbug2.py", line 15, in ?
# savefig('test2.png')
# File "/Library/Python/2.3/pylab.py", line 763, in savefig
#
# File "/platlib/matplotlib/figure.py", line 455, in savefig
# File "/platlib/matplotlib/backends/backend_tkagg.py", line 161, in 
print_figure
# File "/Library/Python/2.3/matplotlib/backends/backend_agg.py", line 
371, in print_figure
# self.draw()
# File "/Library/Python/2.3/matplotlib/backends/backend_agg.py", line 
320, in draw
# self.figure.draw(self.renderer)
# File "/platlib/matplotlib/figure.py", line 338, in draw
# File "/platlib/matplotlib/axes.py", line 1296, in draw
# File "/platlib/matplotlib/lines.py", line 294, in draw
# File "/platlib/matplotlib/lines.py", line 1044, in _draw_x
# File "/Library/Python/2.3/matplotlib/backends/backend_agg.py", line 
156, in draw_line
# self._renderer.draw_lines(gc, x, y)
#IndexError: Unexpected SeqBase<T> length.
savefig('test2.png')
#--------------------------end test program

Hello Jean-Michel,
>Anyway it seems that my polyfit troubles come from computation precision=
>issues. Indeed my polynomial may be of too high order than data actually=
>
>need so that some coefficients are very low (eg. 1e-20). I made some 
>experiments that show the results depend on the use of Numeric/numarray:=
>
>* Numeric
>I must use polyfit(x,y,N) with Float64 for x because it crashes with 
>Float32, but results are very inaccurate
>
>* numarray
>I can use either Float64 or Float32, but only Float32 give good results
>(may someone have an explanation...)
>
>Compared to Matlab, polynomial fitting with Python is not as good in 
>this case. For people who are interested in testing my data I provided
>an attached text file of x and y, the polynomial order is 6.
That does not depend on Numeric, numarray or Matlab. Is your data. If you=
try, in Matlab, to see how polyfit works (type polyfit), you will see wit=
h
a simple trial that your data are bad conditioned. As an example, if x,
y are the 2 rows of your data:
x =3D x(:);
y =3D y(:);
% Construct the Vardermonde Matrix
V(:,n+1) =3D ones(length(x),1);
for j =3D n:-1:1
 V(:,j) =3D x.*V(:,j+1);
end
[Q,R] =3D qr(V,0);
p =3D R\(Q'*y);
Warning: Matrix is close to singular or badly scaled.
 Results may be inaccurate. RCOND =3D 2.575966e-026.
In fact, try to take a look at the condition number of your matrix R:
condest(R)
ans =3D
 3.89823249817041e+025
That's too high. Neither Matlab, Python or whatever software will give yo=
u
a result on which you can rely. Maybe at a first glance Matlab seems to
be more powerful (and, in general, this is the case), but be aware that
you should not trust on results that are affected by so bad conditioning
number/numerical errors.
Try to reduce the number of points (some of them are too close), or try
a non-linear regression (as lsqnonlin), even if you should not need such
a tool in order to do the job.
HTH.
Andrea.

jea...@ar... wrote:
> I'm having some troubles while fitting data with high order polynomials
> (typically order 6). I looked at the polyfit function in
> 'matplotlib/mlab.py' and I must say I don't understand why the
> least-square problem isn't solved using the matrix multiplication
> instead of the * multiplication. Unless I misunderstood something,
> shouldn't the following line:
Obviously I misunderstood something since quick trials gave me:
 >>> array([[0,1],[1,0]]) * array([[2],[3]])
array([[0, 2],
 [3, 0]])
 >>> matrixmultiply(array([[0,1],[1,0]]), array([[2],[3]]))
array([[3],
 [2]])
as the polyfit function works well...
Anyway it seems that my polyfit troubles come from computation precision 
issues. Indeed my polynomial may be of too high order than data actually 
need so that some coefficients are very low (eg. 1e-20). I made some 
experiments that show the results depend on the use of Numeric/numarray:
* Numeric
I must use polyfit(x,y,N) with Float64 for x because it crashes with 
Float32, but results are very inaccurate
* numarray
I can use either Float64 or Float32, but only Float32 give good results 
(may someone have an explanation...)
Compared to Matlab, polynomial fitting with Python is not as good in 
this case. For people who are interested in testing my data I provided 
an attached text file of x and y, the polynomial order is 6.
JM. Philippe

Hi,
here I propose a minimum patch to fontmanager.py from 0.72.1
which I've confirmed to work on Japanese Win2k.
$ diff font_manager.org.py font_manager.py
113,118c113,121
< key, direc, any = _winreg.EnumValue( local, j)
< if not os.path.dirname(direc):
< direc = os.path.join(directory, direc)
< direc = os.path.abspath(direc).lower()
< if direc[-4:] == '.'+fontext:
< items[direc] = 1
---
> try:
> key, direc, any = _winreg.EnumValue( local, j)
> if not os.path.dirname(direc):
> direc = os.path.join(directory, direc)
> direc = os.path.abspath(direc).lower()
> if direc[-4:] == '.'+fontext:
> items[direc] = 1
> except EnvironmentError:
> pass
The idea is taken from a Japanese blog.
 http://somethingred.dip.jp/blog/239
The author of the Blog seems to have some idea to patch _winreg, also.
 http://somethingred.dip.jp/blog/253
--
Natsu Mizutani

> > I am unable to get matplotlib animations to work properly. Some of the data from
> > the previous frame is getting included.
I've just fixed it in CVS, it should appear in the next matplotlib
version. Or try installing from CVS if you need the fix now, and would
like to test it.
Steve

Hi,
I'm having some troubles while fitting data with high order polynomials 
(typically order 6). I looked at the polyfit function in 
'matplotlib/mlab.py' and I must say I don't understand why the 
least-square problem isn't solved using the matrix multiplication 
instead of the * multiplication. Unless I misunderstood something, 
shouldn't the following line:
c = array(linear_algebra.inverse(Xt*X)*Xt*y) # convert back to array
be rewritten like this?
c = array(matrixmultiply(matrixmultiply( 
linear_algebra.inverse(matrixmultiply(Xt,X)), Xt), y) ) # convert back 
to array
Thanks.
JM. Philippe

Steve Chaplin <ste...@ya...>
writes:
> > > I am unable to get matplotlib animations to work properly. Some
> > > of the data from the previous frame is getting included.
> > > 
> > > This is with version 0.72. Any ideas about what is happening?
>
> I ran the script with GTKCairo and it looks fine to me.
> 
> Perhaps you are using GTKAgg which looks like it has the problem. My
> guess is that its caused by using gtk.idle_add() which results in
> asynchronous expose_event updates.
You may have something there. I tested different backends:
 
These show the problem: While these work fine:
 GtkAgg WX 
 QtAgg WXAgg 
 CairoAgg GTK 
 GtkCairo (yes, really) TkAgg 
So for now I'll just switch to WXAgg. It's not as fast but it does the
job. Thanks!
(I'll assist, of course, in further testing if anyone wants to look 
into it)
-j.