Mailman 3 November 2018 - SciPy-Dev

trying to understand how zi is used in lfilter
by Robert Dodier Nov. 8, 2018

Nov. 8, 2018

Hi, I working on translating scipy.signal.lfilter into another programming language (or at least enough of it for the current project). I am looking at the source code of Scipy 1.1.0 for that purpose. lfilter takes an optional argument zi. I see that lfilter_zi can compute a value for zi, and in the examples I've found, lfilter is called with zi = zi_foo * x[0] where zi_foo is the output from lfilter_zi and x[0] is the first input datum. I understand that zi represents the steady state value for the filter and that's great, no problem there. What I don't understand is how zi is taken into account in lfilter. lfilter punts to sigtools._linear_filter, which punts to RawFilter, and at that point I can't figure out what's going on anymore. Can anyone guide me to any description of the use of zi in lfilter, _linear_filter, or RawFilter? A formula, some comments, a Wikipedia page, anything would be very helpful. Thanks very much for any light you can shed on this question. Robert Dodier

1 1

Pythran 0.9.0 - kozhamzer
by serge guelton Nov. 6, 2018

Nov. 6, 2018

Hi all, It is my pleasure to announce the release of version 0.9.0 of the Pythran compiler, a compiler for numerical kernels written in Python. It is available for download on PyPI; pip install pythran And on Conda through conda-forge: conda install -c conda-forge pythran The major change of this release is undoubtedly the use of xsimd [0] as the new vectorization engine, which in turns enables vectorization of complex number expressions! All the details are in the changelog reproduced below. And an outstanding new: looks like Pythran is used at least in one research team at Facebook \o/ In spite of the short window, we received *a lot* of bug report, thanks a lot to @DerWeh, @KOLANICH, @RalphFS, @ashwinvis, @diorcety, @h-vetinari, @jeanlaroche, @lw3259111, @paugier, @vgroff for reporting and sometimes fixing issues. Special thanks go to @wolfv and @JohanMabille for the xsimd support. We're getting closer to 1.0, which will probably be the first one to drop 2.7 support (goal: 2020). Until then, happy computations! -- Serge [0] https://github.com/QuantStack/xsimd ===== 2018-11-06 Serge Guelton <serge.guelton(a)telecom-bretagne.eu> * Moving to xsimd as vectorization engine, requires -DUSE_XSIMD * Better support of view conversion from Python to Pythran * Improved Cython integration * Improved documentation, add example section * Updated ArchLinux Packaging * Remove useless warnings during compilation * Faster ``abs(x**2)`` for complex numbers * IPython magic now accepts most optimization flags * Automatic detection of partially (or fully) constant shape for arrays * Add ignoreflags settings to .pythranrc to skip some compiler flags * Quad number (aka long double) basic support * And many minor bugfixes, as usual :-)

1 0

Truncated distributions
by Ali Cetin Nov. 6, 2018

Nov. 6, 2018

Hi all, I note that quite a few truncated distribution functions are available in SciPy - nice! However, I find the usefulness of these functions somewhat limited when it is desired to fit them to data; in most common scenarios the truncation point is known (or even determined by the user/experimenter), and therefore do not need to be treated as a free parameter. In the current scipy.stats framework, the truncation parameters are accepted as "shape" parameters. Therefore, it is only possible to lock the "normalized" truncation point during fitting. This is a catch-22, since the user is required to provide loc and scale parameters a priori, which are unknown. I would like to propose a solution that only require minor adjustment of the current framework: allow the user to supply the truncation point as part of the data array -> for left and right truncation, the 0th and the Nth element of the array is poped out and used as truncation parameters, respectively. Is this a viable solution? Cheers, Ali

4 6

NumPy 1.15.4 release
by Charles R Harris Nov. 4, 2018

Nov. 4, 2018

Hi All, On behalf of the NumPy team, I am pleased to announce the release of NumPy 1.15.4. This is a bugfix release for bugs and regressions reported following the 1.15.3 release. The most noticeable fix is probably having a boolean type fill value for masked arrays after the use of `==` and `!=`. The Python versions supported by this release are 2.7, 3.4-3.7. Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.15.4/>, source archives are available from Github <https://github.com/numpy/numpy/releases/tag/v1.15.4>. Compatibility Note ================== The NumPy 1.15.x OS X wheels released on PyPI no longer contain 32-bit binaries. That will also be the case in future releases. See `#11625 < https://github.com/numpy/numpy/issues/11625>`__ for the related discussion. Those needing 32-bit support should look elsewhere or build from source. Contributors ============ A total of 4 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Charles Harris - Matti Picus - Sebastian Berg - bbbbbbbbba + Pull requests merged ==================== A total of 4 pull requests were merged for this release. - `#12296 <https://github.com/numpy/numpy/pull/12296>`__: BUG: Dealloc cached buffer info - `#12297 <https://github.com/numpy/numpy/pull/12297>`__: BUG: Fix fill value in masked array '==' and '!=' ops. - `#12307 <https://github.com/numpy/numpy/pull/12307>`__: DOC: Correct the default value of `optimize` in `numpy.einsum` - `#12320 <https://github.com/numpy/numpy/pull/12320>`__: REL: Prepare for the NumPy 1.15.4 release Cheers, Charles Harris

