Mailman 3 August 2006 - 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

ImportError: Inappropriate file type for dynamic loading
by Michael McNeil Forbes 31 Aug '06

31 Aug '06

I am having some problems with scipy on an Intel Mac. It built and installed fine, but when I try to load various components, I get the following error messages: ---------------------------------------- Python 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import scipy Overwriting info=<function info at 0x12b3270> from scipy.misc (was <function info at 0x1288930> from numpy.lib.utils) >>> import scipy.interpolate Traceback (most recent call last): File "<stdin>", line 1, in ? File "/data/apps/python//lib/python/scipy/interpolate/__init__.py", line 7, in ? from interpolate import * File "/data/apps/python//lib/python/scipy/interpolate/interpolate.py", line 13, in ? import fitpack File "/data/apps/python//lib/python/scipy/interpolate/fitpack.py", line 34, in ? import _fitpack ImportError: Inappropriate file type for dynamic loading >>> ---------------------------------------- It seems that python is having difficulty loading libraries derived from fortran/c sources, but I am having a very difficult time trying to figure out why or how to fix this. I was having some issues earlier with numpy extensions, but was able to get numpy to build an install cleanly after ensuring that there were no spurious libraries around (I have installed some previously pre-compiled version of numpy and scipy that worked fine). I have verified that the appropriate file _fitpack.so in this case is being regenerated, but it still cannot be loaded. I was hoping I could see exactly how it was generated, but this information seems to be hidden deep within the distribution utilities and I do not know how to explore this easily. I am having related problems when trying to use f2py to generate simple fortran modules, so I suspect that something is messed up with my fortran compiler, but the compiler seems to work (the library is generated...) Any suggestions about how I can try to diagnose and fix this problem? Michael.

2 1

Bug in scipy.special.exp1
by Patrick Perry 30 Aug '06

30 Aug '06

The following code should demonstrate the problem: >>> special.exp1(-1) nan >>> special.exp1(complex(-1)) (-1.8951178163559368-3.1415926535897931j) I'm not sure why the explicit cast to complex is necessary. Also, I barely know anything about exponential integrals, but I think it should be the case that Ei(z) = -E1(-z). Even though E1(z) may only be defined modulo multiples of pi when z is complex, it might make sense to have "special.expi(x)" return the same value as "-special.exp1(-x)" when x is real. This is not the current behavior: >>> special.expi(1) 1.8951178163559368

1 0

Re: [SciPy-dev] fftfreq very slow; rfftfreq incorrect?
by Andrew Jaffe 30 Aug '06

30 Aug '06

Stefan van der Walt wrote: > On Wed, Aug 30, 2006 at 12:04:22PM +0100, Andrew Jaffe wrote: >> the current implementation of fftfreq (which is meant to return the >> appropriate frequencies for an FFT) does the following: >> >> k = range(0,(n-1)/2+1)+range(-(n/2),0) >> return array(k,'d')/(n*d) >> >> I have tried this with very long (2**24) arrays, and it is ridiculously >> slow. Should this instead use arange (or linspace?) and concatenate >> rather than converting the above list? This seems to result in >> acceptable performance, but we could also perhaps even pre-allocate the >> space. > > Please try the attached benchmark. Results attached. Bottom line is that both new versions are several times faster than the old, and the concat (hstack) version is somewhat faster than the other, but it depends on n. I'm on OSX with the 2.4.3 universal build on PPC and the latest SVN numpy. >> The numpy.fft.rfftfreq seems just plain incorrect to me. It seems to >> produce lots of duplicated frequencies, contrary to the actual output of >> rfft: << removed >> > Please produce a code snippet to demonstrate the problem. We can then > fix the bug and use your code as a unit test. Aha, the problem is that scipy and numpy define rfft differently! numpy returns n/2+1 complex numbers (so the first and last numbers are actually real) with the frequencies equivalent to the positive part of the fftfreq, whereas scipy returns n real numbers with the frequencies as in rfftfreq. I think the numpy behavior makes more sense, as it doesn't require any unpacking after the fact, at the expense of a tiny amount of wasted space. But would this in fact require scipy doing extra work from whatever the 'native' real_fft (fftw, I assume) produces? Anyone else have an opinion?

1 0

import misc -> failed: cannot import name place
by Darren Dale 28 Aug '06

28 Aug '06

Just a heads up, with numpy 1.0b5.dev3084 and scipy 0.5.0.2180, I get the following error when I so from scipy import *: import misc -> failed: cannot import name place --------------------------------------------------------------------------- exceptions.ImportError Traceback (most recent call last) /home/darren/<ipython console> /usr/lib64/python2.4/site-packages/scipy/signal/__init__.py 6 7 import sigtools ----> 8 from waveforms import * 9 from bsplines import * 10 from filter_design import * /usr/lib64/python2.4/site-packages/scipy/signal/waveforms.py 4 # 2003 5 ----> 6 from numpy import asarray, zeros, place, nan, mod, pi, extract, log, sqrt, \ 7 exp, cos, sin, size, polyval, polyint, log10 8 ImportError: cannot import name place

