Mailman 3 February 2015 - SciPy-Dev

Adding routines for updating QR decompositions
by Eric Moore April 6, 2015

April 6, 2015

Hi, I've just submitted PR #4249 adding qr_update, qr_insert and qr_delete for performing rank-k updates, adding rows or columns and removing rows or colums. https://github.com/scipy/scipy/pull/4249 Comments welcome. Eric.

5 6

GSOC Optimization Project
by Nikolay Mayorov March 3, 2015

March 3, 2015

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

Spherical Harmonics and Condon-Shortley phase
by Freddy Rietdijk March 3, 2015

March 3, 2015

Hi, I'm working with auralization and Ambisonics, and the directivity patterns that are used with Ambisonics are spherical harmonics. Scipy has an implementation, scipy.special.sph_harm. Several definitions exist however for spherical harmonics, and the documentation does not specify which is implemented. A common definition that is used in quantum-mechanics includes the Condon-Shortley phase, which is a (-1)**m factor. http://en.wikipedia.org/wiki/Spherical_harmonics#Condon.E2.80.93Shortley_ph… For my purpose, Ambisonics, I need spherical harmonics without this factor. I found the code, which uses external functions, quite difficult to read. I did see `(-1)**mp` but I'm not sure now whether this really is the CS phase or not. Who knows which definition is used in `sph_harm`? Frederik

3 3

Returning the (approximate) inverse hessian from L-BFGS-B as a LinearOperator?
by Robert McGibbon Feb. 28, 2015

Feb. 28, 2015

Hey, tl;dir: thinking of writing a PR the following feature & looking for feedback first. In the L-BFGS-B minimizer, a low-memory approximation to the inverse hessian is used internally to determine the descent direction. Once the optimization terminates, none of this information is returned to the client though. I think it would be a nice to return a callable for the inverse hessian - vector product as a LinearOperator. The main use case for this that I have in mind is for computing standard errors in maximum likelihood statistical models. In this use case, you write down a likelihood function (and maybe its gradient), and pass it off to a minimizer to find the MLE. Getting standard errors in a scalar function of the parameters with the delta method <http://en.wikipedia.org/wiki/Delta_method>, requires computing a quadratic form like g(x)' H^{-1}(x) g(x), where g(x) is a vector (the gradient of the scalar function at the MLE) and the matrix H^{-1}(x) is the inverse of the Hessian at the MLE. For large-scale optimization of a likelihood with L-BFGS-B, the hessian is too big to calculate (or invert) explicitly, but a low memory approximation to the inverse is already available inside the optimizer, so I think it makes sense to expose it. The factored form of the BFGS matrix is kind of harry, so the most reasonable route is to return it as a LinearOperator that computes approximate inverse hessian - vector products. This calculation can be done pretty efficiently, I think, with the routine from section 4 of [1]. Does this make sense to people? Is it a desirable feature? I'm thinking of writing a PR for it, but I wanted to check here first before diving down the rabbit hole. [1] Nocedal, J. "Updating quasi-Newton matrices with limited storage <http://folk.uib.no/ssu029/Pdf_file/Nocedal80.pdf>."*Math. Comput.* 35.151 (1980): 773-782. -Robert

4 12

ANN: SfePy 2015.1
by Robert Cimrman Feb. 26, 2015

Feb. 26, 2015

I am pleased to announce release 2015.1 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 -------------------------- - support for multiple fields in isogeometric analysis - redesigned handling of solver parameters - new modal analysis example For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman and Contributors (*) (*) Contributors to this release (alphabetical order): Lubos Kejzlar, Vladimir Lukes

1 0

scipy.signal function naming
by Ralf Gommers Feb. 26, 2015

Feb. 26, 2015

Hi, Historically many names in scipy.signal have followed Matlab, which typically chooses short but very nondescriptive names. I would prefer to not keep doing that but instead choose readable names that fit with the rest of Scipy and Python. Recent examples from PRs, with in brackets a proposed alternative: grpdelay (group_delay) - https://github.com/scipy/scipy/pull/4549 place (place_poles) - https://github.com/scipy/scipy/pull/4295 ctrb (controllalbility_matrix) - https://github.com/scipy/scipy/pull/4515 obsv (observability_matrix) - https://github.com/scipy/scipy/pull/4515 upfirdn (rate_resample ?) - just discussed on list Thoughts? Ralf

8 7

Introduction: gsoc2015
by Karan Dev Feb. 26, 2015

Feb. 26, 2015

Hi, I'm final year B.Tech. Computer Science student. I want to participate in gsoc2015 by contributing to the organization. I am comfortable in Python, C/C++, JavaScript. I was wondering if anyone could suggest some bugs that are suitable for a beginner in this project? Thank You.

2 4

Re: [SciPy-Dev] Slow moment function in scipy.stats
by stefan Feb. 25, 2015

Feb. 25, 2015

Hi Ralf and Julian I have created a pull request (I hope, very limited experience with git and github). After doing so, I saw Julian's post. Indeed, pow is very accurate. I would argue that for all realistic uses of the moment function, the inaccuracies will be insignificant, but this is certainly up for discussion. BR, Stefan On 02/24/2015 08:17 AM, Ralf Gommers wrote: >/ Hi Stefan, />/ />/ />/ On Thu, Feb 19, 2015 at 12:55 PM, stefan <stefan.peterson(a)rubico.com <http://mail.scipy.org/mailman/listinfo/scipy-dev> />/ <mailto:stefan.peterson@rubico.com <http://mail.scipy.org/mailman/listinfo/scipy-dev>>> wrote: />/ />/ Hello list, />/ />/ First time poster here. Anyway, some time ago I noticed that the />/ scipy skewness function was a major bottleneck in an algorithm of />/ mine. Back then, I typed up my own replacement and thought no more />/ about it. Today, for some unknown reason, I decided to dig a little />/ deeper in this and found the major culprit to be the way moments are />/ computed, specifically the use of np.power. />/ />/ />/ np.power is indeed slow, see for explanations: />/ http://stackoverflow.com/questions/25254541/why-is-numpy-power-60x-slower-t… />/ http://stackoverflow.com/questions/26770996/why-is-numpy-power-slower-for-i… />/ />/ />/ I'd say that replacing one call to np.power with 6 lines of code to />/ achieve a ~10x speedup is a good tradeoff. Pull request is welcome:) />/ / its faster but also less accurate, the reason pow is so slow is that it has an accuracy of 0.5 ulp regardless of input, which a multiplication does not. But the argument can certainly be made that this is irrelevant especially as the moment computation performed here is numerically not that stable in the first place (uncorrected loss of significance in the subtraction, mean has an error in the order of the array size ...) maybe numpy should have a special integer case in power for such situations?

2 1

Re: [SciPy-Dev] Slow moment function in scipy.stats
by Robert Lucente Feb. 24, 2015

Feb. 24, 2015

1 0

Slow moment function in scipy.stats
by Robert Lucente Feb. 24, 2015

Feb. 24, 2015

Why must it be an either or? Why not have 2 options specified via a parameter 1) Fast but inaccurate 2) Slow but more accurate

3 2