Mailman 3 January 2020 - SciPy-Dev

SciPy Contribution: Gammatone Filters in scipy.signal
by Shashaank Narayanan 23 May '20

23 May '20

Hello SciPy Team, I am new to this mailing list, and I am interested in contributing to SciPy. I would like to suggest a new feature to be added to the scipy.signal module: gammatone filters. Gammatone filters are becoming increasingly popular in the fields of digital signal processing and music analysis as it effectively models the auditory filters of the human auditory system. Currently, there are very few implementations of gammatone filters available for Python, and these implementations are not generalized to basic finite impulse response (FIR) and infinite impulse response (IIR) filters like SciPy has. I have written my own gammatone FIR filter using NumPy based on Malcolm Slaney's 1993 paper on the topic ( https://engineering.purdue.edu/~malcolm/apple/tr35/PattersonsEar.pdf). This paper was used for Matlab's implementation of gammatone filters. I am in the process of writing a gammatone IIR filter with NumPy and SciPy. Please let me know if this feature will fit with the scipy.signal module. Appreciate your time and guidance. Thanks, Shashaank

5 6

Implementation choices in scipy.sparse.linalg.LinearOperator
by matteo ravasi 04 Feb '20

04 Feb '20

Dear Scipy Developers, some of you may be aware of the PyLops project (https://github.com/equinor/pylops), which heavily builds on the scipy.sparse.linalg.LinearOperator class of scipy and provides an extensive library of general purpose and domain specific linear operators. Recently a users asked for a functionality that would create the equivalent dense matrix representation of an operator (to be mostly used for teaching purposes). While implementing it, we came across two internal behaviours in the interface.py file that we would like to mention and discuss about: - The method _matmat and _rmatmat as implemented per today requires operators to work on (N, 1)/(M, 1) arrays. Whilst the first sentence in the Notes of LinearOperator states "The user-defined matvec() function must properly handle the case where v has shape (N,) as well as the (N,1) case", I tend to believe that the first option should be the encouraged one, as I do not really see any advantage with carrying over trailing dimensions in this case. Moreover, some of the linear solvers in scipy that can be used together with linear operator such as lsqr or lsmr, require the RHS b vector to have a single dimension (b : (m,) ndarray). Again, although a quick test showed that they work also when providing a b vector of shape (m, 1), this shows to me that the extra trailing dimension is just a nuisance and should be discouraged. Assuming that you agree with this argument, an alternative solution that works on (N, ) input is actually possible and currently implemented in PyLops for _matmat (see here https://github.com/equinor/pylops/blob/master/pylops/LinearOperator.py <https://github.com/equinor/pylops/blob/master/pylops/LinearOperator.py>). This avoids having implementations that work for both (N, ) and (N, 1), which sometimes requires adding additional checks and squeezes within the implementation of _matvec and _rmatvec in situations where trailing dimensions in the input vector are not really bringing any benefit. - The above mentioned new feature has been currently added as a method to the PyLops LinearOperator class (and named todense in a similar fashion to scipy.sparse.xxx_matrix.todense methods). Doing so, we realized that every time two operators are summed/subtracted/multiplied… (pretty much when one of the overloading of scipy.sparse.linalg.LinearOperator is invoked), the returned object is not of LinearOperator type anymore but of the type of the private class in scipy.sparse.linalg.interface used to perform the requested operator (e.g, _SumLinearOperator). I wonder if returning an object of a ‘private’ type is actually something recommended to do in scipy (or even if this happens anywhere else in scipy). Again, in PyLops we need to overload the __add__ method (and similar methods) and make it into a thin wrappers of the scipy equivalent, returning an object of our parent class LinearOperator. This is to ensure that the returned object would maintain the additional properties and methods of our Linearoperator class, but also to avoid ‘leaking’ any of the private classes to the end users. I wonder if also the scipy API should perhaps avoid returning to end users objects of some private classes. This email is not intended to criticise any of current behaviours in scipy.sparse.linalg.LinearOperator, rather to gain an understanding of some of the decisions made by the core developers of the scipy.sparse.linalg.interface submodule, which may all have their own right to be the way they are today :) Looking forward to hearing from you. Best wishes, MR

4 4

Proposed addition to scipy.sparse.csgraph.maximum_flow
by mhwende 02 Feb '20

02 Feb '20

Hi, recently I have made use of the maximum flow algorithm for CSR matrices, i.e., the scipy.sparse.csgraph.maximum_flow function. My test case was a non-sparse, bipartite network with lots of connections between the two node sets. The value of the maximum flow was small in comparison to the total number of nodes and edges in the graph. I wanted to use the scipy.sparse.csgraph module, however with a depth first search (DFS) instead of the breadth-first search that you have implemented. Therefore, I have implemented a new option to use DFS instead of BFS with your implementation. When measuring the execution time for a random graph, there was a signnificant speedup of the DFS procedure compared to the BFS variant. During these tests, I also refactored the two other functions that you call within the main csgraph.maximum_flow function, i.e., _add_reverse_edges and _make_edge_pointers. Depending on the input graph, I found that the time spent in this functions can be larger than the execution time for the actual Edmond-Karps algorithm. Below, you can find a table showing the measured execution times in seconds. Within the columns of this table, the execution time is broken down into parts as follows: a) Adding reverse edges (function _add_reverse_edges). b) Making edge pointers (function _make_edge_pointers). c) Actual max flow computation (function _edmond_karps) d) Total execution time (function maximum_flow). Rows of the table refer to the changes which were made to the implementation, where each measurement was performed with either DFS or BFS for the construction of augmenting paths: 1) Original implementation. 2) After the reimplementation of _make_edge_pointers. 3) After the reimplementation of _add_reverse_edges. Here are the execution times: | a) | b) | c) | d) --------+-----------+-----------+-----------+----------- 1. BFS | 1.29 s | 3.81 s | 8.93 s | 14.08 s 1. DFS | 1.29 s | 3.82 s | 0.50 s | 5.66 s --------+-----------+-----------+-----------+----------- 2. BFS | 1.54 s | 0.22 s | 8.94 s | 10.76 s 2. DFS | 1.33 s | 0.22 s | 0.50 s | 2.10 s --------+-----------+-----------+-----------+----------- 3. BFS | 0.16 s | 0.27 s | 9.01 s | 9.50 s 3. DFS | 0.16 s | 0.23 s | 0.52 s | 0.96 s By comparing the total execution times for BFS in 1d) and for DFS in 3d), my code changes have led to a speedup of about 14, for the network example which I have mentioned. Please let me know if would like to incorporate some or all of my changes into your code base. My changes (a single commit) can be found here: https://github.com/mhwende/scipy/commit/e7be2dc29364fe95f6fae20a4c0775716cd… Finally, here is the script which I have used for testing. The above timings have been produced with the command: python scipymaxflowtest 2000 2000 --dfs=0 This will create a graph with 4000 nodes and 4,000,000 edges, with randomly chosen zero or unit capacities. # File scipymaxflowtest.py import time import argparse import numpy as np import scipy.sparse as sp def scipymaxflowtest(layer_sizes, dfs): layer_sizes = np.array(layer_sizes, dtype = np.int) num_layers = len(layer_sizes) print("Layer sizes:", *layer_sizes) print("Number of layers:", num_layers) num_nodes = 2 + np.sum(layer_sizes) print("Number of nodes:", num_nodes) num_edges = layer_sizes[0] + layer_sizes[-1] for i in range(layer_sizes.size - 1): num_edges += layer_sizes[i] * layer_sizes[i + 1] print("Number of edges:", num_edges) #data = np.ones(num_edges, dtype = np.int) data = np.random.randint(0, 2, num_edges) indices = np.zeros(num_edges, dtype = np.int) indptr = np.zeros(num_nodes + 1, dtype = np.int) ptr = 0 for j in range(layer_sizes[0]): indices[ptr] = 2 + j ptr += 1 indptr[1] = ptr indptr[2] = ptr layer_sum = 0 for k in range(num_layers - 1): next_layer_sum = layer_sum + layer_sizes[k] for i in range(layer_sizes[k]): for j in range(layer_sizes[k + 1]): indices[ptr] = 2 + next_layer_sum + j ptr += 1 indptr[2 + layer_sum + i + 1] = ptr layer_sum = next_layer_sum for i in range(layer_sizes[-1]): indices[ptr] = 1 ptr += 1 indptr[2 + layer_sum + i + 1] = ptr indptr[num_nodes] = ptr # Check that we set as many entries in the index array as there are edges. assert ptr == num_edges # Create CSR matrix from data and index arrays. a = sp.csr_matrix((data, indices, indptr), shape = (num_nodes, num_nodes)) if num_nodes <= 12: print("A =\n{}".format(a.toarray())) t0 = time.time() flow_result = sp.csgraph.maximum_flow(a, 0, 1, dfs) t1 = time.time() flow_value = flow_result.flow_value print("Maximum flow: {} (took {:.6f} s)".format(flow_value, t1 - t0)) return flow_value if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument( "layer_sizes", type = int, nargs = "+", help = "Number of nodes on individual graph layers.") parser.add_argument( "--dfs", type = int, default = 0, help = "Whether to user depth first search.") args = parser.parse_args() np.random.seed(4891243) scipymaxflowtest(args.layer_sizes, args.dfs)

