Mailman 3 May 2007 - SciPy-Dev

Question about Kaiser Implementation in firwin
by Buehler, Eric (AGRE) 04 Oct '08

04 Oct '08

Hello, I have been using the signal.firwin FIR design tool and I have a question about the implementation. Scipy-0.4.8 Numpy-0.9.6 I am generating a kaiser window with the following parameters: N = 128 Cutoff = ~4e7 width = .3 All of the special kaiser generation parameters in the function follow Oppenheim and Schafer well. Even the sinc function for linear phase is follows exactly. However, the last line of the firwin function is causing me some heartburn. filter_design.py 1538 win = get_window(window,N,fftbins=1) 1539 alpha = N//2 1540 m = numpy.arange(0,N) 1541 h = win*special.sinc(cutoff*(m-alpha)) 1542 return h / sum(h) Line 1542 of filter_design.py, "return h / sum(h)", normalizes the function where it doesn't seem necessary, at least in the kaiser window case. Without the normalization, the kaiser window already returns a value of 1 at the zero frequency point. This normalization scales all of the data, making the window difficult to use in the frequency domain. Can someone point me to the rationale for this line? Looking at the code, this seems to be a pretty recent change (within the last year/year and a half). Thanks, Eric Buehler eric <dot> buehler <at> smiths-aerospace <dot> com ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

3 2

ZVODE, a Double Precision Complex ODE Solver
by Nils Wagner 20 Feb '08

20 Feb '08

This might be of interest. Nils From: Alan Hindmarsh <alanh(a)llnl.gov> Date: Wed, 6 Dec 2006 18:20:32 -0500 Subject: ZVODE, a Double Precision Complex ODE Solver Of the many solvers freely available for ODE initial value problems, there seem to be very few, if any, for the case of double precision complex dependent variables, even though there have been occasional user calls for this functionality. (Of course a complex system can be treated as a real system of twice the size, but direct treatment as a complex system is preferable.) I have provided such a solver: ZVODE. ZVODE is a straightforward modification of the Fortran ODE solver DVODE, for double precision real systems, making it part of a trio, SVODE/DVODE/ZVODE. ZVODE is available in two locations: (1) Netlib, in /ode (see file zvode.f), and (2) the LLNL CASC software site, www.llnl.gov/CASC/software.html (see VODE). The latter site also includes a demonstration program, zvdemo. Alan Hindmarsh Center for Applied Scientific Computing Lawrence Livermore National Laboratory

4 5

Timetable for 0.5.3 release?
by Nathan Bell 28 Jun '07

28 Jun '07

Is there a timetable for the next SciPy release? The last release was quite a while ago, so I think we're due :) I realize that releases are somewhat unimportant for much of the SciPy audience, since they'll go straight for the SVN version anyway. However, it's nice to tell casual users that they can apt-get XYZ and try your software. Personally, my code depends critically on the improvements to scipy.sparse made shortly after the last release, so I'm anxious to push this along. FWIW there are currently 15 items on the roadmap for 0.5.3: http://projects.scipy.org/scipy/scipy/roadmap -- Nathan Bell wnbell(a)gmail.com

7 8

Binary i/o package
by Erin Sheldon 06 Jun '07

06 Jun '07

Hi all - The tofile() and fromfile() methods are excellent for reading and writing arrays to disk, and there are good tools in scipy for ascii input/output. I often find myself writing huge binary files to disk and then wanting to extract particular rows and columns from that file. It is natural to associate the fields of a numpy array with the fields in the file, which may be inhomogeneous. The ability to extract this information is straightforward to code in C/C++ and brings the file close to a database in functionality without all the overhead of working with a full database or pytables. I have written a simple C++ numpy extension for reading binary data into a numpy array, with the ability to select rows and fields (columns). One enters the dtype that describes each row in list-of-tuples form and the code creates a numpy array (with perhaps a subset of the fields), reads in the requested data, and returns the result. Pretty simple. I feel like this is a pretty generic and useful type of operation, and if people agree I think it could go into the scipy io subpackage. The package is called readfields currently; it contains the readfields.so from the C++ code as well as simple_format.py which contains modules create files with a simple self-describing header and data written using tofile()) and a read function which parses the header and uses readfields to extract subsets of data. Anyone interested in trying it out can get the package here: http://sdss.physics.nyu.edu/esheldon/python/code/ Erin

