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

Status of sandbox.spline and my other code.
by John Travers 07 Apr '08

07 Apr '08

Hi all, This email is intended to clarify the status of various bits of code I've committed/not committed so I don't leave too much of a mess after me. I'm about to start writing my PhD thesis, so I'll be too busy to work on scipy until September. 1. sandbox.spline stuff The module here was supposed to be a tidy up of scipy.interpolate. All of the dierkx functionality has been moved to f2py wrappers, which I think makes maintenance easier. However, it does not add any new functionality, and in retrospect appears to have been a waste of my time. So I'll leave to you to decide if you want to integrate it into scipy.interpolate or not; though it was originaly planned to be a seperate module to clear up the ambiguity between interpolation and smoothing spline functionality. However I have added 20 unit tests to the code (most of which simply check the wrapper against the pure fortran output, but still useful I think) which could easily be moved over to the current scipy.interpolate module. 2. Radial basis function module in sandbox (rbf) This code has recently had attention from Robert Hetland and is quite improved. I'm not sure if I will ever go into scipy though?? If not, I will put it into a scikit at some point. Related to this, the wiki page has been updated, however, it is at http://www.scipy.org/RadialBasisFunctions but should probably be in the Cookbook. I don't know how to move it over, so some pointers would be helpful. In addition there are four unused attachments I uploaded that could be deleted. 3. Boundary value ODE solver (BVP_SOLVER) I have fairly functional code interfacing to some very good BVP solver code (http://cs.smu.ca/~muir/BVP_SOLVER_Webpage.shtml). The license is good for scipy (as confirmed by the authors), but the code if fortran 95 - therefore cannot apparently go into scipy. I'll make a scikit when I get time (probably September). 4. An interface to the pikaia genetic algorithm routine I have a python interface to pikaia fortran code for genetic algorithm optimisation of real valued functions (http://www.hao.ucar.edu/Public/models/pikaia/pikaia.html). The fortran code itself is robust and highly optimised for numerical work, though it is nowhere near as general as the sandbox.ga module. I think it is useful to go in scipy.optimization alongside the annealing module. If people disagree I'll make it into a scikit. I hope this clears a few things up. Best regards, John Travers

4 4

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

19 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

ndimage problems
by Christopher Hanley 10 Oct '07

10 Oct '07

Hi, We have found two problems with ndimage. I have filed a ticket #455 on the scipy trac page. The first problem can be seen with this example: > import numpy as n > from scipy import ndimage as nd > a = n.ones((10,5),dtype=n.float32) * 12.3 > x = nd.rotate(a,90.0) > x Out[17]: array([[ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 0. , 0. ], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019], [ 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019, 12.30000019]], dtype=float32) }}} Notice that the last two entries of the first row are now 0. The second problem has to do with the reversing of byte order if you have big-endian data on a little endian machine. Please see the example below: >>> a = N.ones ((2,3), dtype=N.float32) * 12.3 >>> a = a.byteswap() >>> a.dtype = a.dtype.newbyteorder (">") >>> print a [[ 12.30000019 12.30000019 12.30000019] [ 12.30000019 12.30000019 12.30000019]] >>> print ndimage.rotate (a, 90.) [[ 0.00000000e+00 -4.28378144e+08] [ 0.00000000e+00 -4.28378144e+08] [ -4.28378144e+08 -4.28378144e+08]] I have taken a look at the ndimage python code and cannot find any explicit calls to byteswap. I'm guessing something is funny in one of the c-api calls. I haven't been able to track it down yet. Chris

2 3

Documentation to SciPy
by Ondrej Certik 01 Sep '07

01 Sep '07

Hi, I would like to rise the quesiton of documentation again, because I find it really confusing. 4 months ago I created http://scipy.org/DocumentationNew That is intended as a replacement for http://scipy.org/Documentation. It should probably be updated to reflect the current state of the documentation. Also a question to Dmitrey - is there some place with a documentation to your new module? I believe it could go to this page: http://scipy.org/SciPy_packages Note: I myself also only put the documentation to the nonlin module inside the code. Once we agree on some way of documenting things, I'll update the documentation on the wiki. Ondrej

4 4

0.6.x branch created
by Jarrod Millman 01 Sep '07

01 Sep '07

Hello, Thanks for all the work getting the trunk in shape for the 0.6.x branch: http://svn.scipy.org/svn/scipy/branches/0.6.x There are a few small changes I still want to make and I will need to ask everyone to test it before making the 0.6.0 tag and release. The version of the trunk has been updated to reflect the fact that all development on it will be in preparation for the 0.7.0 release in about 3 months. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

4 4

ticket 401
by Jarrod Millman 30 Aug '07

30 Aug '07

Hello, I can't reproduce this problem: http://projects.scipy.org/scipy/scipy/ticket/401 Neither could David Cournapeau. So unless someone tells me otherwise I am going to mark it closed tomorrow. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

1 0

SciPy trunk has references to ParametricTestCase
by Jarrod Millman 30 Aug '07

30 Aug '07

Hello, I noticed that a few references to ParametricTestCase have made it into the SciPy trunk: scipy/sparse/tests/test_sparse.py: ParametricTestCase): scipy/misc/tests/test_pilutil.py:class test_pilutil(ParametricTestCase): ParametricTestCase was only recently added to the NumPy: http://projects.scipy.org/scipy/numpy/changeset/3976/trunk/numpy/testing/pa… So should we remove these references just from the tag (which I will make very soon, I promise) or should we remove them from the trunk (at least until a new release of NumPy is made)? -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/

2 2

about optimization funcs
by dmitrey 29 Aug '07

29 Aug '07

hi all, don't you mind if I will add a single line in scipy.optimize fmin_tnc and lbfgsb docstrings that these solvers are also available (with other, unified call syntax) in scikits.openopt (provided scipy is installed)? (briefly for those who don't familiar with scikits.openopt yet: it looks like prob = scikits.openopt.NLP(fun, x0, **kwargs), for example NLP(fun, x0, iprint = 100, xtol = 1e-4, doPlot = 1, maxIter = 1000, maxCPUTime = 100,...) r = prob.solve('scipy_tnc') or r = prob.solve('scipy_lbfgsb') or 'lincher' or 'ralg'(this one for uc only for now) or p = QP(...) or LP(...), NSP(...) for nonsmooth, MILP for mixed-integer LP ) The line should be something like "also you can call the solver from scikits using unified openopt syntax" or "alternatively you can call the solver from scikits using unified openopt syntax" you can correct the line because I'm not skilled in English very well. If noone will mind then probably I will add the line, so what do you think? Regards, D.

2 1

svn server still doesn't work?
by dmitrey 29 Aug '07

29 Aug '07

hi all, does svn server not work only for me or for all as well? does anyone know when it will be fixed? ~/install/scipy/Lib/optimize$ svn ci optimize.py svn: Commit failed (details follow): svn: PROPFIND request failed on '/svn/scipy/trunk/Lib/optimize' svn: '/svn/scipy/trunk/Lib/optimize' path not found svn: Your commit message was left in a temporary file: svn: '/home/dmitrey/install/scipy/Lib/optimize/svn-commit.tmp' Regards, D.

3 4