From michaeljgruber+scipy at fastmail.fm Fri Jul 8 08:24:08 2005 From: michaeljgruber+scipy at fastmail.fm (Michael J Gruber) Date: Fri, 08 Jul 2005 14:24:08 +0200 Subject: [SciPy-dev] gplt suggestion: initcmd Message-ID: <42CE7068.3060404@fastmail.fm> SciPy version: 0.3.2 When using the gplt module for batch processing plots there are two problems: - gplt sets the default terminal to X11, so that you have to have X running (or Xfb). - gplt sends "reset" for every plot", and implements set commands (range etc) as "replots". In particular, ranges get reset when setting up output to a file! As an example, I want to generate 500 plots depending on a parameter, but with the same range so that the plots fit together as an animation. The attached diffs change "plot" and "_init_plot" so that plot has an optional keyword parameter "initcmd". If it is not specified or None, plot behaves as before (sending a "reset" to gnuplot for every plot). If specified, it is sent (instead of reset) verbatim to gnuplot. This allows to do something like the following: # xvals is an arry of x coordinates initcmd='set yrange [-5:40]; set xrange [0:1]; set terminal jpeg size 1000,750; for j in range(500): plotdata = myplotproc(j) gplt.plot(xvals,plotdata,"initcmd=initcmd+'set output "'+prefix+('%0.3d.jpeg"' % j)) (The mailer may introduce linebreaks in the code above.) That way, there are no replots involved, no X needs to be running. One could arrange for range and term to be set only once, but this no performance issue. I'll appreciate any feedback. Cheers, Michael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: interface.py.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pyPlot.py.diff URL: From Fernando.Perez at colorado.edu Fri Jul 8 12:07:51 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 08 Jul 2005 10:07:51 -0600 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: <42CE7068.3060404@fastmail.fm> References: <42CE7068.3060404@fastmail.fm> Message-ID: <42CEA4D7.5060004@colorado.edu> Michael J Gruber wrote: > SciPy version: 0.3.2 > > When using the gplt module for batch processing plots there are two > problems: I can apply this patch (it takes no time at all), but I'd like to rather ask the 'big' question about plotting on the list. It's a reality that nobody really maintains plotting in scipy anymore, especially now that matplotlib and pyx are on the scene, along with mayavi for 3d support. But that is not mentioned anywhere, so it's natural for new users to gravitate towards scipy's plotting support. Should we officially deprecate scipy.*plt? I don't mean to pull it off the codebase, since many people may rely on it, but simply don't mention it anywhere in the docs or docstrings. This way, those who already have code that uses it can continue to run, but new unsuspecting users won't be lured into the trap :) Any opinions? Cheers, f From aisaac at american.edu Fri Jul 8 12:35:13 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 8 Jul 2005 12:35:13 -0400 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: <42CEA4D7.5060004@colorado.edu> References: <42CE7068.3060404@fastmail.fm><42CEA4D7.5060004@colorado.edu> Message-ID: On Fri, 08 Jul 2005, Fernando Perez apparently wrote: > Any opinions? A user's perspective: the current arrangement is confusing to new SciPy users. When I started using SciPy, I naturally wanted to use what appeared to be the SciPy graphic packages. As I quickly ran into their limitations, I was very frustrated until I learned that Matplotlib was the package of choice for SciPy users. I now know this has been discussed many times, but I strongly feel that new users will be better served if they are strongly directed to Matplotlib and, better yet, if Matplotlib is packaged with SciPy. Cheers, Alan Isaac From michaeljgruber+scipy at fastmail.fm Fri Jul 15 05:11:46 2005 From: michaeljgruber+scipy at fastmail.fm (Michael J Gruber) Date: Fri, 15 Jul 2005 11:11:46 +0200 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: References: <42CE7068.3060404@fastmail.fm><42CEA4D7.5060004@colorado.edu> Message-ID: <42D77DD2.6080607@fastmail.fm> Alan G Isaac venit, vidit, dixit 07/08/05 18:35: > On Fri, 08 Jul 2005, Fernando Perez apparently wrote: > >>Any opinions? > > > A user's perspective: > the current arrangement is confusing to new SciPy users. > > When I started using SciPy, I naturally wanted to use > what appeared to be the SciPy graphic packages. As I > quickly ran into their limitations, I was very frustrated > until I learned that Matplotlib was the package of choice > for SciPy users. > > I now know this has been discussed many times, but > I strongly feel that new users will be better served if they > are strongly directed to Matplotlib and, better yet, if > Matplotlib is packaged with SciPy. The same happened to me during my current project. Even though I suggested a patch to gplt and applied it locally to make things work, I have switched to mathplotlib meanwhile because of antialiasing, which is worth the roughly factor 1.7 speed decrease. I regularly use PyX for PS/PDF output. Unfortunately, for creating movies the combo PyX/ghostscript is a severe performance bottle neck. My suggestion: matplotlib, mayavi, PyX should be mentioned in the SciPy doc at least on the same footing as gplt/xplt/plt, if not with precedence. This should be reflected in the examples. Michael From rkern at ucsd.edu Fri Jul 15 06:04:37 2005 From: rkern at ucsd.edu (Robert Kern) Date: Fri, 15 Jul 2005 03:04:37 -0700 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: <42D77DD2.6080607@fastmail.fm> References: <42CE7068.3060404@fastmail.fm><42CEA4D7.5060004@colorado.edu> <42D77DD2.6080607@fastmail.fm> Message-ID: <42D78A35.70008@ucsd.edu> Michael J Gruber wrote: > My suggestion: matplotlib, mayavi, PyX should be mentioned in the SciPy > doc at least on the same footing as gplt/xplt/plt, if not with > precedence. This should be reflected in the examples. Indeed. I don't think anyone is arguing against this. It just boils down to people volunteering their time to implement it. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From Fernando.Perez at colorado.edu Fri Jul 15 12:16:45 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 15 Jul 2005 10:16:45 -0600 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: <42D78A35.70008@ucsd.edu> References: <42CE7068.3060404@fastmail.fm><42CEA4D7.5060004@colorado.edu> <42D77DD2.6080607@fastmail.fm> <42D78A35.70008@ucsd.edu> Message-ID: <42D7E16D.6000009@colorado.edu> Robert Kern wrote: > Michael J Gruber wrote: > > >>My suggestion: matplotlib, mayavi, PyX should be mentioned in the SciPy >>doc at least on the same footing as gplt/xplt/plt, if not with >>precedence. This should be reflected in the examples. > > > Indeed. I don't think anyone is arguing against this. It just boils down > to people volunteering their time to implement it. OK, I have a concrete suggestion which can be implemented in very little time. It's a bit brutal, but I really can't spend the time it would take to build a proper deprecation framework: 1. We edit the setup.py for scipy, and at the end we change: if __name__ == "__main__": ignore_packages = [ # list of package names that will not be built. ] setup_package(ignore_packages) into: if __name__ == "__main__": ignore_packages = [ # list of package names that will not be built. # Those listed by default are deprecated packages slated for # future deletion from scipy. If you still need them, comment them # out, but be aware that they will be deleted from the sources # in the future. 'xplt', 'gplt', 'plt', 'gui_thread', ] setup_package(ignore_packages) This kills installation of *plt and gui_thread, the 4 packages which consistently cause grief to users and burn bandwidth. Note that we do NOT remove them from the tree. Anyone who needs them can have them installed by simply commenting out the lines they wish. 2. Remove the references to these 4 packages from the main scipy docstring. that's a 4-line change. These two changes are easy to implement (about 10 minutes worth of work). The problem becomes how to point users to the equivalent functionality. For that I propose: 3. Change the scipy and plotting tutorials to use matplotlib. This needs a bit more work, but it's not super hard. The problem is that matplotlib does NOT have 3d plotting, so MayaVi would have to be mentioned (or gnuplot). MayaVi itself is easy to install, but VTK (its core dependency) is not. I currently have way too many things on my plate, so I couldn't help with 3 immediately (though perhaps in a month or so). 1 and 2 could be done literally in 10 minutes. But the problem is that these changes are somewhat harsh, and I'm not about to go ahead with them without some minimal consensus from other devs, ESPECIALLY those who invested their time and effort into the *plt modules. I certainly am not trying to trample over their work. Cheers, f From aisaac at american.edu Fri Jul 15 20:27:49 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 15 Jul 2005 20:27:49 -0400 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: <42D7E16D.6000009@colorado.edu> References: <42CE7068.3060404@fastmail.fm><42CEA4D7.5060004@colorado.edu><42D77DD2.6080607@fastmail.fm> <42D78A35.70008@ucsd.edu> <42D7E16D.6000009@colorado.edu> Message-ID: On Fri, 15 Jul 2005, Fernando Perez apparently wrote: > 3. Change the scipy and plotting tutorials to use matplotlib. Here's the figure 1 tutorial. (Looks nice!) Cheers, Alan Isaac x = arange(0,6e-2,6e-2/30) A,k,theta = 10, 1.0/3e-2, pi/6 y_true = A*sin(2*pi*k*x+theta) y_meas = y_true + 2*randn(len(x)) def residuals(p, y, x): A,k,theta = p err = y-A*sin(2*pi*k*x+theta) return err def peval(x, p): return p[0]*sin(2*pi*p[1]*x+p[2]) p0 = [8, 1/2.3e-2, pi/3] print array(p0) #[ 8. 43.4783 1.0472] from scipy.optimize import leastsq plsq = leastsq(residuals, p0, args=(y_meas, x)) print plsq[0] # random outcome print array([A, k, theta]) #[ 10. 33.3333 0.5236] from pylab import * # Requires Matplotlib plot(x,peval(x,plsq[0]),x,y_meas,'o',x,y_true) title('Least-squares fit to noisy data') legend(['Fit', 'Noisy', 'True']) savefig(r'c:\leastsqfit.eps') # Make eps file. From aisaac at american.edu Fri Jul 15 20:50:42 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 15 Jul 2005 20:50:42 -0400 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: <42D7E16D.6000009@colorado.edu> References: <42CE7068.3060404@fastmail.fm><42CEA4D7.5060004@colorado.edu><42D77DD2.6080607@fastmail.fm> <42D78A35.70008@ucsd.edu><42D7E16D.6000009@colorado.edu> Message-ID: On Fri, 15 Jul 2005, Fernando Perez apparently wrote: > 3. Change the scipy and plotting tutorials to use matplotlib. Here is the figure 2 tutorial. Note that the tutorial incorrectly refers to linear_1d, which no longer exists. (Line 331 of ltisys.py also calls this defunct function and needs to be fixed.) Cheers, Alan Isaac x = arange(0,10) y = exp(-x/3.0) from scipy.interpolate import interp1d f = interp1d(x,y) xnew = arange(0,9,0.1) import pylab pylab.plot(x,y,'x',xnew,f(xnew),'.') pylab.legend(['Actual', 'Interpolated']) pylab.show() From aisaac at american.edu Fri Jul 15 22:11:43 2005 From: aisaac at american.edu (Alan G Isaac) Date: Fri, 15 Jul 2005 22:11:43 -0400 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: <42D7E16D.6000009@colorado.edu> References: <42CE7068.3060404@fastmail.fm><42CEA4D7.5060004@colorado.edu><42D77DD2.6080607@fastmail.fm> <42D78A35.70008@ucsd.edu><42D7E16D.6000009@colorado.edu> Message-ID: Here is the figure 3 tutorial. The existing version called asarray_1d, which is apparently defunct. I did not see why, so I just deleted that line. Cheers, Alan Isaac PS I'm done for now. # Cubic-spline x = arange(0,2*pi+pi/4,2*pi/8) y = sin(x) tck = interpolate.splrep(x,y,s=0) xnew = arange(0,2*pi,pi/50) ynew = interpolate.splev(xnew,tck,der=0) pylab.figure(1) pylab.plot(x,y,'b-x',xnew,ynew,'m',xnew,sin(xnew),'r') pylab.legend(['Linear','Cubic Spline', 'True']) pylab.xlim(-0.05,6.33) pylab.ylim(-1.05,1.05) pylab.title('Cubic-spline interpolation') pylab.savefig('interp_cubic.eps') # Derivative of spline yder = interpolate.splev(xnew,tck,der=1) pylab.figure(2) pylab.plot(xnew,yder,'b-',xnew,cos(xnew),'r--') pylab.legend(['Cubic Spline', 'True']) pylab.xlim(-0.05,6.33) pylab.ylim(-1.05,1.05) pylab.title('Derivative estimation from spline') pylab.savefig('interp_cubic_der.eps') # Integral of spline def integ(x,tck,constant=-1): out = zeros(x.shape, x.typecode()) for n in xrange(len(out)): out[n] = interpolate.splint(0,x[n],tck) out += constant return out yint = integ(xnew,tck) pylab.figure(3) pylab.plot(xnew,yint,'b-',xnew,-cos(xnew),'r--') pylab.legend(['Cubic Spline', 'True']) pylab.xlim(-0.05,6.33) pylab.ylim(-1.05,1.05) pylab.title('Integral estimation from spline') pylab.savefig('interp_cubic_int.eps') # Roots of spline print interpolate.sproot(tck) # [ 0. 3.1416] # Parametric spline t = arange(0,1.1,.1) x = sin(2*pi*t) y = cos(2*pi*t) tck,u = interpolate.splprep([x,y],s=0) unew = arange(0,1.01,0.01) out = interpolate.splev(unew,tck) pylab.figure(4) pylab.plot(x,y,'b-x',out[0],out[1],'m',sin(2*pi*unew),cos(2*pi*unew),'r') pylab.legend(['Linear','Cubic Spline', 'True']) pylab.xlim(-1.05,1.05) pylab.ylim(-1.05,1.05) pylab.title('Spline of parametrically-defined curve') pylab.savefig('interp_cubic_param.eps') pylab.show() From prabhu_r at users.sf.net Sat Jul 16 12:20:29 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Sat, 16 Jul 2005 21:50:29 +0530 Subject: [SciPy-dev] gplt suggestion: initcmd In-Reply-To: <42D7E16D.6000009@colorado.edu> References: <42CE7068.3060404@fastmail.fm> <42CEA4D7.5060004@colorado.edu> <42D77DD2.6080607@fastmail.fm> <42D78A35.70008@ucsd.edu> <42D7E16D.6000009@colorado.edu> Message-ID: <17113.13261.244165.24118@monster.linux.in> >>>>> "Fernando" == Fernando Perez writes: Fernando> OK, I have a concrete suggestion which can be Fernando> implemented in very little time. Fernando> It's a bit brutal, but I really can't spend the time Fernando> it would take to build Fernando> a proper deprecation framework: +1 I don't have the time for gui_thread (or plt) anymore since I use ipython -wthread and it works fine. I doubt anyone would be interested in touching those beasts. I don't know anything about {g,x}plt to comment about those. I believe some folks do use xplt and quite like it. Likewise with gplt. So maybe gui_thread, plt can be commented out and the rest left alone and the tutorial etc. point to matplotlib. With all due respect to John, graceplot-using-old-fogies like me aren't affected anyways... :-) cheers, prabhu From Fernando.Perez at colorado.edu Sun Jul 17 23:32:49 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Sun, 17 Jul 2005 21:32:49 -0600 Subject: [SciPy-dev] fftw3 support In-Reply-To: <42B30F4B.4030504@mit.edu> References: <42B30F4B.4030504@mit.edu> Message-ID: <42DB22E1.8040500@colorado.edu> Matt Fishburn wrote: > Hello, > > I've attached patches against the current cvs source for fftw3 support > in scipy. I've only tested these under x86 *nix (debian with various > combinations of fftw-dev and fftw3-dev installed). Could a few people > please try the patches and send build feedback? Did anyone have a look at these patches? The code seems fine to me, and initial testing on my box looks OK, but I'd love to hear from someone else before committing this. One problem with scipy has always been the lack of contributors: we really need to heed when users are willing to send in patches, or else they'll never come back... I can commit this stuff, but I'd like to have at least another pair of eyeballs go over it at least once. Or just tell me to go ahead, I guess :) I just don't want to discourage Matt from contributing in the future. Cheers, f From ravi at ati.com Wed Jul 20 09:45:50 2005 From: ravi at ati.com (Ravikiran Rajagopal) Date: Wed, 20 Jul 2005 09:45:50 -0400 Subject: [SciPy-dev] [PATCH] Compilation with gcc4/gfortran Message-ID: <200507200945.50075.ravi@ati.com> Hi, Please find attached a patch (against scipy CVS) to compile with gcc 4.0. The changes are very simple and should not hurt any other set up: 1. Add "gfortran" as an option for Fortran compilation. 2. Add libgfortran as a replacement for libg2c (needs some tweaking). 3. Modify Lib/linalg/iterative/*.f.src to avoid jumping into a block. 4. Remove sse2 optimizations (see mailing lists for more information). I have tested this on Linux x86 with gcc CVS stable branch (4_0_branch) which is scheduled to be released as gcc 4.0.2. gcc 4.0.1 does not work since support for Hollerith constants (this obsolete construct is heavily used in scipy) was added only last week. Could someone with sufficient karma commit this? Would there be any object to contributing C++ code into scipy? As far as I can see, scipy does not use any C++ constructs. Is this intentional? Regards, Ravi -------------- next part -------------- A non-text attachment was scrubbed... Name: s.diff Type: text/x-diff Size: 6018 bytes Desc: not available URL: From ravi at ati.com Wed Jul 20 14:59:06 2005 From: ravi at ati.com (Ravikiran Rajagopal) Date: Wed, 20 Jul 2005 14:59:06 -0400 Subject: [SciPy-dev] fftw3 support In-Reply-To: <42DB22E1.8040500@colorado.edu> References: <42B30F4B.4030504@mit.edu> <42DB22E1.8040500@colorado.edu> Message-ID: <200507201459.06187.ravi@ati.com> Hi, I have tested the patches against scipy cvs from 5 days ago and they seem to be absolutely fine. My tests were all on Fedora Core 4 with gcc 4.0. Matt, thanks for the patches - I can finally get rid of fftw 2 which was long ago replaced in all my other production code. Regards, Ravi On Sunday 17 July 2005 23:32, Fernando Perez wrote: > Matt Fishburn wrote: > > Hello, > > > > I've attached patches against the current cvs source for fftw3 support > > in scipy. I've only tested these under x86 *nix (debian with various > > combinations of fftw-dev and fftw3-dev installed). Could a few people > > please try the patches and send build feedback? > > Did anyone have a look at these patches? The code seems fine to me, and > initial testing on my box looks OK, but I'd love to hear from someone else > before committing this. > > One problem with scipy has always been the lack of contributors: we really > need to heed when users are willing to send in patches, or else they'll > never come back... I can commit this stuff, but I'd like to have at least > another pair of eyeballs go over it at least once. Or just tell me to go > ahead, I guess :) I just don't want to discourage Matt from contributing > in the future. > > Cheers, > > f > > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev From oliphant at ee.byu.edu Wed Jul 20 15:08:49 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Wed, 20 Jul 2005 13:08:49 -0600 Subject: [SciPy-dev] [PATCH] Compilation with gcc4/gfortran In-Reply-To: <200507200945.50075.ravi@ati.com> References: <200507200945.50075.ravi@ati.com> Message-ID: <42DEA141.4030507@ee.byu.edu> Ravikiran Rajagopal wrote: >Hi, > Please find attached a patch (against scipy CVS) to compile with gcc 4.0. >The changes are very simple and should not hurt any other set up: > 1. Add "gfortran" as an option for Fortran compilation. > 2. Add libgfortran as a replacement for libg2c (needs some tweaking). > 3. Modify Lib/linalg/iterative/*.f.src to avoid jumping into a block. > 4. Remove sse2 optimizations (see mailing lists for more information). >I have tested this on Linux x86 with gcc CVS stable branch (4_0_branch) which >is scheduled to be released as gcc 4.0.2. gcc 4.0.1 does not work since >support for Hollerith constants (this obsolete construct is heavily used in >scipy) was added only last week. Could someone with sufficient karma commit >this? > Would there be any object to contributing C++ code into scipy? As far as I >can see, scipy does not use any C++ constructs. Is this intentional? > > I don't know of any policy against C++. In fact weave uses c++ quite a bit. I just think the main contributors have been more comfortable with c. Thanks for the patch. I will try to apply it soon, unless someone else gets a chance. -Travis From Fernando.Perez at colorado.edu Wed Jul 20 15:44:57 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 20 Jul 2005 13:44:57 -0600 Subject: [SciPy-dev] [PATCH] Compilation with gcc4/gfortran In-Reply-To: <42DEA141.4030507@ee.byu.edu> References: <200507200945.50075.ravi@ati.com> <42DEA141.4030507@ee.byu.edu> Message-ID: <42DEA9B9.2060606@colorado.edu> Travis Oliphant wrote: > Thanks for the patch. > > I will try to apply it soon, unless someone else gets a chance. Go for it, I'll take care of the fftw3 one. Best, f From Fernando.Perez at colorado.edu Wed Jul 20 15:46:37 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 20 Jul 2005 13:46:37 -0600 Subject: [SciPy-dev] fftw3 support In-Reply-To: <200507201459.06187.ravi@ati.com> References: <42B30F4B.4030504@mit.edu> <42DB22E1.8040500@colorado.edu> <200507201459.06187.ravi@ati.com> Message-ID: <42DEAA1D.20202@colorado.edu> Ravikiran Rajagopal wrote: > Hi, > I have tested the patches against scipy cvs from 5 days ago and they seem to > be absolutely fine. My tests were all on Fedora Core 4 with gcc 4.0. > Matt, thanks for the patches - I can finally get rid of fftw 2 which was > long ago replaced in all my other production code. Thanks for double checking, I'll take care of this later. Cheers, f From ravi at ati.com Thu Jul 21 10:45:47 2005 From: ravi at ati.com (Ravikiran Rajagopal) Date: Thu, 21 Jul 2005 10:45:47 -0400 Subject: [SciPy-dev] [PATCH] Compilation with gcc4/gfortran In-Reply-To: <42DEA141.4030507@ee.byu.edu> References: <200507200945.50075.ravi@ati.com> <42DEA141.4030507@ee.byu.edu> Message-ID: <200507211045.47764.ravi@ati.com> On Wednesday 20 July 2005 15:08, Travis Oliphant wrote: > > 2. Add libgfortran as a replacement for libg2c (needs some tweaking). [...] > I will try to apply it soon, unless someone else gets a chance. Hmmm, apparently the tweaking is not simple. I have so far been unable to figure out exactly where g2c is set. The patch I sent earlier is fine but probably requires one more step to find libgfortran. I have a soft link on my test machine which points libg2c.so to libgfortran.so, but that is merely a workaround. Could one of the scipy_distutils gurus comment about this? Regards, Ravi From oliphant at ee.byu.edu Thu Jul 21 18:19:25 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Thu, 21 Jul 2005 16:19:25 -0600 Subject: [SciPy-dev] Re: Wavelets and scipy... In-Reply-To: <42DFD1C5.8000901@enthought.com> References: <42DE965C.7010609@colorado.edu> <42DEB42B.8010404@enthought.com> <42DEBBAD.8060001@colorado.edu> <42DFC831.30607@enthought.com> <42DFD1C5.8000901@enthought.com> Message-ID: <42E01F6D.9080207@ee.byu.edu> Joe Cooper wrote: > eric jones wrote: > >> Fernando, all this sounds great to me. >> >> Thanks Joe for getting this setup. >> >> Travis, I share your concern and desire, but understand Fernando's >> also. In the short term, gettting them up and running seem slike the >> best approach. >> >> It would be great to get SciPy moved over to svn so that this whole >> process is trivial. Problem is, (as usualand as is the same for all >> of you) there is a ton of other stuff sucking down our time here. >> Joe, how hard is this? Can it happen in a few hours, or is this a >> "few days" sort of thing? > > > At this point it is a "it can't happen yet, no matter how much time I > might spend on it" kind of thing. I made the attempt several weeks > ago. cvs2svn choked on the repository with a mysterious error > message. Bug was reported, copies of the relevant files were > exchanged with an interested developer. No fix or workaround has been > forthcoming. Without a working cvs2svn, there is no way to migrate > SciPy to Subversion without losing all history, which is more > destructive than the problems of CVS. I'll ping said developer and > see if there has been any progress on this. Apparently our revision > numbers look funny to cvs2svn. Well, perhaps the right thing to do is to start a fresh scipy svn tree. Then I could add scipy.base (numeric3) to it and build up the rest of scipy from there. It has to be done anyway, and we might as well start fresh. There are several reorginazations that have to take place, and I was always under the impression that we would start on the new scipy with a fresh svn tree. So, why don't you just set up a scipy svn server with the right permissions and we can transfer things over as we see fit. Yes, we lose history, but we have the old scipy at CVS still and enough changes are happening that I don't see the problem with losing the history. I'ts a good time for cleaning up in general. I'd like to work on this through August and be ready for SciPy 2005 with a new scipy built on top of scipy.base (with wavelets added...) So, can Joe just set up a blank scipy svn tree for us to use. Pearu, do you have any time in August to help with the reorganization? -Travis From Fernando.Perez at colorado.edu Fri Jul 22 00:03:09 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Thu, 21 Jul 2005 22:03:09 -0600 Subject: [SciPy-dev] fftw3 support In-Reply-To: <42B30F4B.4030504@mit.edu> References: <42B30F4B.4030504@mit.edu> Message-ID: <42E06FFD.6020405@colorado.edu> Matt Fishburn wrote: > Hello, > > I've attached patches against the current cvs source for fftw3 support > in scipy. I've only tested these under x86 *nix (debian with various > combinations of fftw-dev and fftw3-dev installed). Could a few people > please try the patches and send build feedback? > > fft-c-source.diff is diff'ed against the c source/header files in > Lib/fftpack/src and system_info.diff is diff'ed against the build > detection code in scipy_core/scipy_distutils/system_info.py I also ran a test on this and it worked fine for me. Committed to CVS. Thanks, Matt. Best, f From nwagner at mecha.uni-stuttgart.de Fri Jul 22 03:28:44 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 22 Jul 2005 09:28:44 +0200 Subject: [SciPy-dev] FFT and new failures Message-ID: <42E0A02C.3070307@mecha.uni-stuttgart.de> Using latest cvs scipy.test(1,verbosity=10) results in ====================================================================== FAIL: check_n_argument_complex (scipy.fftpack.basic.test_basic.test_fft) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", line 118, in check_n_argument_complex assert_array_almost_equal(y[0],direct_dft(x1)) File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 740, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 100.0%): Array 1: [ 4.+0.j 16.+4.j 12.+0.j 8.+0.j] Array 2: [ 10.+1.j -3.+2.j -2.-1.j -1.-2.j] ====================================================================== FAIL: check_axes_argument (scipy.fftpack.basic.test_basic.test_fftn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", line 502, in check_axes_argument assert_array_almost_equal(fft(x[i,j,:]),y[i,j,:]) File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 740, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 66.6666666667%): Array 1: [ 6. +0.j -1.5+0.8660254j -1.5-0.8660254j] Array 2: [ 6. +0.j -1.5-0.8660254j -1.5+0.8660254j] ====================================================================== FAIL: check_definition (scipy.fftpack.basic.test_basic.test_fftn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", line 419, in check_definition assert_array_almost_equal(y,direct_dftn(x)) File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 740, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 100.0%): Array 1: [[ 45. +0.j -4.5-2.5980762j -4.5+2.5980762j] [-13.5-7.7942286j 0. +0.j 0. +0.j ] [-13.5+7.79... Array 2: [[ 135. +0.j -13.5-7.7942286j -13.5+7.7942286j] [ -4.5+2.5980762j -4.5+2.5980762j -4.5+2.5980762j] [ -4... ====================================================================== FAIL: check_shape_axes_argument (scipy.fftpack.basic.test_basic.test_fftn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", line 531, in check_shape_axes_argument assert_array_almost_equal (y[i],fft(large_x1[i])) File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 740, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 50.0%): Array 1: [ 6.+0.j -2.+2.j 2.+0.j -2.-2.j] Array 2: [ 6.+0.j -2.-2.j 2.+0.j -2.+2.j] ====================================================================== FAIL: check_definition (scipy.fftpack.basic.test_basic.test_ifftn) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", line 586, in check_definition assert_array_almost_equal(y,direct_idftn(x)) File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 740, in assert_array_almost_equal assert cond,\ AssertionError: Arrays are not almost equal (mismatch 100.0%): Array 1: [[ 5. +0.j -0.5+0.2886751j -0.5-0.2886751j] [-1.5+0.8660254j 0. +0.j 0. +0.j ] [-1.5-0.8660254j ... Array 2: [[ 15. +0.j -1.5+0.8660254j -1.5-0.8660254j] [ -0.5-0.2886751j -0.5-0.2886751j -0.5-0.2886751j] [ -0.5+0.28... ====================================================================== FAIL: check_round (scipy.special.basic.test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1789, in check_round assert_array_equal(rnd,rndrl) File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 715, in assert_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 25.0%): Array 1: [10 10 11 11] Array 2: [10 10 10 11] ---------------------------------------------------------------------- Ran 1265 tests in 3.386s FAILED (failures=6) >>> Nils From harkal at sylphis3d.com Fri Jul 22 05:02:28 2005 From: harkal at sylphis3d.com (Harry Kalogirou) Date: Fri, 22 Jul 2005 12:02:28 +0300 Subject: [SciPy-dev] RQ Decomposition Message-ID: <1122022948.9828.14.camel@cool> Hello! I'm trying to implement th RQ decomposition in SciPy. Unfortunatly I'm not good at fortran and I have some problems. So far I created the wrapper function for "dgerqf" based on the already provided wrapper for the "dgeqrf" function. Now I try to implement the "linalg.rq" function based on the "linalg.qr". The problem is that I can't compute Q as said in the comments of the "dgerqf" function. >From the comments of the "dgerqf" function : > where tau is a real scalar, and v is a real vector with > v(n-k+i+1:n) = 0 and v(n-k+i) = 1; v(1:n-k+i-1) is stored on exit in > A(m-k+i,1:n-k+i-1), and tau in TAU(i). The code I write is : <----code----code----> k = min(M,N) for i in range(k): v = zeros((M,),t) v[N-k+i] = 1 v[0:N-k+i-1] = rq[M-k+i,0:N-k+i-1] H = gemm(-tau[i],v,v,1+0j,ident,trans_b=2) Q = gemm(1,Q,H) <----code----code----> It does not work. As I don't understand fortran indexing scheme maybe i'm doing something wrong... can anyone help?? Best regards, Harry From pearu at scipy.org Fri Jul 22 06:04:47 2005 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 22 Jul 2005 05:04:47 -0500 (CDT) Subject: [SciPy-dev] FFT and new failures In-Reply-To: <42E0A02C.3070307@mecha.uni-stuttgart.de> References: <42E0A02C.3070307@mecha.uni-stuttgart.de> Message-ID: Hi, The bugs leading to the errors below are now fixed in CVS. They appared only when using fftw3 library in fftpack. Pearu On Fri, 22 Jul 2005, Nils Wagner wrote: > Using latest cvs scipy.test(1,verbosity=10) results in > > ====================================================================== > FAIL: check_n_argument_complex (scipy.fftpack.basic.test_basic.test_fft) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", > line 118, in check_n_argument_complex > assert_array_almost_equal(y[0],direct_dft(x1)) > File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line > 740, in assert_array_almost_equal > assert cond,\ > AssertionError: > Arrays are not almost equal (mismatch 100.0%): > Array 1: [ 4.+0.j 16.+4.j 12.+0.j 8.+0.j] > Array 2: [ 10.+1.j -3.+2.j -2.-1.j -1.-2.j] > > > ====================================================================== > FAIL: check_axes_argument (scipy.fftpack.basic.test_basic.test_fftn) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", > line 502, in check_axes_argument > assert_array_almost_equal(fft(x[i,j,:]),y[i,j,:]) > File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line > 740, in assert_array_almost_equal > assert cond,\ > AssertionError: > Arrays are not almost equal (mismatch 66.6666666667%): > Array 1: [ 6. +0.j -1.5+0.8660254j -1.5-0.8660254j] > Array 2: [ 6. +0.j -1.5-0.8660254j -1.5+0.8660254j] > > > ====================================================================== > FAIL: check_definition (scipy.fftpack.basic.test_basic.test_fftn) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", > line 419, in check_definition > assert_array_almost_equal(y,direct_dftn(x)) > File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line > 740, in assert_array_almost_equal > assert cond,\ > AssertionError: > Arrays are not almost equal (mismatch 100.0%): > Array 1: [[ 45. +0.j -4.5-2.5980762j -4.5+2.5980762j] > [-13.5-7.7942286j 0. +0.j 0. +0.j ] > [-13.5+7.79... > Array 2: [[ 135. +0.j -13.5-7.7942286j -13.5+7.7942286j] > [ -4.5+2.5980762j -4.5+2.5980762j -4.5+2.5980762j] > [ -4... > > > ====================================================================== > FAIL: check_shape_axes_argument (scipy.fftpack.basic.test_basic.test_fftn) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", > line 531, in check_shape_axes_argument > assert_array_almost_equal (y[i],fft(large_x1[i])) > File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line > 740, in assert_array_almost_equal > assert cond,\ > AssertionError: > Arrays are not almost equal (mismatch 50.0%): > Array 1: [ 6.+0.j -2.+2.j 2.+0.j -2.-2.j] > Array 2: [ 6.+0.j -2.-2.j 2.+0.j -2.+2.j] > > > ====================================================================== > FAIL: check_definition (scipy.fftpack.basic.test_basic.test_ifftn) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.4/site-packages/scipy/fftpack/tests/test_basic.py", > line 586, in check_definition > assert_array_almost_equal(y,direct_idftn(x)) > File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line > 740, in assert_array_almost_equal > assert cond,\ > AssertionError: > Arrays are not almost equal (mismatch 100.0%): > Array 1: [[ 5. +0.j -0.5+0.2886751j -0.5-0.2886751j] > [-1.5+0.8660254j 0. +0.j 0. +0.j ] > [-1.5-0.8660254j ... > Array 2: [[ 15. +0.j -1.5+0.8660254j -1.5-0.8660254j] > [ -0.5-0.2886751j -0.5-0.2886751j -0.5-0.2886751j] > [ -0.5+0.28... > > > ====================================================================== > FAIL: check_round (scipy.special.basic.test_basic.test_round) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/usr/local/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", > line 1789, in check_round > assert_array_equal(rnd,rndrl) > File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line > 715, in assert_array_equal > assert cond,\ > AssertionError: > Arrays are not equal (mismatch 25.0%): > Array 1: [10 10 11 11] > Array 2: [10 10 10 11] > > > ---------------------------------------------------------------------- > Ran 1265 tests in 3.386s > > FAILED (failures=6) > >>>> > > Nils > > > > > _______________________________________________ > Scipy-dev mailing list > Scipy-dev at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-dev > From pearu at scipy.org Fri Jul 22 06:15:22 2005 From: pearu at scipy.org (Pearu Peterson) Date: Fri, 22 Jul 2005 05:15:22 -0500 (CDT) Subject: [SciPy-dev] fftw3 support In-Reply-To: <42E06FFD.6020405@colorado.edu> References: <42B30F4B.4030504@mit.edu> <42E06FFD.6020405@colorado.edu> Message-ID: On Thu, 21 Jul 2005, Fernando Perez wrote: > Matt Fishburn wrote: >> Hello, >> >> I've attached patches against the current cvs source for fftw3 support in >> scipy. I've only tested these under x86 *nix (debian with various >> combinations of fftw-dev and fftw3-dev installed). Could a few people >> please try the patches and send build feedback? >> >> fft-c-source.diff is diff'ed against the c source/header files in >> Lib/fftpack/src and system_info.diff is diff'ed against the build detection >> code in scipy_core/scipy_distutils/system_info.py > > I also ran a test on this and it worked fine for me. Are you sure that you ran the tests against scipy.fftpack with fftw3 support? There were few bugs that caused some unittests to fail. The bugs are now fixed but it would be nice if new patches would not break the scipy tests in future (though it's a clever way to get attention:). Matt, thanks for sending the patches. Fernando, thanks for making sure that patches were applied. Regards, Pearu From nwagner at mecha.uni-stuttgart.de Fri Jul 22 07:29:43 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Fri, 22 Jul 2005 13:29:43 +0200 Subject: [SciPy-dev] FAIL: check_round (scipy.special.basic.test_basic.test_round) Message-ID: <42E0D8A7.5030804@mecha.uni-stuttgart.de> Hi Pearu, Thank you for the latest bug fixes related to fftpack. How about the remaining failure ? ====================================================================== FAIL: check_round (scipy.special.basic.test_basic.test_round) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/scipy/special/tests/test_basic.py", line 1789, in check_round assert_array_equal(rnd,rndrl) File "/usr/local/lib/python2.4/site-packages/scipy_test/testing.py", line 715, in assert_array_equal assert cond,\ AssertionError: Arrays are not equal (mismatch 25.0%): Array 1: [10 10 11 11] Array 2: [10 10 10 11] ---------------------------------------------------------------------- Ran 1137 tests in 4.310s FAILED (failures=1) Nils P.S. Did you take look at the problems related to scipy.optimize which I have submitted to the bug tracker three weeks ago ? From fishburn at MIT.EDU Fri Jul 22 08:19:58 2005 From: fishburn at MIT.EDU (Matt Fishburn) Date: Fri, 22 Jul 2005 08:19:58 -0400 Subject: [SciPy-dev] fftw3 support In-Reply-To: References: <42B30F4B.4030504@mit.edu> <42E06FFD.6020405@colorado.edu> Message-ID: <42E0E46E.5080309@mit.edu> Pearu Peterson wrote: > Are you sure that you ran the tests against scipy.fftpack with fftw3 > support? There were few bugs that caused some unittests to fail. The > bugs are now fixed but it would be nice if new patches would not break > the scipy tests in future (though it's a clever way to get attention:). Sorry about that. I should have paid attention to testing everything - I didn't test fftn enough or run the test from scipy. I will be more careful in the future. -Matt Fishburn From harkal at sylphis3d.com Fri Jul 22 09:31:46 2005 From: harkal at sylphis3d.com (Harry Kalogirou) Date: Fri, 22 Jul 2005 16:31:46 +0300 Subject: [SciPy-dev] RQ Decomposition Message-ID: <1122039106.18178.1.camel@cool> Hi, I'm sending you a patch that implements RQ decomposition in SciPy. Is it ok? Best regards, Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: rq.diff Type: text/x-patch Size: 3589 bytes Desc: not available URL: From Fernando.Perez at colorado.edu Fri Jul 22 12:21:56 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 22 Jul 2005 10:21:56 -0600 Subject: [SciPy-dev] fftw3 support In-Reply-To: <42E0E46E.5080309@mit.edu> References: <42B30F4B.4030504@mit.edu> <42E06FFD.6020405@colorado.edu> <42E0E46E.5080309@mit.edu> Message-ID: <42E11D24.2020509@colorado.edu> Matt Fishburn wrote: > Pearu Peterson wrote: > >>Are you sure that you ran the tests against scipy.fftpack with fftw3 >>support? There were few bugs that caused some unittests to fail. The >>bugs are now fixed but it would be nice if new patches would not break >>the scipy tests in future (though it's a clever way to get attention:). > > > Sorry about that. I should have paid attention to testing everything - > I didn't test fftn enough or run the test from scipy. I will be more > careful in the future. My bad too :( Juggling too many balls at the same time, sorry. I tried to set up fft3 for the test, but it seems I did something wrong somewhere, or ended up running the tests against the old version of scipy (I was trying not to change our system-wide install with the testing version). Whatever actually happened, sorry for the screwup, and many thanks to Pearu for the quick bailout. Cheers, f From joe at enthought.com Sun Jul 24 20:38:10 2005 From: joe at enthought.com (Joe Cooper) Date: Sun, 24 Jul 2005 19:38:10 -0500 Subject: [SciPy-dev] Another attempt at converting SciPy CVS to Subversion Message-ID: <42E43472.8000707@enthought.com> Hi all, Just a heads up: I'm shutting down access to the scipy CVS repository for a few minutes, as I'm going to give another go to converting to Subversion. It should return shortly. I will give more warning before the actual conversion takes place...which could be as soon as Monday, if testing goes well. From rng7 at cornell.edu Mon Jul 25 15:07:04 2005 From: rng7 at cornell.edu (Ryan Gutenkunst) Date: Mon, 25 Jul 2005 15:07:04 -0400 Subject: [SciPy-dev] Wrapped up lsodar Message-ID: <42E53858.7020304@cornell.edu> Hi all, I've wrapped up the lsodar integration routine from odepack. (http://www.netlib.org/odepack/) In the hopes of being useful to SciPy, I've made the wrapper backward-compatible with the current odeint in SciPy. Enhancements to the old odeint: * Root-finding: Solve dydt = f while looking for roots of the function g(y, t). For a given root, the integrator can either just record its crossing, or terminate at that point. * Intermediate output mode: If int_pts = True, then the integrator returns yout and tout, which include every step the integrator took. This is useful if you want to track the behavior of a function, but don't know where the interesting regions are ahead of time. * f2py used to wrap: I have some vague recollection of a desire to move away from hand-generated wrappers in SciPy. Issues remaining: (I'd love help with any of these.) * col_deriv: The jacobian could be calculated in Fortran order, which would prevent a few array copies. I think f2py provides a way to specify whether arrays should be copied/transposed, but I couldn't understand it. :-) * Banded jacobians: I never used this feature, and I don't really understand it, so there's no test cases for it yet. * Speed: It's about 10% slower than odeint on a test problem. I don't know yet how much of the slowdown is in the wrapping or the algorithm switch. It might also just be that my f2py'ing is linking to different libraries than odeint was compiled with on this machine. I'm not sure whether this is actually interesting to SciPy, but I figured I put it out there. Any comments are appreciated, and if changes need to be made to get it into the core SciPy distribution, I'm happy to make them. (The attached .tgz file contains: lsodar.pyf - The f2py wrapper file lsodar.py - The python interface test_lsodar.py - Unit tests for the integrator speedTest.py - A race between odeint and the newly-wrapped version) Cheers, Ryan -- Ryan Gutenkunst | Cornell LASSP | "It is not the mountain | we conquer but ourselves." Clark 535 / (607)227-7914 | -- Sir Edmund Hillary AIM: JepettoRNG | http://www.physics.cornell.edu/~rgutenkunst/ -------------- next part -------------- A non-text attachment was scrubbed... Name: lsodar.tgz Type: application/x-tar Size: 6826 bytes Desc: not available URL: From nwagner at mecha.uni-stuttgart.de Mon Jul 25 15:21:52 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Mon, 25 Jul 2005 21:21:52 +0200 Subject: [SciPy-dev] Bug in f2py Message-ID: Hi all, python setup.py build results in Reading fortran codes... Reading file 'Lib/optimize/lbfgsb-0.9/lbfgsb.pyf' (format:free) Post-processing... Block: _lbfgsb Block: setulb "name 'x' is not defined" in evaluating 'len(x)' (available names: []) Traceback (most recent call last): File "setup.py", line 124, in ? setup_package(ignore_packages) File "setup.py", line 112, in setup_package url = "http://www.scipy.org", File "/home/nwagner/cvs/scipy/scipy_core/scipy_distutils/core.py", line 73, in setup return old_setup(**new_attr) File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/home/nwagner/cvs/scipy/scipy_core/scipy_distutils/command/build_src.py", line 129, in run self.build_sources() File "/home/nwagner/cvs/scipy/scipy_core/scipy_distutils/command/build_src.py", line 215, in build_sources self.build_extension_sources(ext) File "/home/nwagner/cvs/scipy/scipy_core/scipy_distutils/command/build_src.py", line 255, in build_extension_sources sources = self.f2py_sources(sources, ext) File "/home/nwagner/cvs/scipy/scipy_core/scipy_distutils/command/build_src.py", line 399, in f2py_sources f2py2e.run_main(f2py_options + ['--build-dir',target_dir,source]) File "/usr/lib/python2.4/site-packages/f2py2e/f2py2e.py", line 417, in run_main postlist=callcrackfortran(files,options) File "/usr/lib/python2.4/site-packages/f2py2e/f2py2e.py", line 356, in callcrackfortran postlist=crackfortran.crackfortran(files) File "/usr/lib/python2.4/site-packages/f2py2e/crackfortran.py", line 2521, in crackfortran postlist=postcrack(grouplist[0]) File "/usr/lib/python2.4/site-packages/f2py2e/crackfortran.py", line 1469, in postcrack g=postcrack(g,tab=tab+'\t') File "/usr/lib/python2.4/site-packages/f2py2e/crackfortran.py", line 1487, in postcrack block['body']=analyzebody(block,args,tab=tab) File "/usr/lib/python2.4/site-packages/f2py2e/crackfortran.py", line 1628, in analyzebody b=postcrack(b,as,tab=tab+'\t') File "/usr/lib/python2.4/site-packages/f2py2e/crackfortran.py", line 1487, in postcrack block['body']=analyzebody(block,args,tab=tab) File "/usr/lib/python2.4/site-packages/f2py2e/crackfortran.py", line 1628, in analyzebody b=postcrack(b,as,tab=tab+'\t') File "/usr/lib/python2.4/site-packages/f2py2e/crackfortran.py", line 1483, in postcrack block['vars']=analyzevars(block) File "/usr/lib/python2.4/site-packages/f2py2e/crackfortran.py", line 2140, in analyzevars length = _eval_length(vars[n]['charselector']['*'], NameError: global name '_eval_length' is not defined Nils From chrisk at MIT.EDU Tue Jul 26 18:02:52 2005 From: chrisk at MIT.EDU (ChrisK) Date: Tue, 26 Jul 2005 18:02:52 -0400 Subject: [SciPy-dev] bulding with Fink on 10.4 with xcode-2.1 Message-ID: <42E6B30C.3000705@mit.edu> I was rebuilding scipy on Max OS X and had to do some slight patching. This is with fink on Max OS 10.4.2 using XCode 2.1 (w/gcc 4.0), for the scipy-py24 package. (for version 0.3.2) There were two files where 'static' was causing a compile error: scipy/Lib/interpolate/fitpack.pyf scipy/Lib/stats/ranlib_all.c and one file that did not setup HAVE_INVERSE_HYPERBOLIC properly, which was fixed by patching the build file: scipy/scipy_core/scipy_base/setup_scipy_base.py Thus the 4th compile worked. So I thought I would post this patch here in case someone could put them in upstream. I have also sent this to the fink site and maintainer. -- Chris -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scipy-py.patch URL: From rkern at ucsd.edu Tue Jul 26 20:40:01 2005 From: rkern at ucsd.edu (Robert Kern) Date: Tue, 26 Jul 2005 17:40:01 -0700 Subject: [SciPy-dev] bulding with Fink on 10.4 with xcode-2.1 In-Reply-To: <42E6B30C.3000705@mit.edu> References: <42E6B30C.3000705@mit.edu> Message-ID: <42E6D7E1.1030802@ucsd.edu> ChrisK wrote: > I was rebuilding scipy on Max OS X and had to do some slight patching. > > This is with fink on Max OS 10.4.2 using XCode 2.1 (w/gcc 4.0), for > the scipy-py24 package. (for version 0.3.2) [...] > So I thought I would post this patch here in case someone could put them > in upstream. I have also sent this to the fink site and maintainer. Since it's not a patch against CVS, it won't be applied here upstream. -- Robert Kern rkern at ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From w.northcott at unsw.edu.au Wed Jul 27 05:45:48 2005 From: w.northcott at unsw.edu.au (Bill Northcott) Date: Wed, 27 Jul 2005 19:45:48 +1000 Subject: [SciPy-dev] Another attempt at converting SciPy CVS to Subversion Message-ID: As of 09:30 UTC 27th July cvs seems to be broken. Bill Northcott From nwagner at mecha.uni-stuttgart.de Wed Jul 27 07:04:08 2005 From: nwagner at mecha.uni-stuttgart.de (Nils Wagner) Date: Wed, 27 Jul 2005 13:04:08 +0200 Subject: [SciPy-dev] Load MATLAB 7 MAT-files in scipy Message-ID: <42E76A28.6040601@mecha.uni-stuttgart.de> Hi all, AFAIK, it's not possible to load MATLAB 7 MAT-files in scipy. help (io.loadmat) results in Both v4 (Level 1.0) and v6 matfiles are supported. Version 7.0 files are not yet supported. I am curious about the current features of scipy regarding I/O of MAT-files generated by Matlab v4 and v6 How about sparse matrix support ? Any comment would be appreciated. Nils References http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=7734&objectType=file From Fernando.Perez at colorado.edu Thu Jul 28 02:02:43 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Thu, 28 Jul 2005 00:02:43 -0600 Subject: [SciPy-dev] File swig_num_gen.py, anyone? Message-ID: <42E87503.10604@colorado.edu> Hi all, I need to wrap some C code and I want to allow it to use Numeric arrays. The swig_num.i file, which is in scipy's Lib/cluster/src directory, seems like a useful tool for this task. But if I try to use it, I get a swath of swig deprecation warnings, along with a few errors. I'd rather not fix that .i file by hand, b/c it carries at the top this warning: /************************************************************************/ /* swig_num.i -- typemaps for mapping C arrays to Python Numeric arrays */ /* */ /* This file is auto-generated by swig_num_gen.py. */ /* DO NOT EDIT THIS FILE DIRECTLY unless you want your changes */ /* clobbered by the next run of the generator. */ /************************************************************************/ Unfortunately the file swig_num_gen.py seems to have gone AWOL. Google doesn't find it, and not even a locate call directly at the scipy.org server (while ssh'd in) finds it, so it seems not even to be in the bowels of the CVS repo. Does anybody have an idea of where that file is? I'd rather work on fixing the code generator rather than the final .i file, especially because the zillion warnings are of only 2 kinds, and I'm pretty sure fixing each at the source would involve fixing only one pattern. Alternatively, if anybody has a good set of typemaps to use swig with Numeric which they can pass my way, I'll be very grateful. Cheers, f From jdhunter at ace.bsd.uchicago.edu Thu Jul 28 09:35:30 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu, 28 Jul 2005 08:35:30 -0500 Subject: [SciPy-dev] File swig_num_gen.py, anyone? In-Reply-To: <42E87503.10604@colorado.edu> (Fernando Perez's message of "Thu, 28 Jul 2005 00:02:43 -0600") References: <42E87503.10604@colorado.edu> Message-ID: <87pst3kq8t.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "Fernando" == Fernando Perez writes: Fernando> Alternatively, if anybody has a good set of typemaps to Fernando> use swig with Numeric which they can pass my way, I'll Fernando> be very grateful. Take a look at kiva/agg/agg_typemaps.i and kiva/agg/numeric.i in the enthought svn repository for lots of nice examples which support sequences and Numeric arrays transparently including dimension and type checks as needed. JDH From jdhunter at ace.bsd.uchicago.edu Thu Jul 28 09:35:30 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu, 28 Jul 2005 08:35:30 -0500 Subject: [SciPy-dev] File swig_num_gen.py, anyone? In-Reply-To: <42E87503.10604@colorado.edu> (Fernando Perez's message of "Thu, 28 Jul 2005 00:02:43 -0600") References: <42E87503.10604@colorado.edu> Message-ID: <87pst3kq8t.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "Fernando" == Fernando Perez writes: Fernando> Alternatively, if anybody has a good set of typemaps to Fernando> use swig with Numeric which they can pass my way, I'll Fernando> be very grateful. Take a look at kiva/agg/agg_typemaps.i and kiva/agg/numeric.i in the enthought svn repository for lots of nice examples which support sequences and Numeric arrays transparently including dimension and type checks as needed. JDH From jdhunter at ace.bsd.uchicago.edu Thu Jul 28 12:35:35 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu, 28 Jul 2005 11:35:35 -0500 Subject: [SciPy-dev] matplotlib cookbook wiki on scipy.org ? Message-ID: <87hdeezy5k.fsf@peds-pc311.bsd.uchicago.edu> I wanted to setup a wiki for matplotlib where I and others can post snippets, recipes and howtos. Is the scipy wiki an appropriate place for this? Eg, a link under "Topical Software" to "MatplotlibCookbook". As a cookbook, it could potentially create a lot of pages; presumably authors might want to upload images as well, so it might also consume more bandwidth and storage than typical wiki pages. I have no problem shopping for another place to host it, but I think the scipy site would be ideal if the scipy devs and enthought agree. Thanks! JDH From prabhu_r at users.sf.net Thu Jul 28 13:21:18 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Thu, 28 Jul 2005 22:51:18 +0530 Subject: [SciPy-dev] matplotlib cookbook wiki on scipy.org ? In-Reply-To: <87hdeezy5k.fsf@peds-pc311.bsd.uchicago.edu> References: <87hdeezy5k.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <17129.5134.894026.530004@monster.linux.in> >>>>> "John" == John Hunter writes: John> I wanted to setup a wiki for matplotlib where I and others John> can post snippets, recipes and howtos. Is the scipy wiki an John> appropriate place for this? Eg, a link under "Topical John> Software" to "MatplotlibCookbook". As a cookbook, it could John> potentially create a lot of pages; presumably authors might John> want to upload images as well, so it might also consume more John> bandwidth and storage than typical wiki pages. I think it is a good idea to put these things in the scipy pages (whereever appropriate). This also makes it easier for folks to edit content since their existing logins will work and they won't have to maintain yet another login/password elsewhere. Overall I think it would be cool if more folks do this. More eyeballs, more folks editing related pages. I don't know what the others think about this though. cheers, prabhu From travis at enthought.com Thu Jul 28 14:38:34 2005 From: travis at enthought.com (Travis N. Vaught) Date: Thu, 28 Jul 2005 13:38:34 -0500 Subject: [SciPy-dev] matplotlib cookbook wiki on scipy.org ? In-Reply-To: <17129.5134.894026.530004@monster.linux.in> References: <87hdeezy5k.fsf@peds-pc311.bsd.uchicago.edu> <17129.5134.894026.530004@monster.linux.in> Message-ID: <42E9262A.5030106@enthought.com> As you know, SciPy.org is a community site and scipy is an open tool. I heartily encourage you to post anything useful to scientific computing with python on the site--particularly if there is any community interest in doing so. With regard to size/bandwidth issues: bring it on...if the site falls over (hang in there Plone) we'll pick up the pieces. As a fellow community member, Enthought wants to see the community grow and flourish. As a website host, we're committed to making it work for the community. Regards, Travis Prabhu Ramachandran wrote: >>>>>>"John" == John Hunter writes: >>>>>> >>>>>> > > John> I wanted to setup a wiki for matplotlib where I and others > John> can post snippets, recipes and howtos. Is the scipy wiki an > John> appropriate place for this? Eg, a link under "Topical > John> Software" to "MatplotlibCookbook". As a cookbook, it could > John> potentially create a lot of pages; presumably authors might > John> want to upload images as well, so it might also consume more > John> bandwidth and storage than typical wiki pages. > >I think it is a good idea to put these things in the scipy pages >(whereever appropriate). This also makes it easier for folks to edit >content since their existing logins will work and they won't have to >maintain yet another login/password elsewhere. Overall I think it >would be cool if more folks do this. More eyeballs, more folks >editing related pages. > >I don't know what the others think about this though. > >cheers, >prabhu > >_______________________________________________ >Scipy-dev mailing list >Scipy-dev at scipy.net >http://www.scipy.net/mailman/listinfo/scipy-dev > > -- ........................ Travis N. Vaught CEO Enthought, Inc. http://www.enthought.com ........................ From jdhunter at ace.bsd.uchicago.edu Thu Jul 28 14:46:54 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu, 28 Jul 2005 13:46:54 -0500 Subject: [SciPy-dev] matplotlib cookbook wiki on scipy.org ? In-Reply-To: <42E9262A.5030106@enthought.com> ("Travis N. Vaught"'s message of "Thu, 28 Jul 2005 13:38:34 -0500") References: <87hdeezy5k.fsf@peds-pc311.bsd.uchicago.edu> <17129.5134.894026.530004@monster.linux.in> <42E9262A.5030106@enthought.com> Message-ID: <87hdeedazl.fsf@peds-pc311.bsd.uchicago.edu> >>>>> "Travis" == Travis N Vaught writes: Travis> As you know, SciPy.org is a community site and scipy is an Travis> open tool. I heartily encourage you to post anything Travis> useful to scientific computing with python on the Travis> site--particularly if there is any community interest in Travis> doing so. Travis> With regard to size/bandwidth issues: bring it on...if the Travis> site falls over (hang in there Plone) we'll pick up the Travis> pieces. As a fellow community member, Enthought wants to Travis> see the community grow and flourish. As a website host, Travis> we're committed to making it work for the community. Thanks Travis, that's all the encouragement I need! I've had a lingering confusion over whether scipy.org is meant to support scipy the tool or scientific python in general, and your answer clears that up for me. JDH From swisher at enthought.com Thu Jul 28 14:54:20 2005 From: swisher at enthought.com (Janet M. Swisher) Date: Thu, 28 Jul 2005 13:54:20 -0500 Subject: [SciPy-dev] ANN: SciPy 2005 Conf: Abstracts and early registration due 7/29/05 Message-ID: <42E929DC.2080507@enthought.com> Friday, July 29, 2005 is the deadline for abstract submission for the 2005 Scientific Computing in Python Conference, scheduled for September 22 and 23, at Caltech. More information on the conference, including abstract guidelines, can be found at The 29th is also the deadline for early registration for the conference. The early registration fee is US$100; regular registration is US$150. The conference fee includes breakfast and lunch both days, and dinner on the first day. -- Janet Swisher --- Senior Technical Writer Enthought, Inc. http://www.enthought.com From jdhunter at ace.bsd.uchicago.edu Thu Jul 28 18:34:30 2005 From: jdhunter at ace.bsd.uchicago.edu (John Hunter) Date: Thu, 28 Jul 2005 17:34:30 -0500 Subject: [SciPy-dev] edit scipy zwiki using emacs? Message-ID: <874qae8sqx.fsf@peds-pc311.bsd.uchicago.edu> Has anyone gotten emacs working with the zwiki/plone on scipy.org? I have used it in the past with zwiki-mode and ange-ftp, but I think this requires direct ftp access to the server, and the plone site appears to have its own authentication system http://zwiki.org/FAQs#How%20do%20I%20edit%20with%20Emacs? http://zwiki.org/EmacsAndWiki The link below details an approach that can work with xmlrpc, but requires some server side code in the extensions dir http://www.zope.org/Members/alburt/zwiki_mode Any pointers? JDH From joe at enthought.com Thu Jul 28 19:28:47 2005 From: joe at enthought.com (Joe Cooper) Date: Thu, 28 Jul 2005 18:28:47 -0500 Subject: [SciPy-dev] edit scipy zwiki using emacs? In-Reply-To: <874qae8sqx.fsf@peds-pc311.bsd.uchicago.edu> References: <874qae8sqx.fsf@peds-pc311.bsd.uchicago.edu> Message-ID: <42E96A2F.10701@enthought.com> John Hunter wrote: > Has anyone gotten emacs working with the zwiki/plone on scipy.org? I > have used it in the past with zwiki-mode and ange-ftp, but I think > this requires direct ftp access to the server, and the plone site > appears to have its own authentication system > > http://zwiki.org/FAQs#How%20do%20I%20edit%20with%20Emacs? > http://zwiki.org/EmacsAndWiki > > The link below details an approach that can work with xmlrpc, but > requires some server side code in the extensions dir > > http://www.zope.org/Members/alburt/zwiki_mode > > > Any pointers? I'd welcome some Plone pointers. ;-) I had, at one point, gotten WebDAV access to the plone site working, but I haven't tried it in ages, so I don't know if it remains working. I've never touched XMLRPC with plone and it sounds kind of scary to me (almost everything about plone scares me), but I'm willing to give it a try. We're working our current machine pretty hard, but the migration to the new server will happen by this weekend, and at that point I'll be happy to install some extra products and poke around a bit to see if I can make all of this work for you. FTP access is enabled on our plone instance as well, though I have no clue how to use it, or if the firewall on scipy.org is allowing access to it. Again, I can spend some time figuring it out in the next few days. From joe at enthought.com Thu Jul 28 21:02:59 2005 From: joe at enthought.com (Joe Cooper) Date: Thu, 28 Jul 2005 20:02:59 -0500 Subject: [SciPy-dev] SciPy CVS to Subversion migration Message-ID: <42E98043.9030900@enthought.com> Hi all, The issues with converting our CVS repository to Subversion have been resolved, and so I'd like to make the switch tomorrow (Friday) afternoon. If you have anything you'd like to check-in before the CVS repository is gone forever, please do so before then. You will have to check out a new working copy after the conversion occurs. If the timing of this outage will cause anyone discomfort, please let me know, and I will re-schedule for another day. Just FYI: History will be maintained from the old CVS tree. Once the migration occurs, branching, merging, and reorganizing the tree will become trivially simple and reliable (and anyone with commit access can make those kinds of changes without system administrator intervention). I know there is a contingent of SciPy developers that would like to do some long-desired serious cleanups and purges within the tree--the new Subversion repository will easily allow these kinds of changes without having to throw out all of the old history and start fresh. If, after the migration, you find you still want to start fresh, let me know and I'll create a new Subversion repo for you to work in. Holler if you have any further questions or concerns. Thanks, Joe From oliphant at ee.byu.edu Sat Jul 30 21:29:16 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Sat, 30 Jul 2005 19:29:16 -0600 Subject: [SciPy-dev] Re: [Numpy-discussion] Suggested Addition to the new array PEP In-Reply-To: <42E800B0.7050803@noaa.gov> References: <42E800B0.7050803@noaa.gov> Message-ID: <42EC296C.8040401@ee.byu.edu> Chris Barker wrote: > Hi all, but particularly Travis, > > I just took the time to read the new array PEP: > > http://numeric.scipy.org/PEP.txt > > It looks great. > > I do have one suggestion for an addition method: > > change_type(NewType) # or some other name: > > Change the type that the bytes in the array represent, without > changing the data at. Dimensions will change if the new type has a > different itemsize than the old. > Actually, I think this functionality is supported by attribute assignment. Anyway, it is a good suggestion and one that should be supported ( I know I wanted it to be supported at some time, I don't know if it is). > > By the way, I'm also not seeing tostring() or tobuffer() listed in the > PEP The are still there just attributes now... a.data is always a buffer object a.data[:] is a string (because [:] on a buffer object always produces the string)