2 1

Missing whitespace after commas in pycodestyle check
by Joshua Wilson 30 Jan '20

30 Jan '20

Hey everyone, During code review, it seems that we care about missing whitespace after commas. (I have no data on this, but I suspect it is our most common linting nit.) Linting for this is currently disabled. Now on the one hand, we generally avoid turning on checks like this because of the disruption to open PRs and what they do to git history. On the other hand, I don't think enforcing this check by hand works. Reminding an author to add spaces after commas can easily add several rounds of extra review (some places almost invariably get missed on the first try, and then the problem tends to sneak back in in later commits), and I usually just give up after a while. So I don't think we are heading in the direction of "in 5 years all the bad cases will be gone and we can turn on the check without disruption". So I would kind of like to push us to either: 1. Turn the lint check on. We can do this module-by-module or even file-by-file if necessary to minimize disruption. 2. Declare that this is not something we care about in code review. Thoughts? - Josh

6 9

Github actions setup.
by Andrew Nelson 29 Jan '20

29 Jan '20

I've recently setup github actions for a personal project. The setup is quite quick, the test suite runs in parallel and it seems to be fast. I'm wondering what peoples thoughts are for doing the same for scipy? The rationale is that there is a reasonably heavy load on travisCI (10 entries) and this might be a way of spreading the load somewhat. e.g. we could take off half the Linux entries.

