matplotlib-users Mailing List for matplotlib

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.

On Mon, 2005年03月14日 at 22:38 -0800, matplotlib-users-
re...@li... wrote:
> > I am unable to get matplotlib animations to work properly. Some of the data from
> > the previous frame is getting included.
> > 
> > I have included some example code that shows this. When draw() is called in the
> > loop, it draws the data from the previous frame for y<0.15 (ca), and from the
> > current frame for larger y. The final show() does *not* lag even if set_ydata
> > has not been called since the last draw().
> > 
> > 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.
Steve

cvs access is broken
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/numpy co -P 
Numerical
cvs [checkout aborted]: unrecognized auth response from 
cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect 
(Connection refused)