3 5

Machine learning datasets (was Presentation of pymachine, a python package for machine learning)
by Bruce Southey 04 Jun '07

04 Jun '07

Hi, You might find the UCI Machine Learning Repository a useful resource for data: http://www.ics.uci.edu/~mlearn/MLRepository.html Standard sources are: Statlib: http://lib.stat.cmu.edu/ Netlib: http://www.netlib.org/ Even with those included with R may be used because some are in public domain. Regards Bruce On 5/14/07, Peter Skomoroch <peter.skomoroch(a)gmail.com> wrote: > This google search turns up more sources: > > http://www.google.com/search?q=data+%22in+the+public+domain%22+%22freely+by… > > > On 5/14/07, Peter Skomoroch <peter.skomoroch(a)gmail.com> wrote: > > With some digging, we should be able to find text, images, scientific > data, census info, and audio which is in the public domain. I see this a > lot: > > > > "The information on government web pages is in the public domain unless > specifically annotated otherwise (copyright may be held elsewhere) and may > therefore be used freely by the public." > > > > I'm still learning the ins and outs of licensing, but my understanding is > that data/information released as "public domain" can be bundled with > anything, i.e. BSD licenses. Does anyone have any insight into this? > > > > Here are a few starter sites which mention that the data they provide is > in the public domain: > > > > Geophysical data: > > > > http://www.ngdc.noaa.gov/ngdcinfo/onlineaccess.html > > > > Nasa images and measurements: > > > > > http://adc.gsfc.nasa.gov/adc/questions_feedback.html#policies1%22 > > > > Weather, forecasts: > > > > http://www.weather.gov/disclaimer.php > > > > Genomic data: > > > > > http://www.drugresearcher.com/news/ng.asp?id=10960-snp-database-goes > > > > > > -Pete > > > > > > On 5/14/07, David Cournapeau < david(a)ar.media.kyoto-u.ac.jp> wrote: > > > > > Peter Skomoroch wrote: > > > > I followed some of the discussion around datasets in the previous > > > > threads. As you mentioned, it might make sense to make some larger > > > > datasets available separately or as cran-style optional installs, but > > > > I think it would also be a big plus for scipy to have some more > > > > smaller built-in datasets of various types. > > > I agree, but there is the problem of licensing. I don't know what is the > > > status of data from a legal point of view: if I copy data from a book, I > > > guess this is copyrighted as the rest of the book. But then there are > > > some famous datasets (eg old faithful, iris, etc...) which are available > > > in different softwares with different licenses. > > > > > > Copying the datasets of R (in r-base) would be useful, but they fall > > > under the GPL, hence they cannot be included in scipy, at least if > > > datasets are also under the GPL. Unfortunately, I don't know the legal > > > details of those cases (status of data in a package licensed under the > GPL). > > > > > > Anyway, if I have some useful datasets, I will certainly make them in a > > > separate package, so that it can be used outside pymachine. > > > > > > David > > > _______________________________________________ > > > Scipy-dev mailing list > > > Scipy-dev(a)scipy.org > > > http://projects.scipy.org/mailman/listinfo/scipy-dev > > > > > > > > > > > > > -- > > Peter N. Skomoroch > > peter.skomoroch(a)gmail.com > > http://www.datawrangling.com > > > > -- > Peter N. Skomoroch > peter.skomoroch(a)gmail.com > http://www.datawrangling.com > _______________________________________________ > Scipy-dev mailing list > Scipy-dev(a)scipy.org > http://projects.scipy.org/mailman/listinfo/scipy-dev > >