2 1

SciPy 2020 Call for Submissions is open!
by Melissa Mendonça 29 Jan '20

29 Jan '20

Apologies for crossposting. ===== SciPy 2020, the 19th annual Scientific Computing with Python conference, will be held July 6-12, 2020 in Austin, Texas. The annual SciPy Conference brings together over 900 participants from industry, academia, and government to showcase their latest projects, learn from skilled users and developers, and collaborate on code development. The call for SciPy 2020 talks, posters, and tutorials is now open through February 11, 2020. Talks and Posters (July 8-10, 2020) In addition to the general track, this year will have the following specialized tracks, mini symposia, and sessions: Tracks High Performance Python Machine Learning and Data Science Mini Symposia Astronomy and Astrophysics Biology and Bioinformatics Earth, Ocean, Geo and Atmospheric Science Materials Science Special Sessions Maintainers Track SciPy Tools Plenary Session For additional details and instructions, please see the conference website. <https://www.scipy2020.scipy.org/> Tutorials (July 6-7, 2020) Tutorials should be focused on covering a well-defined topic in a hands-on manner. We are looking for awesome techniques or packages, helping new or advanced Python programmers develop better or faster scientific applications. We encourage submissions to be designed to allow at least 50% of the time for hands-on exercises even if this means the subject matter needs to be limited. Tutorials will be 4 hours in duration. In your tutorial application, you can indicate what prerequisite skills and knowledge will be needed for your tutorial, and the approximate expected level of knowledge of your students (i.e., beginner, intermediate, advanced). Instructors of accepted tutorials will receive a stipend. For examples of content and format, you can refer to tutorials from past SciPy tutorial sessions (SciPy 2018 <https://na-admin.eventscloud.com/emarketing/go.php?i=735095&e=amlsbGNAZW50a…>, SciPy2019 <https://na-admin.eventscloud.com/emarketing/go.php?i=735095&e=amlsbGNAZW50a…> ) and some accepted submissions <https://na-admin.eventscloud.com/emarketing/go.php?i=735095&e=amlsbGNAZW50a…>. For additional details and instructions see the conference website <https://na-admin.eventscloud.com/emarketing/go.php?i=735095&e=amlsbGNAZW50a…> . Submission page: https://easychair.org/conferences/?conf=scipy2020 Submission Deadline: February 11, 2020 - Melissa Weber Mendonça Diversity Committee Co-Chair

1 1

Re: [SciPy-Dev] Generate random variates using Cython
by Christoph Baumgarten 23 Jan '20

23 Jan '20

