Mailman 3 March 2015 - SciPy-Dev

Re: [SciPy-Dev] GSOC Optimization Project
by Richard Tsai 09 Mar '15

09 Mar '15

Hi Ralf, > Here they are on Melange: > > http://www.google-melange.com/gsoc/proposal/review/org/google/gsoc2014/rich… > > http://www.google-melange.com/gsoc/proposal/review/org/google/gsoc2014/jenn… > I think that that is and will remain publicly accessible, but I'm not 100% They should be: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/richardt… http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/jennysto… > sure. The blogs of Richard and Jenny (last year's students) may also be > interesting: > http://richardtsai.info/ > http://euphoricjenny.blogspot.com/ > > Cheers, > Ralf And for Nikolay and other potential GSoC students: I’m a GSoC student for scipy last year. I will not be able to participate this year due to some personal arrangements (internship etc.). But I’m willing to help you with your preparation. Feel free to ask if you have any questions. Good luck! Regards, Richard

3 3

Allow specification of matrix permutation method in scipy.sparse.linalg.eigs()
by Paul Nation 08 Mar '15

08 Mar '15

As of SciPy 0.15, there are now a few matrix reordering methods in the scipy.sparse.csgraph module. Some reorderings, such as the reverse_cuthill_mckee ordering are similarity transforms (symmetric permutations), and can be used when solving the generalized eigenvalue problem using eigs() or eigsh(). In some cases, the reduced bandwidth and profile can lead to a considerable reduction in fill-in compared to other methods, such as the default COLAMD. However, as it stands now, these functions do not allow one to specify the matrix ordering, and always default to COLAMD as the sparse LU inverse routine simply calls: self.M_lu = splu(M) I am writing to see if a pull request that will allow for the user to set the reordering used in eigs() and eigsh() via the permc_spec kwarg in splu is something that people are interested in. Best regards, Paul

2 3

Exact p-values in Mann-Whitney U test
by Szymon Łęski 05 Mar '15

05 Mar '15

Hello, I wrote a Python implementation of exact p-values in Mann-Whitney U test. The current test (scipy.stats.mannwhitneyu) uses normal approximation, and is valid only for sample size > 20 (as stated in notes). The exact version is correct also for small samples. I believe this would be a useful thing to include in scipy.stats. However, the current version is still better for very large samples, so I think both versions should be kept. I wanted to ask for opinion on what would be the best way to include the new version. Separate function? Optional argument controlling which method is used? Heuristics based on sample sizes? I have put my script, and the paper I based the implementation on, in this Dropbox folder: https://www.dropbox.com/sh/0zxp9u8sliwijl5/AAARecyrwQ2z-8xU-LbKOpWna?dl=0 Feedback appreciated! Best regards, Szymon Leski

4 4

Updates to VODE and ZVODE solvers in single step mode
by Paul Nation 05 Mar '15

05 Mar '15

When using the single-step mode in either the VODE or ZVODE ode solver, the default mode (2) called in: def step(self, *args): itask = self.call_args[2] self.call_args[2] = 2 # Step mode is here r = self.run(*args) self.call_args[2] = itask return r results in taking a single step that (typically) goes beyond the output time requested in the solver. When doing, for example, monte carlo algorithms, this leads to a big performance hit because one must take a step back, reset the solver and then use the normal mode to go to the requested stop time. Instead, these solvers support a mode (5) that will never step beyond the end time. The modified step function is in that case: def step(self, *args): itask = self.call_args[2] self.rwork[0] = args[4] #Set to stop time self.call_args[2] = 5 #Set single step mode to stop at requested time. r = self.run(*args) self.call_args[2] = itask return r Currently in order to implement this, one needs to create their own ODE integrator subclass of VODE or ZVODE, overload the step function, then create an ode instance and then finally add the custom integrator using ode._integrator. I think supporting both options natively would be a nice thing to have in SciPy. In addition, often it is not necessary to do a full reset of the ode solver using ode.reset(). Often times one just needs to change the RHS vector (and possibly the time) and set the flag for the solver to start anew (ode._integrator.call_args[3] = 1). This to results in a large performance benefit for things like monte carlo solving. Right now I need to call ode._y = new_vec ode._integrator.call_args[3] = 1 when I want to accomplish this. Adding support for a “fast reset” might also be a good thing to have in SciPy. All of the code to accomplish such things are already being used in the QuTiP monte carlo solver(https://github.com/qutip/qutip/blob/master/qutip/mcsolve.py <https://github.com/qutip/qutip/blob/master/qutip/mcsolve.py>) and would therefore be fairly painless to add to SciPy. Best regards, Paul

2 6

Allow specification of matrix permutation method in scipy.sparse.linalg.eigs()
by Paul Nation 05 Mar '15

05 Mar '15

As of SciPy 0.15, there are now a few matrix reordering methods in the scipy.sparse.csgraph module. Some reorderings, such as the reverse_cuthill_mckee ordering are similarity transforms (symmetric permutations), and can be used when solving the generalized eigenvalue problem using eigs() or eigsh(). In some cases, the reduced bandwidth and profile can lead to a considerable reduction in fill-in compared to other methods, such as the default COLAMD. However, as it stands now, these functions do not allow one to specify the matrix ordering, and always default to COLAMD as the sparse LU inverse routine simply calls: self.M_lu = splu(M) I am writing to see if a pull request that will allow for the user to set the reordering used in eigs() and eigsh() via the permc_spec kwarg in splu is something that people are interested in. Best regards, Paul