6 11

Severe installation problems
by Nils Wagner 01 Jun '07

01 Jun '07

Hi all, I tried to install the latest svn of scipy but it failed.(SuSE Linux 10.0) python setup.py install non-existing path in 'scipy/cluster': 'tests' non-existing path in 'scipy/cluster': 'src/vq_wrap.cpp' mkl_info: libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE fftw3_info: FOUND: libraries = ['fftw3'] library_dirs = ['/usr/lib64'] define_macros = [('SCIPY_FFTW3_H', None)] include_dirs = ['/usr/include'] djbfft_info: NOT AVAILABLE non-existing path in 'scipy/fftpack': 'tests' could not resolve pattern in 'scipy/fftpack': 'dfftpack/*.f' non-existing path in 'scipy/fftpack': 'fftpack.pyf' non-existing path in 'scipy/fftpack': 'src/zfft.c' non-existing path in 'scipy/fftpack': 'src/drfft.c' non-existing path in 'scipy/fftpack': 'src/zrfft.c' non-existing path in 'scipy/fftpack': 'src/zfftnd.c' non-existing path in 'scipy/fftpack': 'src/zfft_djbfft.c' non-existing path in 'scipy/fftpack': 'src/zfft_fftpack.c' non-existing path in 'scipy/fftpack': 'src/zfft_fftw.c' non-existing path in 'scipy/fftpack': 'src/zfft_fftw3.c' non-existing path in 'scipy/fftpack': 'src/zfft_mkl.c' non-existing path in 'scipy/fftpack': 'convolve.pyf' non-existing path in 'scipy/fftpack': 'src/convolve.c' blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in /usr/local/lib libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib/atlas libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib NOT AVAILABLE atlas_blas_info: FOUND: libraries = ['f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] language = c include_dirs = ['/usr/local/include/atlas'] customize GnuFCompiler Found executable /usr/bin/g77 Found executable /usr/bin/g77 customize GnuFCompiler Found executable /usr/bin/g77 Found executable /usr/bin/g77 customize GnuFCompiler using config compiling '_configtest.c': /* This file is generated from numpy/distutils/system_info.py */ void ATL_buildinfo(void); int main(void) { ATL_buildinfo(); return 0; } C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/usr/local/lib/atlas -lf77blas -lcblas -latlas -o _configtest ATLAS version 3.7.11 built by root on Fri Mar 3 10:15:49 CET 2006: UNAME : Linux lisa 2.6.13-15.8-default #1 Tue Feb 7 11:07:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux INSTFLG : -1 1 MMDEF : ARCHDEF : F2CDEFS : -DAdd__ -DStringSunStyle CACHEEDGE: 393216 F77 : /usr/bin/g77, version GNU Fortran (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) F77FLAGS : -fomit-frame-pointer -O -m64 -fPIC CC : /usr/bin/gcc, version gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux) CC FLAGS : -fomit-frame-pointer -O -mfpmath=387 -m64 -fPIC MCC : /usr/bin/gcc, version gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux) MCCFLAGS : -fomit-frame-pointer -O -mfpmath=387 -m64 -fPIC success! removing: _configtest.c _configtest.o _configtest FOUND: libraries = ['f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] language = c define_macros = [('ATLAS_INFO', '"\\"3.7.11\\""')] include_dirs = ['/usr/local/include/atlas'] could not resolve pattern in 'scipy/integrate': 'linpack_lite/*.f' could not resolve pattern in 'scipy/integrate': 'mach/*.f' could not resolve pattern in 'scipy/integrate': 'quadpack/*.f' could not resolve pattern in 'scipy/integrate': 'odepack/*.f' non-existing path in 'scipy/integrate': '_quadpackmodule.c' non-existing path in 'scipy/integrate': '_odepackmodule.c' non-existing path in 'scipy/integrate': 'vode.pyf' non-existing path in 'scipy/integrate': 'tests' could not resolve pattern in 'scipy/interpolate': 'fitpack/*.f' non-existing path in 'scipy/interpolate': '_fitpackmodule.c' non-existing path in 'scipy/interpolate': 'fitpack.pyf' non-existing path in 'scipy/interpolate': 'tests' non-existing path in 'scipy/io': 'numpyiomodule.c' non-existing path in 'scipy/io': 'tests' non-existing path in 'scipy/io': 'examples' non-existing path in 'scipy/io': 'docs' ATLAS version 3.7.11 non-existing path in 'scipy/lib/blas': 'fblas.pyf.src' non-existing path in 'scipy/lib/blas': 'fblaswrap.f.src' could not resolve pattern in 'scipy/lib/blas': 'fblas_l?.pyf.src' non-existing path in 'scipy/lib/blas': 'cblas.pyf.src' could not resolve pattern in 'scipy/lib/blas': 'cblas_l?.pyf.src' non-existing path in 'scipy/lib/blas': 'tests' lapack_opt_info: lapack_mkl_info: NOT AVAILABLE atlas_threads_info: Setting PTATLAS=ATLAS libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib/atlas libraries lapack_atlas not found in /usr/local/lib/atlas libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries lapack_atlas not found in /usr/local/lib libraries ptf77blas,ptcblas,atlas not found in /usr/lib libraries lapack_atlas not found in /usr/lib numpy.distutils.system_info.atlas_threads_info NOT AVAILABLE atlas_info: libraries lapack_atlas not found in /usr/local/lib/atlas numpy.distutils.system_info.atlas_info FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] language = f77 include_dirs = ['/usr/local/include/atlas'] customize GnuFCompiler Found executable /usr/bin/g77 Found executable /usr/bin/g77 customize GnuFCompiler Found executable /usr/bin/g77 Found executable /usr/bin/g77 customize GnuFCompiler using config compiling '_configtest.c': /* This file is generated from numpy/distutils/system_info.py */ void ATL_buildinfo(void); int main(void) { ATL_buildinfo(); return 0; } C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -fPIC compile options: '-c' gcc: _configtest.c gcc -pthread _configtest.o -L/usr/local/lib/atlas -llapack -lf77blas -lcblas -latlas -o _configtest ATLAS version 3.7.11 built by root on Fri Mar 3 10:15:49 CET 2006: UNAME : Linux lisa 2.6.13-15.8-default #1 Tue Feb 7 11:07:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux INSTFLG : -1 1 MMDEF : ARCHDEF : F2CDEFS : -DAdd__ -DStringSunStyle CACHEEDGE: 393216 F77 : /usr/bin/g77, version GNU Fortran (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) F77FLAGS : -fomit-frame-pointer -O -m64 -fPIC CC : /usr/bin/gcc, version gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux) CC FLAGS : -fomit-frame-pointer -O -mfpmath=387 -m64 -fPIC MCC : /usr/bin/gcc, version gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux) MCCFLAGS : -fomit-frame-pointer -O -mfpmath=387 -m64 -fPIC success! removing: _configtest.c _configtest.o _configtest FOUND: libraries = ['lapack', 'f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/local/lib/atlas'] language = f77 define_macros = [('ATLAS_INFO', '"\\"3.7.11\\""')] include_dirs = ['/usr/local/include/atlas'] ATLAS version 3.7.11 non-existing path in 'scipy/lib/lapack': 'flapack.pyf.src' could not resolve pattern in 'scipy/lib/lapack': 'flapack_*.pyf.src' non-existing path in 'scipy/lib/lapack': 'clapack.pyf.src' non-existing path in 'scipy/lib/lapack': 'calc_lwork.f' non-existing path in 'scipy/lib/lapack': 'atlas_version.c' non-existing path in 'scipy/lib/lapack': 'tests' ATLAS version 3.7.11 non-existing path in 'scipy/linalg': 'src/fblaswrap.f' non-existing path in 'scipy/linalg': 'generic_fblas.pyf' non-existing path in 'scipy/linalg': 'generic_fblas1.pyf' non-existing path in 'scipy/linalg': 'generic_fblas2.pyf' non-existing path in 'scipy/linalg': 'generic_fblas3.pyf' non-existing path in 'scipy/linalg': 'interface_gen.py' non-existing path in 'scipy/linalg': 'generic_cblas.pyf' non-existing path in 'scipy/linalg': 'generic_cblas1.pyf' non-existing path in 'scipy/linalg': 'interface_gen.py' non-existing path in 'scipy/linalg': 'generic_flapack.pyf' non-existing path in 'scipy/linalg': 'flapack_user_routines.pyf' non-existing path in 'scipy/linalg': 'interface_gen.py' non-existing path in 'scipy/linalg': 'generic_clapack.pyf' non-existing path in 'scipy/linalg': 'interface_gen.py' non-existing path in 'scipy/linalg': 'src/det.f' non-existing path in 'scipy/linalg': 'src/lu.f' non-existing path in 'scipy/linalg': 'src/calc_lwork.f' non-existing path in 'scipy/linalg': 'atlas_version.c' non-existing path in 'scipy/linalg': 'iterative/STOPTEST2.f.src' non-existing path in 'scipy/linalg': 'iterative/getbreak.f.src' non-existing path in 'scipy/linalg': 'iterative/BiCGREVCOM.f.src' non-existing path in 'scipy/linalg': 'iterative/BiCGSTABREVCOM.f.src' non-existing path in 'scipy/linalg': 'iterative/CGREVCOM.f.src' non-existing path in 'scipy/linalg': 'iterative/CGSREVCOM.f.src' non-existing path in 'scipy/linalg': 'iterative/GMRESREVCOM.f.src' non-existing path in 'scipy/linalg': 'iterative/QMRREVCOM.f.src' non-existing path in 'scipy/linalg': 'iterative/_iterative.pyf.src' non-existing path in 'scipy/linalg': 'tests' non-existing path in 'scipy/linsolve': 'tests' could not resolve pattern in 'scipy/linsolve': 'SuperLU/SRC/*.c' non-existing path in 'scipy/linsolve': '_zsuperlumodule.c' non-existing path in 'scipy/linsolve': '_superlu_utils.c' non-existing path in 'scipy/linsolve': '_superluobject.c' non-existing path in 'scipy/linsolve': '_dsuperlumodule.c' non-existing path in 'scipy/linsolve': '_superlu_utils.c' non-existing path in 'scipy/linsolve': '_superluobject.c' non-existing path in 'scipy/linsolve': '_csuperlumodule.c' non-existing path in 'scipy/linsolve': '_superlu_utils.c' non-existing path in 'scipy/linsolve': '_superluobject.c' non-existing path in 'scipy/linsolve': '_ssuperlumodule.c' non-existing path in 'scipy/linsolve': '_superlu_utils.c' non-existing path in 'scipy/linsolve': '_superluobject.c' non-existing path in 'scipy/linsolve/umfpack': 'tests' umfpack_info: libraries umfpack not found in /usr/local/lib libraries umfpack not found in /usr/lib /usr/lib64/python2.4/site-packages/numpy/distutils/system_info.py:403: UserWarning: UMFPACK sparse solver (http://www.cise.ufl.edu/research/sparse/umfpack/) not found. Directories to search for the libraries can be specified in the numpy/distutils/site.cfg file (section [umfpack]) or by setting the UMFPACK environment variable. warnings.warn(self.notfounderror.__doc__) NOT AVAILABLE non-existing path in 'scipy/linsolve/umfpack': 'umfpack.i' non-existing path in 'scipy/linsolve/umfpack': 'umfpack.i' non-existing path in 'scipy/maxentropy': 'tests' non-existing path in 'scipy/maxentropy': 'examples' non-existing path in 'scipy/maxentropy': 'doc' non-existing path in 'scipy/misc': 'lena.dat' non-existing path in 'scipy/misc': 'tests' non-existing path in 'scipy/odr': 'odrpack/d_odr.f' non-existing path in 'scipy/odr': 'odrpack/d_mprec.f' non-existing path in 'scipy/odr': 'odrpack/dlunoc.f' non-existing path in 'scipy/odr': 'odrpack/d_lpk.f' non-existing path in 'scipy/odr': '__odrpack.c' non-existing path in 'scipy/odr': 'tests' could not resolve pattern in 'scipy/optimize': 'minpack/*f' non-existing path in 'scipy/optimize': '_minpackmodule.c' could not resolve pattern in 'scipy/optimize': 'Zeros/*.c' non-existing path in 'scipy/optimize': 'zeros.c' non-existing path in 'scipy/optimize': 'lbfgsb/lbfgsb.pyf' non-existing path in 'scipy/optimize': 'lbfgsb/routines.f' non-existing path in 'scipy/optimize': 'tnc/moduleTNC.c' non-existing path in 'scipy/optimize': 'tnc/tnc.c' non-existing path in 'scipy/optimize': 'cobyla/cobyla.pyf' non-existing path in 'scipy/optimize': 'cobyla/cobyla2.f' non-existing path in 'scipy/optimize': 'cobyla/trstlp.f' non-existing path in 'scipy/optimize': 'minpack2/minpack2.pyf' non-existing path in 'scipy/optimize': 'minpack2/dcsrch.f' non-existing path in 'scipy/optimize': 'minpack2/dcstep.f' non-existing path in 'scipy/optimize': 'tests' non-existing path in 'scipy/signal': 'tests' non-existing path in 'scipy/signal': 'sigtoolsmodule.c' non-existing path in 'scipy/signal': 'firfilter.c' non-existing path in 'scipy/signal': 'medianfilter.c' non-existing path in 'scipy/signal': 'sigtools.h' non-existing path in 'scipy/signal': 'splinemodule.c' non-existing path in 'scipy/signal': 'S_bspline_util.c' non-existing path in 'scipy/signal': 'D_bspline_util.c' non-existing path in 'scipy/signal': 'C_bspline_util.c' non-existing path in 'scipy/signal': 'Z_bspline_util.c' non-existing path in 'scipy/signal': 'bspline_util.c' non-existing path in 'scipy/sparse': 'tests' non-existing path in 'scipy/sparse': 'sparsetools/sparsetools.py' non-existing path in 'scipy/sparse': 'sparsetools/sparsetools_wrap.cxx' non-existing path in 'scipy/sparse': 'sparsetools' could not resolve pattern in 'scipy/special': 'c_misc/*.c' could not resolve pattern in 'scipy/special': 'cephes/*.c' could not resolve pattern in 'scipy/special': 'mach/*.f' could not resolve pattern in 'scipy/special': 'amos/*.f' could not resolve pattern in 'scipy/special': 'toms/*.f' could not resolve pattern in 'scipy/special': 'cdflib/*.f' could not resolve pattern in 'scipy/special': 'specfun/*.f' non-existing path in 'scipy/special': '_cephesmodule.c' non-existing path in 'scipy/special': 'amos_wrappers.c' non-existing path in 'scipy/special': 'specfun_wrappers.c' non-existing path in 'scipy/special': 'toms_wrappers.c' non-existing path in 'scipy/special': 'cdf_wrappers.c' non-existing path in 'scipy/special': 'ufunc_extras.c' non-existing path in 'scipy/special': 'specfun.pyf' non-existing path in 'scipy/special': 'tests' non-existing path in 'scipy/stats': 'tests' could not resolve pattern in 'scipy/stats': 'statlib/*.f' non-existing path in 'scipy/stats': 'statlib.pyf' non-existing path in 'scipy/stats': 'futil.f' non-existing path in 'scipy/stats': 'mvn.pyf' non-existing path in 'scipy/stats': 'mvndst.f' non-existing path in 'scipy/ndimage': 'src/nd_image.c' non-existing path in 'scipy/ndimage': 'src/ni_filters.c' non-existing path in 'scipy/ndimage': 'src/ni_fourier.c' non-existing path in 'scipy/ndimage': 'src/ni_interpolation.c' non-existing path in 'scipy/ndimage': 'src/ni_measure.c' non-existing path in 'scipy/ndimage': 'src/ni_morphology.c' non-existing path in 'scipy/ndimage': 'src/ni_support.c' non-existing path in 'scipy/ndimage': 'src' non-existing path in 'scipy/ndimage': 'tests' non-existing path in 'scipy/stsci/convolve': 'src/_correlatemodule.c' non-existing path in 'scipy/stsci/convolve': 'src/_lineshapemodule.c' non-existing path in 'scipy/stsci/image': 'src/_combinemodule.c' non-existing path in 'scipy/weave': 'tests' non-existing path in 'scipy/weave': 'scxx' non-existing path in 'scipy/weave': 'blitz/blitz' non-existing path in 'scipy/weave': 'doc' non-existing path in 'scipy/weave': 'examples' Warning: Subpackage 'Lib' configuration returned as 'scipy' running install running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src building py_modules sources creating build creating build/src.linux-x86_64-2.4 creating build/src.linux-x86_64-2.4/scipy building library "dfftpack" sources building library "linpack_lite" sources building library "mach" sources building library "quadpack" sources building library "odepack" sources building library "fitpack" sources building library "superlu_src" sources building library "odrpack" sources building library "minpack" sources building library "rootfind" sources building library "c_misc" sources building library "cephes" sources building library "mach" sources building library "toms" sources building library "amos" sources building library "cdf" sources building library "specfun" sources building library "statlib" sources building extension "scipy.cluster._vq" sources building extension "scipy.fftpack._fftpack" sources target build/src.linux-x86_64-2.4/_fftpackmodule.c does not exist: Assuming _fftpackmodule.c was generated with "build_src --inplace" command. error: '_fftpackmodule.c' missing Any pointer ? Nils