Hi, After upgrading to Numpy 1.18, I could indeed compile the code https://docs.scipy.org/doc/numpy-1.17.0/reference/random/extending.html and it gives a substantial speedup. I am still wondering how to integrate such an approach into SciPy. To generate uniform samples in the _rvs method of a continuous distribution i scipy.stats, I would write: self._random_state.random_sample If I want to use Cython, how can I ensure that it relies on the same random state? In the future, one needs to support RandomState and Generator (cross-ref to the recent PR https://github.com/scipy/scipy/pull/11402) Thanks for your help. Christoph P.S. code used import numpy as np cimport numpy as np cimport cython from cpython.pycapsule cimport PyCapsule_IsValid, PyCapsule_GetPointer from numpy.random cimport bitgen_t from numpy.random import PCG64 @cython.boundscheck(False) @cython.wraparound(False) def rvs(Py_ssize_t n): cdef Py_ssize_t i cdef bitgen_t *rng cdef const char *capsule_name = "BitGenerator" cdef double u, v cdef double[::1] random_values x = PCG64() capsule = x.capsule # Optional check that the capsule if from a BitGenerator if not PyCapsule_IsValid(capsule, capsule_name): raise ValueError("Invalid pointer to anon_func_state") # Cast the pointer rng = <bitgen_t *> PyCapsule_GetPointer(capsule, capsule_name) random_values = np.empty(n, dtype='float64') with x.lock, nogil: for i in range(n): while (1): u = rng.next_double(rng.state) v = rng.next_double(rng.state) if u <= v*v: break random_values[i] = v randoms = np.asarray(random_values) return randoms On Thu, Jan 16, 2020 at 12:46 PM <scipy-dev-request(a)python.org> wrote: > Send SciPy-Dev mailing list submissions to > scipy-dev(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request(a)python.org > > You can reach the person managing the list at > scipy-dev-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. Generate random variates using Cython (Christoph Baumgarten) > 2. Re: Generate random variates using Cython (Matti Picus) > 3. Re: Missing whitespace after commas in pycodestyle check > (Joshua Wilson) > 4. cuSignal: GPU accelerated version of SciPy Signal package > (Robert Lucente - Pipeline.Com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Jan 2020 20:14:07 +0100 > From: Christoph Baumgarten <christoph.baumgarten(a)gmail.com> > To: scipy-dev(a)python.org > Subject: [SciPy-Dev] Generate random variates using Cython > Message-ID: > < > CABXY2qC6PLydMVi5on7x3tqn2qED5nBD19ACtKA81OYm_Y4GAA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I recently looked into rejection algorithms to generate random variates > that rely on repeatedly generating uniform random variates until a > termination condition is satisfied. > A pure Python implementation is reasonably fast but much slower than a C > implementation (e.g. Poisson distribution in numpy). I tried to use Cython > to adapt my Python code (I just started to look into Cython, so it could be > that I overlook something very basic) but I did not succeed and I would > like to ask for help. > > The following code works that generates rvs on [0, 1] with density 3 x**2 > as an example (compiling it generates a warning though: Warning Msg: Using > deprecated NumPy API, disable it with #define NPY_NO_DEPRECATED_API > NPY_1_7_API_VERSION) but I struggle to get rid of the Python interaction > np.random.rand() to speed it up. > > cimport numpy as np > from numpy cimport ndarray, float64_t > import numpy as np > def rvs(int N): > cdef double u, v > cdef int i > cdef np.ndarray[np.float64_t, ndim=1] x = np.empty((N, ), > dtype=np.float64) > for i in range(N): > while (1): > u = np.random.rand() > v = np.random.rand() > if u <= v*v: > break > x[i] = v > return x > > Following https://numpy.org/devdocs/reference/random/c-api.html (Cython > API > for random), I tried > cimport numpy.random to use random_standard_uniform. > However, I get an error: 'numpy\random.pxd' not found > > I get similar errors when trying to compile the Cython examles here: > https://docs.scipy.org/doc/numpy-1.17.0/reference/random/extending.html > > Cython version: 0.29.14 > Numpy 1.17.4 > python 3.7.1 > > Any guidance on how to access the uniform distribution in numpy using > Cython would be great. Thanks > > Christoph >

2 2

ANN: SciPy 1.2.3 (LTS)
by Tyler Reddy 21 Jan '20