2 1

numpy-1.0b4 build failure
by Neal Becker 28 Aug '06

28 Aug '06

Any hints? running install_data [...] creating /var/tmp/rpm/numpy-1.0b4-1-root-nbecker/usr/lib64/python2.4/site-packages/numpy/numarray/numpy error: can't copy 'numpy/numarray/numpy/': doesn't exist or not a regular file error: Bad exit status from /var/tmp/rpm/rpm-tmp.82145 (%install)

1 0

scipy.fft module slow for complex inputs when linked to fftw3
by David Cournapeau 28 Aug '06

28 Aug '06

Hi there, I noticed recently that when using the fft module of scipy, it is much slower (5-10 folds) than numpy for complex inputs (only in the 1d case) when linking to fftw3. This problem is reported on the ticket #1 for scipy : http://projects.scipy.org/scipy/scipy/ticket/1 I am not sure, because the code is a bit difficult to read, but it looks like in the case of complex input + fftw3, the plan is always recomputed for each call to zfft (file:zfft.c), whereas in the real case or in the complexe case + fftw2, the function drfft(file:drfft.c), called from zrfft (file:zrfft.c) is calling a plan which is cached. I am trying to see how the caching is done, but I am not sure I will have the time to make it work for fftw3. David P.S: I am wondering if there is a reason why the code is written with all those #ifdef ? Because it makes the hacking of the module quite difficult. Why not implementing each function for each fft library, and wraps them around in the header files ? Is is just a time constraint, or is there another reason ?

3 9

prefered way to submit code, patch, new module to scipy/numpy ?
by David Cournapeau 20 Aug '06

20 Aug '06

hello, I tried to find some doc on scipy wiki regarding how to submit patches, new code to scipy or numpy, buyt couldn't find so. Is there a recommended way to do so ? For new modules or new code in existing modules, is there a kind of reviewing process ? David

1 0

Re: [SciPy-dev] Mac OS X and gcc 4.2
by Bill Northcott 18 Aug '06

18 Aug '06

On 18/08/2006, at 3:00 AM, Chris Kees wrote: > having trouble even building the trunk of numpy and scipy on Mac > OS X using a recent build of gcc (version 4.2.0 20060710) . Why use such a bleeding edge compiler? The FSF compilers don't even work very well on Darwin, which is only of secondary interest to the FSF developers. OTOH Apple incorporate a number of Darwin optimisations into their code which does not reach the FSF sources until later if at all. Even worse current Apple compilers are based on gcc-4.0.x so a lot of Apple stuff will be in FSF 4.0.3 but none of it in 4.2 which is very different. You can use the standard Apple compilers with a Fortran from hpc.sourceforge.net. Or just get the current R 2.3.1 binary package which includes gcc-4.0.3 with gfortran. Although this appears to be built from FSF sources it is universal and can target i386, ppc and ppc64. > errors with gcc 4.2: > > ... > gcc: _configtest.c > gcc: unrecognized option '-no-cpp-precomp' > cc1: error: unrecognized command line option "-arch" > cc1: error: unrecognized command line option "-arch" > cc1: error: unrecognized command line option "-Wno-long-double" As others have observed the problem is the configure script. As the autoconf macro guidelines make clear one should test for features not software versions. The script clearly tests for Darwin and assumes an Apple compiler. The options causing the errors are all Apple specific. I think the -no-cpp-precomp option is now redundant, -arch is only necessary if you are trying to target a different architecture to the build host. I am surprised it is used at all. While -Wno-long- double is sort of important. The size of long doubles has changed recently on Darwin so it is useful to now if you have them in your code. Bill Northcott

3 2

Mac OS X and gcc 4.2
by Chris Kees 17 Aug '06

17 Aug '06

Good Afternoon, I'm trying to port a set of finite element tools and linear/ nonlinear multilevel solvers to the new numpy and scipy. I'm having trouble even building the trunk of numpy and scipy on Mac OS X using a recent build of gcc (version 4.2.0 20060710) . Is it pointless for me to even try using something besides apple's gcc 3.3? I'm just getting simple unrecognized option errors, but I don't know how to modify the configuration to get rid of them or ignore them. Could anyone give me some pointers here? Thanks, Chris errors with gcc 4.2: ... gcc: _configtest.c gcc: unrecognized option '-no-cpp-precomp' cc1: error: unrecognized command line option "-arch" cc1: error: unrecognized command line option "-arch" cc1: error: unrecognized command line option "-Wno-long-double" gcc: unrecognized option '-no-cpp-precomp' cc1: error: unrecognized command line option "-arch" cc1: error: unrecognized command line option "-arch" cc1: error: unrecognized command line option "-Wno-long-double" failure. removing: _configtest.c _configtest.o ...

2 4