3 5

Make numpy.distutils work with python 2.5 + cygwin
by Ravikiran Rajagopal 31 May '07

31 May '07

Hi, I am trying to compile numpy with python 2.5.1 under cygwin and ran into the following issue. I cannot convince numpy.distutils to tell distutils that I am using cygwin. Using the switch "--compiler=ming32" with both 'config' and 'build' options of setup.py, I end up with an error from distutils (not numpy.distutils) that python was built with Visual Studio 2003 and asking me to pass "-c ming32" to setup.py. What magic incantation do I need to convince distutils+numpy.distutils to accept my cygwin compilers? Regards, Ravi

3 10

Problem compiling/installing/using arpack Please advise
by Jeremy Conlin 31 May '07

31 May '07

I am trying to use arpack, found in the scipy sandbox. It appears to compile/install fine, but I get an error (shown below) when I try to import arpack. I know there has been some discussion lately on Trac about this module. I'm hoping someone can help me figure out what is wrong and how I can use this. I am running python2.5 and I just updated my scipy from the svn repository. Thanks, Jeremy $ python Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import arpack Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/arpack/__init__.py", line 2, in <module> from arpack import * File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/arpack/arpack.py", line 9, in <module> import _arpack ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/arpack/_arpack.so, 2): Symbol not found: _etime_ Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/arpack/_arpack.so Expected in: dynamic lookup >>>