1 0

Hiearchical Clustering issue
by Rishabh SHARMA 04 Mar '15

04 Mar '15

Hello I have this question,could someone help? I am using scipy.cluster.hiearchical ***I have a distance matrix in squareform 't' as array([[ 0.00000000e+00, 3.44600000e+03, 6.75000000e+02, 2.06000000e+03, 2.24205600e+06], [ 3.44600000e+03, 0.00000000e+00, 2.77300000e+03, 1.75000000e+03, 2.23959500e+06], [ 6.75000000e+02, 2.77300000e+03, 0.00000000e+00, 1.49100000e+03, 2.24154200e+06], [ 2.06000000e+03, 1.75000000e+03, 1.49100000e+03, 0.00000000e+00, 2.24127000e+06], [ 2.24205600e+06, 2.23959500e+06, 2.24154200e+06, 2.24127000e+06, 0.00000000e+00]]) ***I used this cmd z=linkage(t,method='complete') //t is the above matrix z array([[ 0.00000000e+00, 2.00000000e+00, 1.39718861e+03, 2.00000000e+00], [ 1.00000000e+00, 3.00000000e+00, 3.53484724e+03, 2.00000000e+00], [ 5.00000000e+00, 6.00000000e+00, 5.85696654e+03, 4.00000000e+00], [ 4.00000000e+00, 7.00000000e+00, 5.00927065e+06, 5.00000000e+00]]) **Question: why in the first row of z where objects 0,2 are merged the distance is shown as 1.397e+3[3rd element of 1st row] whereas it should the distance given by t[0][2] as in distance matrix(these objects are original objects/leaf nodes) Thanks PS: I posted the question in user list,but no one seems to have the answer.In any case sorry for spamming dev list.

2 2

scipy.signal - Tukey Window
by Eric Quintero 04 Mar '15

04 Mar '15

Hi all, I’ve submitted a PR (#4584 <https://github.com/scipy/scipy/pull/4584>) to add the Tukey window <http://en.wikipedia.org/wiki/Window_function#Tukey_window> to scipy.signal’s repertoire. If you have any opinion about its implementation or API, I’d be glad to hear it! Regards, Eric Quintero

2 1

Distance to uncontrollability
by Irvin Probst 04 Mar '15

04 Mar '15

Hi, do you know if an implementation of Gu/Mengi's algorithm to compute the distance to uncontrollability [1] for a linear system would be of any interest for the average scipy user ? Or is it enough for almost anyone to be able to compute the controllability index of a system using the staircase algorithm ? [1] Copy/paste of Gu/Mengi's paper: The distance to uncontrollability for a linear control system is the distance (in the 2-norm) to the nearest uncontrollable system. We present an algorithm based on methods of Gu and Burke–Lewis–Overton that estimates the distance to uncontrollability to any prescribed accuracy. The new method requires O(n4) operations on average, which is an improvement over previous methods which have complexity O(n6), where n is the order of the system. Numerical experiments indicate that the new method is reliable in practice. Source: http://home.ku.edu.tr/~emengi/papers/fast_dist_uncont.pdf

1 0

GSoC ideas
by Cera, Tim 03 Mar '15

03 Mar '15

These ideas are things that I wanted to tackle, but they might instead get better play as part of the GSoC program. 1. In the scipy.ndimage package there are many functions that have a 'mode' option to define the padding process to use to minimize edge issues. I think would be better to use the pad function in numpy. With this approach, as improvements are made in the numpy pad function, the scipy.ndimage package benefits. 2. Something that could be useful to me is to update ODRPACK to ODRPACK95. ODRPACK95 can be found at http://www.netlib.org/toms/869.zip. At the same time suggest to implement the new odr in scipy.optimize. License is not defined in the ODRPACK95 software but I found this in the netlib FAQ: *2.3) Are there restrictions on the use of software retrieved from Netlib?* Most netlib software packages have no restrictions on their use but we recommend you check with the authors to be sure. Checking with the authors is a nice courtesy anyway since many authors like to know how their codes are being used. Kindest regards, Tim

2 1

GSOC Optimization Project
by Nikolay Mayorov 03 Mar '15

03 Mar '15

Hi! I want to clarify some things about GSOC project idea related to Levenberg-Marquardt algorithm. 1) Why do we want anything but current leastsq based on MINPACK? Looks like it is answered here: https://github.com/scipy/scipy/pull/90 "When we call python from FORTRAN, a lot of magic has to be done. This magic prevents us, for example, to properly pass exceptions through the FORTRANcode." Could you comment more on that perhaps? 2) What's wrong with https://github.com/scipy/scipy/pull/90? Why it is stalled? What do you expect from GSOC student to do better / different? Again partially answered in PR: "It's stalled: the algorithmic part is OK, the new interfaces proposed controversial.", "However, this could perhaps be extended to Levenberg-Marquardt supporting sparse Jacobians" 3) Based on 2: how GSOC student should proceed with interface issue? I mean there weren't any strong opinions and it was on the list for so long. I have no idea how to come up with a good solution all of a sudden. 4) Do you believe that code written during GSOC should be based on PR mentioned? --- That's what I come up so far about the work during GSOC: - Decide on interface part- Add new features to the PR from pv (probably just one of them): Sparse Jacobians support Constraints support- Implement a solid test suite --- I would appreciate your answers, Nikolay.

3 5