Mailman 3 December 2015 - SciPy-User

ANN: Astropy v1.1 released
by Thomas Robitaille 14 Dec '15

14 Dec '15

Dear colleagues, We are very happy to announce the v1.1 release of the Astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven Python package intended to contain much of the core functionality and common tools needed for astronomy and astrophysics. New and improved major functionality in this release includes: * New functions to automatically determine histogram bins, including the Bayesian blocks algorithm * A new interface to transform between Table objects and pandas DataFrame objects * Support for table indexing * Support for supergalactic and ecliptic coordinates * A new .info attribute to get summary information about tables and columns * A new show_in_notebook() method to show a table in Jupyter/IPython notebooks with additional interactivity features * Support for new units, including logarithmic units such as magnitudes, dex, and decibels * Support for the Planck 2015 cosmology and significant performance improvements in the cosmology sub-package In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/stable/whatsnew/1.1.html Instructions for installing Astropy are provided on our website, and extensive documentation can be found at: http://docs.astropy.org If you make use of the Anaconda Python Distribution, you can update to Astropy v1.1 with: conda update astropy If you normally use pip, you can upgrade with: pip install astropy --upgrade Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 160 developers have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: http://www.astropy.org/team.html As a reminder, Astropy v1.0 (our long term support release) will continue to be supported with bug fixes until Feb 19th 2017, so if you need to use Astropy in a very stable environment, you may want to consider staying on the v1.0.x set of releases rather than upgrading to v1.1. If you use Astropy directly for your work, or as a dependency to another package, please remember to include the following acknowledgment at the end of papers: """ This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2013). """ where (Astropy Collaboration, 2013) is a reference to the Astropy paper: http://dx.doi.org/10.1051/0004-6361/201322068 Please feel free to forward this announcement to anyone you think might be interested in this release! Thomas Robitaille, Erik Tollerud, and Perry Greenfield on behalf of The Astropy Collaboration

1 0

pip install scipy: error adding symbols: bad value
by Daπid 11 Dec '15

11 Dec '15