2 2

LAPACK issue
by Nils Wagner 31 May '07

31 May '07

Hi all, scipy.test() has some failures which seem to be related to the new LAPACK version http://www.netlib.org/lapack/lapack-3.1.1.changes ====================================================================== FAIL: check_syevr (scipy.lib.tests.test_lapack.test_flapack_float) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/scipy/lib/lapack/tests/esv_tests.py", line 41, in check_syevr assert_array_almost_equal(w,exact_w) File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 230, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 215, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 33.3333333333%) x: array([-0.66992444, 0.48769474, 9.18222618], dtype=float32) y: array([-0.66992434, 0.48769389, 9.18223045]) ====================================================================== FAIL: check_syevr_irange (scipy.lib.tests.test_lapack.test_flapack_float) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/scipy/lib/lapack/tests/esv_tests.py", line 66, in check_syevr_irange assert_array_almost_equal(w,exact_w[rslice]) File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 230, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 215, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 33.3333333333%) x: array([-0.66992444, 0.48769474, 9.18222618], dtype=float32) y: array([-0.66992434, 0.48769389, 9.18223045]) ====================================================================== FAIL: Solve: single precision complex ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/scipy/linsolve/umfpack/tests/test_umfpack.py", line 32, in check_solve_complex_without_umfpack assert_array_almost_equal(a*x, b) File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 230, in assert_array_almost_equal header='Arrays are not almost equal') File "/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", line 215, in assert_array_compare assert cond, msg AssertionError: Arrays are not almost equal (mismatch 20.0%) x: array([ 1. +0.j, 1.99999809+0.j, 3. +0.j, 4.00000048+0.j, 5. +0.j], dtype=complex64) y: array([1, 2, 3, 4, 5]) ---------------------------------------------------------------------- These failures are not present in case of LAPACK 3.0. Any comment ? Nils

