Mailman 3 July 2006 - SciPy-Dev

Question about Kaiser Implementation in firwin
by Buehler, Eric (AGRE) Oct. 4, 2008

Oct. 4, 2008

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

netcdf module with ctypes
by Jonathan Taylor July 28, 2006

July 28, 2006

I have been playing around with ctypes to see how they work and have written a fairly complete netcdf module (with some tests + doctests) in pure python. The reason I wrote this one is that I have a specific subclass of netcdf files I want to work with and couldn't get the sandbox.netcdf package to behave exactly as I wanted it to. By default, I read variables into temporary memmap'ed array files because some of the data files I use are quite large. This could be customized, though of course. Wondering if it is of any interest to anyone, Jonathan -- ------------------------------------------------------------------------ Jonathan Taylor Tel: 650.723.9230 Dept. of Statistics Fax: 650.725.8977 Sequoia Hall, 137 www-stat.stanford.edu/~jtaylo 390 Serra Mall Stanford, CA 94305

2 2

Ticket 223
by Nils Wagner July 28, 2006

July 28, 2006

Dear developers, Please can you look into my bugreport http://projects.scipy.org/scipy/scipy/ticket/223 I'm really sorry for annoying you but I want to know the reason for this bug. Thanks in advance Nils P.S: Before I recompile ATLAS I would like to know if it is really an ATLAS issue...

1 0

building numpy-1.0b1 on linux x86_64
by Neal Becker July 27, 2006

July 27, 2006

I'm trying to make a rpm for fedora 5 (x86_64). lapack and blas are in /usr/lib64. I've used this in the past: env CFLAGS="$RPM_OPT_FLAGS" BLAS=%{_libdir} LAPACK=%{_libdir} python setup.py config_fc --fcompiler=gnu95 build That is, pass BLAS and LAPACK in env during build. I noticed comments about site.cfg. I wonder if it would be better to specify BLAS, LAPACK there? Also, does it matter whether I do the same during install? BLAS=%{_libdir} LAPACK=%{_libdir} python setup.py config_fc --fcompiler=gnu95 install --root=$RPM_BUILD_ROOT

1 0

Weave support for recent SWIG releases (patch)
by Prabhu Ramachandran July 26, 2006

July 26, 2006

Hi, I've submitted a ticket and patch to get weave working with SWIG (from CVS) wrapped objects. Versions of SWIG before 1.3.28 should continue to work. The patch and ticket are available here: http://projects.scipy.org/scipy/scipy/ticket/235 Could someone please take a look and apply the patch. Thanks. cheers, prabhu

2 2

Moving stsci into the main scipy library
by Travis Oliphant July 26, 2006

July 26, 2006

I'd like to propose moving the stsci package (which contains the convolve and image sub-packages from numarray) into SciPy from the sandbox. These packages duplicate some of the features available in other packages and a better solution might be to merge the functionality into other packages. However, this will take work and time. Right now, my main concern is giving numarray users who depended on those packages an immediate working mechanism for using them. The ndimage package is already in SciPy. Creating an stsci package will allow numarray converts to install scipy to get access to their familiar code. Users not afraid of a compile could check-out just these packages and install them. Users who rely on binary installations will want the stsci package to get built and that means it needs to be in the main library. -Travis

1 0

Next SciPy release
by Ed Schofield July 25, 2006

July 25, 2006

Hi all, I'd like to make a new SciPy release early next week to sync with NumPy 1.0b1. It would have been nice to release SciPy 0.5.0 to coincide with NumPy 1.0 (final), but I suppose the next release should be numbered 0.5.0, following Andrew Straw's suggestion in http://projects.scipy.org/scipy/numpy/ticket/170. We have a growing list of outstanding tickets. I'll go through these, but I'd appreciate any help here ;) -- Ed

5 7

What is this dispatch thing ?
by David Huard July 21, 2006

July 21, 2006

Hi, I just updated scipy from svn and stats.linregress(x,y) returns /usr/lib/python2.4/site-packages/stats.py in __call__(self, arg1, *args, **kw) 244 def __call__(self, arg1, *args, **kw): 245 if type(arg1) not in self._types: --> 246 raise TypeError, "don't know how to dispatch %s arguments" % type(arg1) 247 return apply(self._dispatch[type(arg1)], (arg1,) + args, kw) 248 TypeError: don't know how to dispatch <type 'numpy.ndarray'> arguments Also, in ipython, linregress? returns a doc about the dispatch class. Is this intended ? David

2 2

Unit Tests for Probabilistic Functions
by Dennis V. Perepelitsa July 21, 2006

July 21, 2006

Hi, all. I'm in the process of writing unit tests for a hidden markov model module I've been hacking on. I want to ensure that my implementation generates sequences of hidden and observed states with the correct probabilities. How can I test for this? More generally, what are some good methods to use when writing unit tests for probabilistic functions? Can we do any better than "run it a bunch of times and make sure the true mean is within a 98% (or higher/lower) confidence interval of the sample mean"? I'd rather not devise a unit test that is guaranteed to fail 2% of the time. Dennis V. Perepelitsa Picower Institute for Learning and Memory MIT, Class of 2008 - Course VIII, XVIII

1 0

Cobyla test fixed
by Travis E. Oliphant July 17, 2006

July 17, 2006

I think we tracked down the problem in cobyla. Apparently, a certain operation deep in the bowels of the Fortran code was causing a number to be very-small negative on 32-bit platforms but 0.0d0 on 64-bit platforms. Different behavior occurred based on whether or not the number was less than zero or not. On 32-bit platforms the different behavior ensued on 64-bit platforms it did not. I changed the code in cobyla/trstlp.f so that it checks for a number that is less than eps currently eps is hard-coded to -2.2e-16 but this is a hack. But, the hack works and allows all scipy tests to pass on 32-bit systems (and hopefully 64-bit systems as well). There are a lot more print statements in the code now, but they are all embedded in a test for iprint to be equal to 3 so they don't run by default (the tests will cause the code to run very slightly slower, however). Thanks to those with 64-bit systems who helped in debugging. -Travis

1 0