I have upgraded to Fedora 23, that includes the new binary ABI, so I decided to recompile my modules. I created a new virtualenv, updated pip and setuptools, and installed numpy and scipy with pip. The second one failed spitting: /bin/ld: build/temp.linux-x86_64-2.7/libdfftpack.a(zffti1.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC build/temp.linux-x86_64-2.7/libdfftpack.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status Find attached the full log. I am using GCC 5.1.1 and openBLAS 0.2.15. For the record, Numpy's f2py tests are also failing.

3 5

Q: Use of scipy.signal.bilinear
by R Schumacher 08 Dec '15

08 Dec '15

We have a function which describes a frequency response correction to piezo devices we use. To flatten the FFT, it is similar to: Cdis_t = .5 N = 8192 for n in range(8192): B3 = n * 2560 / N Fc(n) = 1 / ((B3/((1/(Cdis_t*2*pi))**2+B3**2)**0.5)*(-0.01*log(B3) + 1.04145)) In practice it really only matters for low frequencies. I suggested that we might be able to do a time domain correction as a forward-reverse FFT filter using the function, but another said it can also be applied in the time domain using a bilinear transform. So, can one use http://docs.scipy.org/doc/scipy-0.16.0/reference/generated/scipy.signal.bil… and, how does one generate b,a from the given Fourrier domain flattening function? I'd guess someone here has done this... - Ray

1 0

Numpy 1.10.2rc2 released
by Charles R Harris 08 Dec '15

08 Dec '15

Hi All, I'm pleased to announce the release of Numpy 1.10.2rc2. After two months of stomping bugs I think the house is clean and we are almost ready to put it up for sale. However, bugs are persistent and may show up at anytime, so please inspect and test thoroughly. Windows binaries and source releases can be found at the usual place on Sourceforge <https://sourceforge.net/projects/numpy/files/NumPy/1.10.2rc2/>. If there are no reports of problems in the next week I plan to release the final. Further bug squashing will be left to the 1.11 release except possibly for regressions. The release notes give more detail on the changes. *bon appétit,* Chuck

1 0

wavio -- A python module for reading and writing WAV files
by Warren Weckesser 05 Dec '15

05 Dec '15

A stackoverflow answer about reading 24 bit WAV files has evolved into a small module called 'wavio' that is now on PyPI: https://pypi.python.org/pypi/wavio The functions 'wavio.read()' and 'wavio.write()' allow numpy arrays to be read from and written to integer WAV files (including 24 bit files, which scipy doesn't yet support). The functions use the Python 'wave' library, so they have the same limitations as that module. In particular, these functions to not support floating point WAV data (which scipy *does* support). 'wavio.write()' converts a floating point array to integers before writing it to the file. Feedback is welcome, either by email or by reporting issues on the github page: https://github.com/WarrenWeckesser/wavio Now go make some noise. Warren

1 0

Survival vs 1-cdf clarification
by Olga Botvinnik 04 Dec '15

04 Dec '15

For the random variables in scipy.stats, I have a question about the documentation. Does the statement "Survival function (1-cdf — sometimes more accurate)." mean: 1. Survival function (also defined as 1-cdf, and the survival function version is sometimes more accurate). -- or -- 2. Survival function (also defined as 1-cdf, and 1-cdf is sometimes more accurate). Thanks! Olga

3 4

gmres callback with restart unworking ?
by zimon toutoune 03 Dec '15

03 Dec '15

Dear, I would like to catch the full convergence history for all the iterations, - no restart: gmres(full) - with restart: gmres(restart) and in the same time, be able to fix the maximum number of total iterations, to avoid surprise. I would like to track the residual of all the inner iterations. What is the more efficient solution ? because I have remarked a twisted behavior with 'callback'. I guess that the test in 'ijob==3' is not fine enough. 'If callback' is None, then the number of total iterations corresponds to 'maxiter*restart', and 'maxiter' fixes the number of outer iterations, 'restart' fixes the number of inner iterations. Note that if 'restart' is None, the default parameter is 20. This behavior is the expected one, right ? If 'callback' is not None, then the number of total iterations corresponds to 'maxiter', but the 'restart' parameter is never considered. In both case, with or without 'callback', if 'maxiter' is None, then GMRes is running more the size of the matrix which does not make so much sense from a linear algebra point of view. Note that the number of matvec performed corresponds to the number of total iterations plus one. Which is expected due to the initial residual. However, the 'callback' does not catch it. Why not add it ? The preconditioner, is it applied at Left or at Right ? What is the best strategy to apply a preconditioner depending on the iteration number ? Sould be a good idea or not to maintain a pythonic implementation of gmres similar to lgmres ? Last, but not least, where could I find the doc about the 'ijob' numbering and the Fortran API ? Maybe I am missing a point ? All the best, simon ~~python #!/usr/env python # coding: utf8 import numpy import scipy.linalg import scipy.sparse.linalg def f(x): global countMatvec countMatvec += 1 y = numpy.random.rand(x.shape[0]) return y def catch(res): global countRes, reslist countRes += 1 reslist.append(res) N = 50 A = scipy.sparse.linalg.LinearOperator((N, N), matvec=f, dtype=complex) b = numpy.random.rand(A.shape[0]) m = 3 r = 7 if m is None: mm = 1 else: mm = m if r is None: rr = 20 else: rr = r print("\nno callback") countMatvec = 0 countRes, reslist = 0, [] y, info = scipy.sparse.linalg.gmres(A, b, maxiter=m, restart=r) print(countMatvec-1, countRes, mm*(rr+1)-1, info==mm, info) print(numpy.linalg.norm(b - A.matvec(y))) print("\ncallback") countMatvec = 0 countRes, reslist = 0, [] y, info = scipy.sparse.linalg.gmres(A, b, maxiter=m, restart=r, callback=catch) print(countMatvec-1, countRes, mm*(rr+1)-1, info==mm, info) print(numpy.linalg.norm(b - A.matvec(y)))

1 0

why is GMRES slow ? [py=3.4.3 numpy=1.10 scipy=0.16]
by zimon toutoune 02 Dec '15

02 Dec '15

Dear, I am looking for an explanation why GMRes [scipy.sparse.linalg.gmres] running 'Niter' iterations is much more slower than applying 'Niter' times 'matvec' (or 'dot'). For sure, there is the Arnoldi orthogonalization, the Givens rotation, but the gap is more huge than that. Moreover, for dense matrices [numpy.ndarray], solving with 'scipy.linalg.solve', i.e. performing a LU decomposition, is really, really faster. (and hopefully same result using 'numpy.linalg.solve') But LU is about O(N**3) and Krylov about O(Niter*N**2), therefore fixing 'Niter' small and 'N' big enough should show significant differences. I am not talking about convergence, only about the expected performances. And I know that solving random matrices is not a well-thought idea, but it appears to me a way to quickly benchmark since I am just interesting about performances. Let see the code below. In short, the matrix is complex and the size is 5000. There is no restart and maxiter is 50. And the results are: > In [1]: run test.py solve gmres mydot 7.203553199768066 26.598630666732788 1.2706046104431152 50 > In [2]: %timeit scipy.linalg.solve(A, b) 1 loops, best of 3: 7.15 s per loop > In [3]: %timeit scipy.sparse.linalg.gmres(A, b, maxiter=m, restart=r) 1 loops, best of 3: 25.7 s per loop > In [4]: %timeit mydot(A, b, maxiter=info) 1 loops, best of 3: 1.14 s per loop - Is it expected ? - Is it reproductible ? (I do with 2 versions of Numpy/Scipy on MacOS and Debian, and so I am missing an installation problem ?, and the Debian one runs python=3.4.3 numpy=1.10 scipy=0.16 installed through conda) - Does it come from the constants behind big-O ? (size versus time should show confirm or not, right ?) - Does it come from a detail about the implementation ? (all is calling BLAS/LAPACK, right ?) If I miss a point and my questions are naive, then oups! Because why ? Best Regards, simon ~~python code #!/usr/env python # coding: utf8 import numpy import scipy.linalg import scipy.sparse.linalg from time import time N = 5000 m = 50 r = None A = numpy.random.rand(N, N) + 1j * numpy.random.rand(N, N) b = numpy.random.rand(N) + 1j * numpy.random.rand(N) def mydot(A, x, maxiter=5): for i in range(maxiter): A.dot(x) numpy.sum(x * x) print('solve') tt = time() x = scipy.linalg.solve(A, b) ts = time() - tt print('gmres') tt = time() y, info = scipy.sparse.linalg.gmres(A, b, maxiter=m, restart=r) tg = time() - tt if info <= 0: info = m print('mydot') tt = time() mydot(A, b, maxiter=info) tm = time() - tt print(ts) print(tg) print(tm) print(info)

2 2

ANN: SfePy 2015.4
by Robert Cimrman 01 Dec '15

01 Dec '15

I am pleased to announce release 2015.4 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (preliminary support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker, wiki: http://github.com/sfepy Highlights of this release -------------------------- - basic support for restart files - new type of linear combination boundary conditions - balloon inflation example For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman on behalf of the SfePy development team --- Contributors to this release in alphabetical order: Robert Cimrman Grant Stephens

2 2