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

weave not supporting other compilers than gnu ?
by Matthieu Brucher 13 Nov '07

13 Nov '07

Hi, I'm trying to get a simple code to work with weave, the blitz converter and ICC, but it seems that only the gnu headers are included in the repository. This means that weave cannot be used with something else than GCC, which is not what is said in the tutorial (BTW, it is outdated, and the examples are as well :()) Is there a reason why those headers are not available ? Matthieu

1 1

python2.3 and scipy
by Nils Wagner 30 Oct '07

30 Oct '07

Hi all, I get some warnings and errors with recent svn and python2.3 e.g. Warning: FAILURE importing tests for <module 'scipy.io.mio' from '...site-packages/scipy/io/mio.pyc'> /data/home/nwagner/local/lib64/python2.3/site-packages/scipy/io/tests/test_mio.py:235: ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() (in TestMIOArray) Warning: FAILURE importing tests for <module 'scipy.misc.pilutil' from '...ackages/scipy/misc/pilutil.pyc'> /data/home/nwagner/local/lib64/python2.3/site-packages/numpy/testing/numpytest.py:389: SyntaxError: invalid syntax (test_pilutil.py, line 38) (in _get_module_tests) ERROR: test_factor1 (scipy.stats.models.tests.test_formula.TestFormula) ---------------------------------------------------------------------- Traceback (most recent call last): File "/data/home/nwagner/local/lib64/python2.3/site-packages/scipy/stats/models/tests/test_formula.py", line 190, in test_factor1 fac = formula.Factor('ff', set(f)) NameError: global name 'set' is not defined However I cannot reproduce them with python2.5. Any comments ? Nils

1 0

Setting up your editor for NumPy/SciPy
by Stefan van der Walt 30 Oct '07

30 Oct '07

Hi all, Since we are busy cleaning up the NumPy and SciPy sources, I'd like to draw your attention to the guidelines regarding whitespace. We use 4 spaces per indentation level, in Python and C code alike (see PEP 7: http://www.python.org/dev/peps/pep-0007/ under the heading Python 3000). Lines should be a maximum of 79 characters long (to facilitate reading in text terminals), and must not have trailing whitespace. PEP 8 (http://www.python.org/dev/peps/pep-0008/) states: """ The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. If necessary, you can add an extra pair of parentheses around an expression, but sometimes using a backslash looks better. Make sure to indent the continued line appropriately. """ I attach a file, containing some common errors, which you can use to setup your editor. I also attach the settings I use under Emacs to highlight the problems. Regards Stéfan

3 3

Scipy Logos
by Olivier Verdier 28 Oct '07

28 Oct '07

Hi! Are there any scipy logos somewhere? I came across some scipy logos on the first page of scipy.org but nothing else. Could someone point me to a page where the scipy logos are? Then I think it would be a good idea to add those logos on the scipy.org site. thanks! == Olivier

1 0

Bug in sparse.py
by Nils Wagner 27 Oct '07

27 Oct '07

Nathan, scipy.test(1) reveals a bug in sparse.py (recent svn) ====================================================================== ERROR: check loadmat case sparse ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib64/python2.5/site-packages/scipy/io/tests/test_mio.py", line 84, in cc self._check_case(name, files, expected) File "/usr/local/lib64/python2.5/site-packages/scipy/io/tests/test_mio.py", line 74, in _check_case matdict = loadmat(file_name) File "/usr/local/lib64/python2.5/site-packages/scipy/io/mio.py", line 96, in loadmat matfile_dict = MR.get_variables() File "/usr/local/lib64/python2.5/site-packages/scipy/io/miobase.py", line 277, in get_variables res = getter.get_array() File "/usr/local/lib64/python2.5/site-packages/scipy/io/miobase.py", line 317, in get_array arr = self.get_raw_array() File "/usr/local/lib64/python2.5/site-packages/scipy/io/mio4.py", line 174, in get_raw_array return scipy.sparse.csc_matrix((vals,ij), dims) File "/usr/local/lib64/python2.5/site-packages/scipy/sparse/sparse.py", line 937, in __init__ dtype=self.dtype).tocsc() File "/usr/local/lib64/python2.5/site-packages/scipy/sparse/sparse.py", line 2264, in __init__ self._check() File "/usr/local/lib64/python2.5/site-packages/scipy/sparse/sparse.py", line 2277, in _check raise TypeError,'row array has invalid dtype' TypeError: row array has invalid dtype Nils

3 3

changes to scipy.sparse
by Nathan Bell 26 Oct '07

26 Oct '07

There have been some recent changes to scipy.sparse that may potentially affect others. http://projects.scipy.org/scipy/scipy/changeset/3465 Sparse matrices (csr_matrix, csc_matrix, and coo_matrix) now support 64-bit indices and the following dtypes: int8, uint8, int16, int32, int64, float32, float64, complex64, complex128 Unsupported dtypes will be accepted by the sparse objects, but they'll be upcasted (by SWIG) to one of the above types when sent to one of the sparsetools functions. Operations between different data types should follow the expected upcasting procedure (e.g. complex64 * float64 -> complex128). The only issue I found when using non-floating point dtypes occurred in linsolve.spsolve() which assume a FP dtype. I created a method spmatrix.asfptype() that returns a sparse matrix withan appropriate FP type when necessary. In addition, the member variable spmatrix.fptype was removed since it pertained only to SuperLU. A few small edits to linsolve.spsolve were made to account for these changes. I have not tested the UMFPACK bindings yet, so let me know if there are any problems. I encountered an unexpected bug related to io.mio (matlab IO). The mio methods were creating sparse matrices with non-native byte order. The SWIG magic in sparsetools accounts for non-contiguous arrays, but not endianness. As a temporary fix I cast all input arrays to native byte order using: 44 def to_native(A): 45 if not A.dtype.isnative: 46 return A.astype(A.dtype.newbyteorder('native')) 47 else: 48 return A This seems to work, however I'd like to improve my SWIG to account for such issues instead. I believe the current SWIG bindings in the numpy SVN check for, but do not change byteorder. Does anyone have SWIG that accounts for this? With the additional data types, the SWIG output for sparsetools now weighs in a nearly 3MB and takes about 2.5 minutes to compile on my 1.8 GHz Athlon 64. While this is a rather large amount of C++ I don't think we can assume that end-users will have SWIG, let alone the a recent SVN version required by sparsetools for some systems. The size and compile time are due to the large number of functions (23*9*2 = 414) generated by the templates. A while ago I wrote a small C++ wrapper for numpy complex types so templated code (like sparsetools) can make sense of T + T and T == 0 etc. The numpy SWIG examples seem to lack complex support, so I thought this may be valuable to others. http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/sparse/sparsetool… Also, I plan to add support for block CSR and CSC formats to sparse in the near future. As always, comments and questions are welcome. -- Nathan Bell wnbell(a)gmail.com

1 0

scipy sparse documentation
by dmitrey 26 Oct '07

26 Oct '07

hi all, could you inform me where is the most appropriate documentation of using sparse matrices? is it possible to add the one to http://www.scipy.org/SciPy_packages? (currently it has just an empty page related to sparse) in FAQ there are 2 packages mentioned: sparse and sandbox pysparse. What about the latter - will it be next default scipy sparse toolbox or the one is obsolete? http://www.scipy.org/FAQ?highlight=%28sparse%29 Regards, D.

2 1