21 Jan '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.2.3, which is a bug fix release. This is part of the long-term support (LTS) branch that includes Python 2.7. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.2.3 One of a few ways to install this release with pip: pip install scipy==1.2.3 ========================== SciPy 1.2.3 Release Notes ========================== SciPy 1.2.3 is a bug-fix release with no new features compared to 1.2.2. It is part of the long-term support (LTS) release series for Python 2.7. Authors ======= * Geordie McBain * Matt Haberland * David Hagen * Tyler Reddy * Pauli Virtanen * Eric Larson * Yu Feng * ananyashreyjain * Nikolay Mayorov * Evgeni Burovski * Warren Weckesser Issues closed for 1.2.3 -------------------------------- * `#4915 <https://github.com/scipy/scipy/issues/4915>`__: Bug in unique_roots in scipy.signal.signaltools.py for roots with same magnitude * `#5546 <https://github.com/scipy/scipy/issues/5546>`__: ValueError raised if scipy.sparse.linalg.expm recieves array larger than 200x200 * `#7117 <https://github.com/scipy/scipy/issues/7117>`__: Warn users when using float32 input data to curve_fit and friends * `#7906 <https://github.com/scipy/scipy/issues/7906>`__: Wrong result from scipy.interpolate.UnivariateSpline.integral for out-of-bounds * `#9581 <https://github.com/scipy/scipy/issues/9581>`__: Least-squares minimization fails silently when x and y data are different types * `#9901 <https://github.com/scipy/scipy/issues/9901>`__: lsoda fails to detect stiff problem when called from solve_ivp * `#9988 <https://github.com/scipy/scipy/issues/9988>`__: doc build broken with Sphinx 2.0.0 * `#10303 <https://github.com/scipy/scipy/issues/10303>`__: BUG: optimize: `linprog` failing TestLinprogSimplexBland::test_unbounded_below_no_presolve_corrected * `#10376 <https://github.com/scipy/scipy/issues/10376>`__: TST: Travis CI fails (with pytest 5.0 ?) * `#10384 <https://github.com/scipy/scipy/issues/10384>`__: CircleCI doc build failing on new warnings * `#10535 <https://github.com/scipy/scipy/issues/10535>`__: TST: master branch CI failures * `#11121 <https://github.com/scipy/scipy/issues/11121>`__: Calls to `scipy.interpolate.splprep` increase RAM usage. * `#11198 <https://github.com/scipy/scipy/issues/11198>`__: BUG: sparse eigs (arpack) shift-invert drops the smallest eigenvalue for some k * `#11266 <https://github.com/scipy/scipy/issues/11266>`__: Sparse matrix constructor data type detection changes on Numpy 1.18.0 Pull requests for 1.2.3 -------------------------------- * `#9992 <https://github.com/scipy/scipy/pull/9992>`__: MAINT: Undo Sphinx pin * `#10071 <https://github.com/scipy/scipy/pull/10071>`__: DOC: reconstruct SuperLU permutation matrices avoiding SparseEfficiencyWarning * `#10076 <https://github.com/scipy/scipy/pull/10076>`__: BUG: optimize: fix curve_fit for mixed float32/float64 input * `#10138 <https://github.com/scipy/scipy/pull/10138>`__: BUG: special: Invalid arguments to ellip_harm can crash Python. * `#10306 <https://github.com/scipy/scipy/pull/10306>`__: BUG: optimize: Fix for 10303 * `#10309 <https://github.com/scipy/scipy/pull/10309>`__: BUG: Pass jac=None directly to lsoda * `#10377 <https://github.com/scipy/scipy/pull/10377>`__: TST, MAINT: adjustments for pytest 5.0 * `#10379 <https://github.com/scipy/scipy/pull/10379>`__: BUG: sparse: set writeability to be forward-compatible with numpy>=1.17 * `#10426 <https://github.com/scipy/scipy/pull/10426>`__: MAINT: Fix doc build bugs * `#10540 <https://github.com/scipy/scipy/pull/10540>`__: MAINT: Fix Travis and Circle * `#10633 <https://github.com/scipy/scipy/pull/10633>`__: BUG: interpolate: integral(a, b) should be zero when both limits are outside of the interpolation range * `#10833 <https://github.com/scipy/scipy/pull/10833>`__: BUG: Fix subspace_angles for complex values * `#10882 <https://github.com/scipy/scipy/pull/10882>`__: BUG: sparse/arpack: fix incorrect code for complex hermitian M * `#10906 <https://github.com/scipy/scipy/pull/10906>`__: BUG: sparse/linalg: fix expm for np.matrix inputs * `#10961 <https://github.com/scipy/scipy/pull/10961>`__: BUG: Fix signal.unique_roots * `#11126 <https://github.com/scipy/scipy/pull/11126>`__: BUG: interpolate/fitpack: fix memory leak in splprep * `#11199 <https://github.com/scipy/scipy/pull/11199>`__: BUG: sparse.linalg: mistake in unsymm. real shift-invert ARPACK eigenvalue selection * `#11269 <https://github.com/scipy/scipy/pull/11269>`__: Fix: Sparse matrix constructor data type detection changes on Numpy 1.18.0 Checksums ========= MD5 ~~~ 702e7f68e024359d5cf0627337944520 scipy-1.2.3-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 53035df3bf9c688fb7803df11b74eb97 scipy-1.2.3-cp27-cp27m-manylinux1_i686.whl 6a07e4864228d4d6bc8d396b9e09f71c scipy-1.2.3-cp27-cp27m-manylinux1_x86_64.whl 645b4211dc2f2b3bdc4e5cf85454e164 scipy-1.2.3-cp27-cp27m-win32.whl 49e6c189ca1a0d92f426e4efaa782f37 scipy-1.2.3-cp27-cp27m-win_amd64.whl a875abf6f3f52fac916739dd556ccefb scipy-1.2.3-cp27-cp27mu-manylinux1_i686.whl 46138092ed3b9e9f0b67afb3765ca041 scipy-1.2.3-cp27-cp27mu-manylinux1_x86_64.whl 608650168cfeda8fb9c1f44ccfb9b6a7 scipy-1.2.3-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 3acbfaf35ad246e4cffd0f7e35f88483 scipy-1.2.3-cp34-cp34m-manylinux1_i686.whl 807bca9d17cf3221a062c6b72192a1ed scipy-1.2.3-cp34-cp34m-manylinux1_x86_64.whl 327a19bd65112ee59425f57cf65dce67 scipy-1.2.3-cp34-cp34m-win32.whl a1b627a5b0b1adb3c5418d3c9081615b scipy-1.2.3-cp34-cp34m-win_amd64.whl 80d65fd4266bcb29e02b03545ae80b7a scipy-1.2.3-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl bd1e8f80f9e0427855ff10810e68118f scipy-1.2.3-cp35-cp35m-manylinux1_i686.whl 35f03968403ad3049db956b90a346a59 scipy-1.2.3-cp35-cp35m-manylinux1_x86_64.whl bf489f87f8bfeb6a14c5e606b539f16a scipy-1.2.3-cp35-cp35m-win32.whl 7a618445b53f4f8671352ea52df5cc9f scipy-1.2.3-cp35-cp35m-win_amd64.whl 7b7e8889babc121b4c1340f4b8081423 scipy-1.2.3-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 8339ebba078ee752b2bd15eb3fc64f2f scipy-1.2.3-cp36-cp36m-manylinux1_i686.whl 4dd7be670ce0b1bd2b4c3f5038cf6fb9 scipy-1.2.3-cp36-cp36m-manylinux1_x86_64.whl 9130c940f3b811b9281ac64a3bd610a6 scipy-1.2.3-cp36-cp36m-win32.whl adeb6e4e9c270df4a5e55d0f1a4a72f0 scipy-1.2.3-cp36-cp36m-win_amd64.whl 19f6644944227c64c50dedbb04f8d91d scipy-1.2.3-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl f75450b9399acd7eb3c0fc1724de4be3 scipy-1.2.3-cp37-cp37m-manylinux1_i686.whl fc1cb1164479e070af722e579604bea2 scipy-1.2.3-cp37-cp37m-manylinux1_x86_64.whl 6c2057a41b73f17daf100f3fc1252903 scipy-1.2.3-cp37-cp37m-win32.whl 27f26a031ac1884ac5cb3e35343aba7c scipy-1.2.3-cp37-cp37m-win_amd64.whl 43b42a507472dfa1dff4c91d58a6543f scipy-1.2.3.tar.gz 561ee26a6d0a9b31d644db5e8244bc76 scipy-1.2.3.tar.xz 5b9f47308d06b22078810fca4f97fad2 scipy-1.2.3.zip SHA256 ~~~~~~ 2ff82db1393bd5d8ddeb9134e8f77a8e971e635452d7e65f7238f40c71d385a8 scipy-1.2.3-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 5d950892a6a2da6dae2b5a3021b329dbf04483a7fb0bd3011685db7f51578ae7 scipy-1.2.3-cp27-cp27m-manylinux1_i686.whl 487a61a7e477923c7a9e8fa06f27e3f2dbc7ce9450a970a2e5d902b0a305d028 scipy-1.2.3-cp27-cp27m-manylinux1_x86_64.whl 3397ce30e240e9a543d81f623a9e8e98ae39012cf72e42e95929530a03f20791 scipy-1.2.3-cp27-cp27m-win32.whl 8533e8c2e467eed913a0aa4fac09c9fb824f32d1ab1121db3a50845f9b347825 scipy-1.2.3-cp27-cp27m-win_amd64.whl b6cbb7125b0c742e0f31fb293d19e9f1a03db58f6ddefc51a2025ee15ae607cb scipy-1.2.3-cp27-cp27mu-manylinux1_i686.whl e870dfd006ab657f9cc48b099646c5ceb4e812e59a7d460dc80ac9a659f089dc scipy-1.2.3-cp27-cp27mu-manylinux1_x86_64.whl b8b0e81a2b87d68acf4a54aea800edafbb5bc9a04f38256718826f95f625fb75 scipy-1.2.3-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl ecc27dda36d7172bb4ed7f245499e28251fa17909b314b4e8956a942f302e1a3 scipy-1.2.3-cp34-cp34m-manylinux1_i686.whl ee213d8c8eee0540ba91efca61605dc0e2b5bd90ca35ab49c85f0ad7038df00f scipy-1.2.3-cp34-cp34m-manylinux1_x86_64.whl 57a0ee083b94944ba6329e755d112bfd53a98bd9a6a4faf10bc7722c955a7653 scipy-1.2.3-cp34-cp34m-win32.whl 1bc0720f149fbb69d19156cf91730aa21455c58949aea56bfaa2b74c06868100 scipy-1.2.3-cp34-cp34m-win_amd64.whl d39ae9cfd7bdea7753fd617e2edfc68b94a019a65c0153c3fced35cf657b79e7 scipy-1.2.3-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 7e6c485c3f2789c790fe4cc5c6c3b4554000d284fd05be90479b6fbd8795d064 scipy-1.2.3-cp35-cp35m-manylinux1_i686.whl 92fbdcf9acebf2007502adbed1b22e3a3e9445aceb5e7a568f9759d76461368b scipy-1.2.3-cp35-cp35m-manylinux1_x86_64.whl b2fad2430232f8c2faeb0abff7ed5191f0a534bd1bd482c71a9616c44e674c76 scipy-1.2.3-cp35-cp35m-win32.whl 8b3ac1e50188792fdf811e5a747df2b784c65d9a17f59609a73c8285424a48ad scipy-1.2.3-cp35-cp35m-win_amd64.whl b38f2e6d53f852ae1de1aacead2c26a69c91b36f833e744557ca370979b81652 scipy-1.2.3-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 39bf06b2536e69f08a257b260aaa25d088d755b73cf3751b44e5838ccb1d0a82 scipy-1.2.3-cp36-cp36m-manylinux1_i686.whl c08013e0fe1554372da9312d5bad588402f71c0636f0f86a9b9b61d507c59bac scipy-1.2.3-cp36-cp36m-manylinux1_x86_64.whl cac83647970115dfb6d29dc3b4ab44b3aa11254e8aeba115f88ad0ccbb273085 scipy-1.2.3-cp36-cp36m-win32.whl 0c23e5b3a314dce4049b969c81ad801cf05e1fe699760846c7567deaa9b8c548 scipy-1.2.3-cp36-cp36m-win_amd64.whl 503e25b8da22b1be6f2f81e1dcf26f42bfb13fe89bccbf8bc48e1b6f2a4789c8 scipy-1.2.3-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 19904399501ecf56ead21b307cc52c8ff03a2103343f554f3fbc189bb2cf1609 scipy-1.2.3-cp37-cp37m-manylinux1_i686.whl f658f90db1530f70128bbeb2c1e61006de2eb2382408080a211d885f501af3a7 scipy-1.2.3-cp37-cp37m-manylinux1_x86_64.whl 7aeb232273b38e74d89181d9165ca47314e1c4269afe7c3a1926aea3e63345a2 scipy-1.2.3-cp37-cp37m-win32.whl 53353a504ad2181eb27c9d61e91ce29324f8b7550876736a08a36e6b60c43407 scipy-1.2.3-cp37-cp37m-win_amd64.whl ecbe6413ca90b8e19f8475bfa303ac001e81b04ec600d17fa7f816271f7cca57 scipy-1.2.3.tar.gz 94ef2ac3c9c83cbbda0a5c5552fffa22993c1c21313c0eb7a2e7102b4629bc31 scipy-1.2.3.tar.xz a4f09f8c6f5924582fc61d3c5cd8174e8f8857a45dfa4a81c0d134b7c4af74cc scipy-1.2.3.zip -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEuinQzfUTSK0iykiguEZ+VI8xggYFAl4nNasACgkQuEZ+VI8x ggYXiQwArWCb+6PjBb/vyjDO8KOjYmVCCNm8OxC1OvJ3Nvm+CMOY9z8nurfImpZ3 3mL/pl3mqmvMj7u7i30pOVXlfdVUaAoRKbmyjOnXDGTOTogbPEkkf6PPJOKgdXYo 1ml+FmdAFPIyNJhJOMv9ME5rssZlLqpwxbwqKsRBnC3/eHLLXgJ2/kFL9dunPSDN upfSpptbBbuQJpsA6+OxUB3DKZ3VsxbOG7+b+2dIiKfsRkt1N2nQi4g/HJqbQ85P 8G7s4Twqo6DToUZdDcud/C+hsUsFkqRRh/0osLjuu99H3z4y0+F6rZSedwf5T4Wa zFU5IFiU92T4pA5Y0EnZxJS4MnB7jaVeSe+FLf23q7Y6Hi1nC3s4/rLxqUhKzO0V T02G+/hAyeFol2/6quwephzn3Vv+fiZ+hg7zEvDnnjP/TlmSwW/csLRTHXb1qu/z FXxb/Xs1f+/jPbjwqb0gA7vpzs7OgodWZtML+0FOxPwjyNBxWQQe/pbuppjtszQq 2iysS9UM =E9q4 -----END PGP SIGNATURE-----