1 0

bicgstab
by Dieter Werthmüller Nov. 2, 2018

Nov. 2, 2018

Hi everyone, I've got some questions related to scipy.sparse.linalg.bicgstab. I try to move some code from Matlab to Python. Now, in the Matlab-bicgstab the matrix A and the preconditioner M can be function handles; from the docs: "A can be a function handle, afun, such that afun(x) returns A*x." and similar "M can be a function handle mfun, such that mfun(x) returns M\x." This can be very useful, because you can avoid creating the matrices A and M explicitly. As far as I can see, this is not possible in scipy.sparse.linalg.bicgstab. Therefore my questions: - Is that correct, it is not possible with scipy.sparse.linalg.bicgstab, or do I miss something? (Are there any examples online? I couldn't find much in the docs.) - Is there a trick to achieve the same behaviour in scipy.sparse.linalg.bicgstab? - If not, do you know of other packages in Python that provide that feature? Thanks a lot, Dieter

3 6

building scipy for WebAssembly
by Roman Yurchak Nov. 2, 2018

Nov. 2, 2018

Hello, I am currently working on building scipy for WebAssembly as part of pyodide project (https://github.com/iodide-project/pyodide) and I was hoping for some feedback on that process. There is a preliminary build in https://github.com/iodide-project/pyodide/pull/211 Currently, this build uses scipy 0.17.1 as from what I understood, that was one of the last versions that only included f77 without any f90 (https://github.com/scipy/scipy/issues/2829#issuecomment-223764054). In the WebAssembly environment there is currently no reliably working Fortran compiler (https://github.com/iodide-project/pyodide/issues/184), and f90 cannot be converted to C with f2c unlike f77. If one wanted to (experimentally) compile the latest version of scipy without a Fortran compiler what would be your suggestions? i.e. - are there any alternatives to f2c that you think might work for f90 - or any automatic converter f90 to f77 (so that f2c could be used) I did search but maybe I missed something. Alternatively, if that's really not realistic, could someone please comment on the rate of adoption for f90/f95 in the scipy code base? The decision to support f90 was taken before the 0.18 release in 2016 but I'm not sure what impact it had on the code base. In other words maybe there is a later version than 0.17.1 that might (mostly) work? Another point is linking BLAS/LAPACK. Currently reference BLAS and CLAPACK are linked statically as I haven't managed to do this dynamically yet. The issue is the package size. As LAPACK, which is quite large, gets repeatedly included in around ~10 different .so modules, resulting in a 170MB large package (after compression), as opposed to ~30MB compressed package without BLAS/LAPACK. That is quite problematic when one is expected to download the dependencies at each page load (excluding caching). I'm not sure if there are other distributions of scipy that use static linking of LAPACK? or other things worth trying to reduce the package size, short of trying to make dynamic linking work or try to detect and strip unused symbols? Also in scipy/linalg/setup.py I was wondering why/how the ATLAS_INFO macro defined the existence of `scipy.linalg._clapack`? For instance, when using CLAPACK (with libf2c), would the following be correct? lapack_opt = {'libraries': ['f2c', 'blas', 'lapack'], 'include_dirs': [], 'library_dirs': ['<path_to_blas_lapack_lib>'], 'language': 'f77', 'define_macros': [('NO_ATLAS_INFO', 1), ('HAVE_CBLAS', None)]} which does not appear to build `scipy.linalg._clapack`. Finally, in later scipy versions, https://scipy.github.io/devdocs/building/linux.html suggests that with “export LAPACK=” one can build scipy without LAPACK, but then _flapack is still a mandatory import in scipy.linalg.__init___ (via .lapack) as far as I can tell. Is scipy.linalg (and anything that depends on it) expected to produce import errors in the latter case then? In general, any comments or suggestions would be appreciated, Thank you, Roman

2 2

Parallelised brute
by Andrew Nelson Nov. 2, 2018

Nov. 2, 2018

In #9428 I've added a workers keyword that adds the ability to parallelise `optimize.brute`. It's not an enormous change, and it makes use of the machinery that was used in `differential_evolution`. Is it too late for it to go in before the next branch? Tests are passing, and I've added a test to check that the parallelised version gives the same result as a serial version.

2 1