1 0

SciPy Journal
by Travis Oliphant 31 May '07

31 May '07

Hi everybody, I'm sorry for the cross posting, but I wanted to reach a wide audience and I know not everybody subscribes to all the lists. I've been thinking more about the "SciPy Journal" that we discussed before and I have some thoughts. 1) I'd like to get it going so that we can push out an electronic issue after the SciPy conference (in September) 2) I think it's scope should be limited to papers that describe algorithms and code that are in NumPy / SciPy / SciKits. Perhaps we could also accept papers that describe code that depends on NumPy / SciPy that is also easily available. 3) I'd like to make a requirement for inclusion of new code in SciPy that it have an associated journal article describing the algorithms, design approach, etc. I don't see this journal article as being user-interface documentation for the code. I see this is as a place to describe why the code is organized as it is and to detail any algorithms that are used. 4) The purpose of the journal as I see it is to a) provide someplace to document what is actually done in SciPy and related software. b) provide a teaching tool of numerical methods with actual "people use-it" code that would be useful to researchers, students, and professionals. c) hopefully clever new algorithms will be developed for SciPy by people using Python that could be show-cased here d) provide a peer-review publication opportunity for people who contribute to open-source software 5) We obviously need associate editors and people willing to review submitted articles as well as people willing to submit articles. I have two articles that can be submitted within the next two months. What do other people have? As an example of the kind of thing a SciPy Journal would be useful for. I have recently over-hauled the interpolation.py file for SciPy by incorporating the B-spline stuff that is partly in fitpack. In the process I noticed two things: 1) I have (what seems to me) a different recursive algorithm for calculating derivatives of B-splines than I could find in fitpack. 2) I have developed a different way to determine the K-1 extra degrees of freedom for Kth-order spline fitting than I have seen before. The SciPy Journal would be a great place to document both of these things while describing the spline interpolation design of scipy.interpolate It is true that I could submit this stuff to other journals, but it seems like that doing that makes the information harder to find in the future and not easier. I'm also dissatisfied with how information exclusionary academic journals seem to be. They are catching up, but they are still not as accessible as other things available on the internet. Given the open nature of most scientific research, it is remarkable that getting access to the information is not as easy as it should be with modern search engines (if your internet domain does not subscribe to the e-journal). Comments and feedback is welcome. -Travis

1 0