3 2

Re: [SciPy-Dev] Efficient Toeplitz Matrix-Vector Multiplication
by Aditya Ravuri 21 Jan '20

21 Jan '20

Hi, Fastmat and pylops do not have all the toeplitz methods implemented yet (to my knowledge). If it is determined that scipy is not the appropriate place for these functions, I'm happy to contribute there. Regards, Aditya On Thu, Jan 16, 2020, 5:01 PM <scipy-dev-request(a)python.org> wrote: > Send SciPy-Dev mailing list submissions to > scipy-dev(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request(a)python.org > > You can reach the person managing the list at > scipy-dev-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. Re: cuSignal: GPU accelerated version of SciPy Signal package > (Juan Luis Cano) > 2. Re: Efficient Toeplitz Matrix-Vector Multiplication > (Semper Sebastian TU Ilmenau) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Jan 2020 15:20:07 +0100 > From: Juan Luis Cano <juanlu001(a)gmail.com> > To: SciPy Developers List <scipy-dev(a)python.org> > Subject: Re: [SciPy-Dev] cuSignal: GPU accelerated version of SciPy > Signal package > Message-ID: > < > CAFmivUWhSKC4kFcoFsE36gxaN9Jg37W9S8HFcdybsyMMUs-JkQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > The question is very broad, so I'm answering very broadly as well: I'm > happy that someone is splitting the SciPy sub-packages into separate > projects... I could see myself using cusignal (or cuintegrate, or > cuoptimize) just because of that, regardless of the GPU stuff. > > On 1/16/20, Robert Lucente - Pipeline.Com <rlucente(a)pipeline.com> wrote: > > https://github.com/rapidsai/cusignal > > > > I was wondering what people thought of cuSignal? > > > > If the topic is not appropriate for this mailing list, please consider > > replying directly to me. > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev(a)python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > > > > -- > Juan Luis Cano > > > ------------------------------ > > Message: 2 > Date: Thu, 16 Jan 2020 14:28:24 +0000 > From: Semper Sebastian TU Ilmenau <Sebastian.Semper(a)tu-ilmenau.de> > To: SciPy Developers List <scipy-dev(a)python.org> > Subject: Re: [SciPy-Dev] Efficient Toeplitz Matrix-Vector > Multiplication > Message-ID: <f1ba5b7e6eae42af9b9e7047b16aea4d(a)tu-ilmenau.de> > Content-Type: text/plain; charset="utf-8" > > You could just use > > > https://fastmat.readthedocs.io/en/latest/ > > > or > > > https://github.com/equinor/pylops > > > for efficient matrix-vector multiplications. ? > > ________________________________ > Von: SciPy-Dev <scipy-dev-bounces+sebastian.semper= > tu-ilmenau.de(a)python.org> im Auftrag von Aditya Ravuri < > aditya.ravuri(a)gmail.com> > Gesendet: Montag, 13. Januar 2020 23:01:22 > An: scipy-dev(a)python.org > Betreff: Re: [SciPy-Dev] Efficient Toeplitz Matrix-Vector Multiplication > > Hello, > > I've submit a draft PR for this on GitHub: > https://github.com/scipy/scipy/pull/11346 > > An issue has been raised there that adding more functions increases the > number of public functions, which is undesirable. If this mailing list can > confirm that SciPy will never support matrix methods for special matrices > over and above what's already implemented, I will move these lines to the > documentation for scipy.linalg.toeplitz as suggested. > > Regards, > > Aditya > > > > On Fri, Jan 10, 2020 at 12:40 AM Aditya Ravuri <aditya.ravuri(a)gmail.com > <mailto:aditya.ravuri@gmail.com>> wrote: > Hello, > > I'd like to add a function that performs efficient matrix-vector > multiplication of Toeplitz matrices with vectors using the circulant matrix > embedding trick. A simple example is attached. > > May I proceed with coding up an implementation for SciPy based on this > script? Is it something that could be added? > > An example application of this is in statistics, where stationary > processes have a Toeplitz covariance matrix. The efficient matrix vector > product can be used to compute log probabilities quickly and perhaps even > make use of conjugate gradient solvers in multivariate normals conditional > distributions. > > Regards, > > Aditya > > > -- > AdityaR >

3 2

Scientific Python: Using SciPy for Optimization by Bryan Weber at Real Python - Jan 20, 2020
by Robert Lucente 20 Jan '20

20 Jan '20

https://realpython.com/python-scipy-cluster-optimize/ I was wondering what people thought of the article

3 3