Mailman 3 May 2014 - SciPy-Dev

Re: [SciPy-Dev] removing umfpack wrapper
by Robert Cimrman 23 Nov '14

23 Nov '14

On 11/12/2013 11:22 PM, Ralf Gommers wrote: > On Tue, Nov 12, 2013 at 10:20 AM, Robert Cimrman <cimrman3(a)ntc.zcu.cz>wrote: > >> Hi Ralf, >> >> On 11/10/2013 04:36 PM, Ralf Gommers wrote: >>> Hi all, >>> >>> This is long overdue, but I think it's time to remove the UMFPACK wrapper >>> before the next release. I'd like some feedback on how to do that and to >>> what package (if any) to point existing users. >>> >>> As for why to remove the wrapper, see: >>> https://github.com/scipy/scipy/issues/3002 >>> http://permalink.gmane.org/gmane.comp.python.scientific.user/20451 >>> Short summary: UMFPACK changed from a BSD-compatible license to GPL at >> some >>> point. >>> >>> The deprecation warning in sparse.linalg has been referring people to >>> scikits.umfpack until now, however that package has disappeared >> completely >>> as far as I can tell. I suspect it was in the old scikits svn repo and >> was >>> never moved before that was killed. The alternatives seems to be >> Pysparse ( >> >> I missed that the scikit was lost in transition... >> >> How much work would be to move it to the new site - move from SVN to git, >> and? >> I would be willing to do it, if there is interest. >> > > Hi Robert, I think the moving wouldn't be a lot of work (assuming svn > access can still be arranged). If you'd revive the scikit it's not a > one-time effort though - it's only useful if the code is being maintained > imho. That can still be low effort perhaps, but with reviewing some PRs, > maintenance releases, putting it on pypi, etc. I'd expect at least an hour > a week or so. > > Are there scikits.umfpack users now? Would it make sense to salvage > whatever is useful from the scikit and contribute it to pysparse instead? We are using it in sfepy as the default direct solver. It seems to me that the pysparse interface requires the input matrix to be in the LL (linked list) format, which is unfortunate for us, as we use CSR. The scipy (and former scikit) umfpack wrappers have used CSR, so no copies were necessary. (After all, I have created the original scipy wrappers to be used from sfepy in the first place...) So in case others are not interested in having the scikit, I can see two possible solutions from my perspective: either enhance pysparse interface to allow CSR as well, or move the wrappers to sfepy (which I maintain anyway, but swig -> cython conversion would be needed). Not sure yet which solution I prefer. Cheers, r. > Cheers, > Ralf >> >> Cheers, >> r. >> >>> http://pysparse.sourceforge.net) and PyUBlasExt ( >>> https://pypi.python.org/pypi/PyUblasExt). Scikits.sparse is dead(-ish) >> and >>> doesn't wrap umfpack it looks like. PyUBlasExt has something that looks >>> like a wrapper but for C++ (?). So can we refer people to pysparse? >>> >>> Other question: do we call Pysparse instead of scikits.umfpack when >>> available? And if so, by default or not? Or do we rip out everything that >>> sits under useUmfpack=True? >>> >>> Cheers, >>> Ralf

2 5

Linalg: function for diagonalize hermitian commuting matrices simultaneously
by Lars-Hendrik Frahm 07 Oct '14

07 Oct '14

Dear SciPy Developers, I like to contribute a function for simultaneously diagonalize a set of hermitian commuting matrices. Especially for matrices with degenerate eigenvalues. Is there need for something like that in SciPy ? I think it could be helpful for someone else and I didn't find it in recent SciPy versions or on the mailing list. Hope to hear from you.

3 3

Bootstrap confidence limits code
by Constantine Evans 04 Oct '14

04 Oct '14

Hello everyone, A few years ago I implemented a scikit for bootstrap confidence limits (https://github.com/cgevans/scikits-bootstrap). I didn’t think much about it after that until recently, when I realized that some people are actually using it, and that there’s apparently been some talk about implementing this functionality in either scipy.stats or statsmodels (I should thank Randal Olson for discussing this and bringing it to my attention). As such I’ve rewritten most of the code, and written up some docstrings. The current code can do confidence intervals with basic percentile interval, bias-corrected accelerated, and approximate bootstrap confidence methods, and can also provide bootstrap and jackknife indexes. Most of it is implemented from the descriptions in Efron and Tibshirani’s Introduction to the Bootstrap, but the ABC code at the moment is a port from the modified-BSD-licensed bootstrap package for R (not the boot package) as I’m not entirely confident in my understanding of the method. And so, I have a few questions for everyone: * Is there any interest in including this sort of code in either scipy.stats or statsmodels? If so, where do people think would be the better place? The code is relatively small; at the moment it is less than 200 lines, with docstrings probably making up 100 of those lines. * Also, if so, what would need to be changed, added, and improved beyond what is mentioned in the Contributing to Scipy part of the reference guide? I’m never a fan of my own code, and imagine quite a bit would need to be fixed; I know tests will need to be added too. In addition, I have a few questions about what would be better practice for the API, and I haven’t really found a guide on best practices for Scipy: * When I started writing the code, I wrote a single function ci for confidence intervals, with a method argument to choose the method. This is easy for users, especially so that they don’t have to look through documentation to realize that BCA is the most generally useful method (at least from everything I’ve read) and that there really isn’t any reason to use many of the simpler methods. However, ABC takes different paramenters, and needs a statistic function that takes weights, which makes this single-function organization trickier. At the moment, I have a separate function for ABC. Would it be better to split up all the methods to their own functions? * ABC requires a statistic function that takes weights. I’ve noticed that things like np.average takes a weights= argument. Would it be better to require input of a stat(data,weights) function, or input of a stat(data,weights=) with weights as a named argument? The latter would be nice in terms of allowing the same function to be used for all methods, but would make it impossible to use a lambda for the function. Is there some other method of doing this entirely? * Are there any missing features that anyone thinks should be added? I apologize if much of this is answered elsewhere, I just haven’t found any of it; I also apologize if this is far too long-winded and confusing! Regards, Constantine Evans

4 3

Levenberg-Marquardt Implementation
by Nico Del Piano 18 Jun '14

18 Jun '14

Hi all, I am Nicolas Del Piano, and currently studying the last year of computer science career. I was searching for a GSoC project that involves mathematical concepts, and I found one very interesting. I have experience on python programming and I studied calculus, so I have a background of the problem context. I am interested on the implementation and testing of Levenberg-Marquardt / trust region nonlinear least squares algorithm. Here are some useful links, that I have searched to having a reference about the problem: http://ananth.in/docs/lmtut.pdf (Introduction) www.cs.nyu.edu/~roweis/notes/lm.pdf (Optimization) http://scribblethink.org/Computer/Javanumeric/index.html (java implementation) I would be glad if there is an interested mentor to discuss the issues, talk about the problem and its possible implementations, and provide me some support and guide. Thanks! Regards.

10 21

Multivariate Ctypes PR
by Brian Lee Newsom 28 May '14

28 May '14

Hello all, In regards to the multivariate ctypes PR ( https://github.com/scipy/scipy/pull/3262), Nathan and I have addressed all the issues presented earlier regarding this code. Tests have been added and integrated into the build system and are working and passing. As for merging the code paths between Python and Ctypes, my opinion is that this is a route where little progress can be made. I have removed the need for an extra stack storage struct (ZStorage) and am now using the one previously used for python (QStorage). Other than that, the initialization, call, and restore all require different enough behaviors for the Python vs. the C that I do not believe it is feasible to merge them. If anyone else has a different opinion I'd love to hear your thoughts. Ideally a route that could be explored soon would be compiling the Python into C with code generation and handling that automatically, and in this way the complexities could be removed. However with CTypes this possibility seems extremely challenging or impossible, and Nathan and I believe that this should be held off until Cython can be supported. At it's present state, this feature is usable, tested, and documented. Let me know if anything else can be done to hasten it's inclusion. Thanks, Brian

3 2

ANN: SfePy 2014.2
by Robert Cimrman 23 May '14

23 May '14

I am pleased to announce release 2014.2 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. The code is based on NumPy and SciPy packages. It is distributed under the new BSD license. This release brings a preliminary support for isogeometric analysis - a recently developed computational approach that allows using the NURBS-based domain description from CAD design tools also for approximation purposes similar to the finite element method. 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 -------------------------- - preliminary support for isogeometric analysis - improved post-processing and visualization script for time-dependent problems with adaptive time steps - three new terms 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): Vladimír Lukeš

1 0

Win32 binaries for Python 3.3, 3.4?
by Matthew Brett 21 May '14

21 May '14

Hi guys, Am I right in thinking we don't have binary installers for Pythons 3.3 and 3.4 for Scipy 0.14.0? Is this because of the need for VS 10? [1] Are there plans for these guys? Can I help? Cheers, Matthew [1] http://matthew-brett.github.io/pydagogue/python_msvc.html#visual-studio-ver…

3 6

The performance of Cython typed memoryview
by Richard Tsai 20 May '14

20 May '14

Hi all, I'm rewriting cluster.vq in Cython now. I've been doing some experiments on Cython recently and I encountered a problem. I tried to implement vq.vq with Typed Memoryview but it seemed to be much slower than the original implementation, which accesses the array through C pointers and updates the pointers after every iteration. (See https://github.com/scipy/scipy/blob/master/scipy/cluster/_vq_rewrite.pyx#L51) I checked the C code Cython generated and I noticed that Cython generated some things like `*(arr.data + i * arr.strides[0] + j * arr.strides[1])` for memoryview accesses and it is inefficient when looping through the array. Is there any workaround? Or should I abandon Typed Memoryview in this case? BTW, in order to call BLAS routines in Cython conveniently, I generate a cblas.pxd with cwrap (https://github.com/geggo/cwrap), but it seems improper to leave it in the cluster directory (may be useful somewhere else). Is there a suitable place for it? Ralf said I can put a script there but then cwrap will become a build dependency and it seems unnecessary. Regards, Richard

1 0

Re: [SciPy-Dev] [SciPy-User] ANN: Weave 0.15.0 release
by Robert Kern 14 May '14

14 May '14

On Wed, May 14, 2014 at 10:15 AM, srean <srean.list(a)gmail.com> wrote: > Very happy to see this, I thought weave had been relegated to abandon-ware. > Although Weave did not get a lot of love I have found it very useful. Actually, it's even more abandoned than before. It's been carved off into its own project such that its abandonment doesn't hold up the rest of scipy. See Ralf's last paragraph: > On Sun, May 11, 2014 at 3:45 PM, Ralf Gommers <ralf.gommers(a)gmail.com> > wrote: >> Note that the Scipy developers are not planning to make any further >> improvements >> to Weave. They may however merge pull requests and create maintenance >> releases for urgent issues. If someone is interested in maintaining Weave, >> that would be very welcome. Questions and discussions relating to Weave >> should >> be directed to the scipy-dev mailing list (see >> http://scipy.org/scipylib/mailing-lists.html). If you wish to take up maintenance of weave to save it from its abandonment, please let us know, and we will give you admin rights to the repo. Thanks! -- Robert Kern

1 0

Re: [SciPy-Dev] Consideration of differential evolution minimizer being added to scipy.optimize.
by Andrew Nelson 13 May '14

13 May '14

Dear all, I've put some more work into the differential evolution (another global optimizer) code I would like to contribute to scipy.optimize. Since this is the first time I'm contributing to scipy I'd would like a code review, with a view to putting in a pull request in the near future. The changes/additions I've made are at (under files changed): https://github.com/andyfaff/scipy/compare/scipy:master...master Some of the comments when I first discussed this were for benchmarking DE to see if it had comparable performance to basinhopping. To that end I've added some code and extra test functions (http://en.wikipedia.org/wiki/Test_functions_for_optimization) for benchmarking global optimizers. You can see the output of the benchmarking at: https://gist.github.com/andyfaff/9439229 >From the test functions differential_evolution doesn't do too badly, especially when no gradient is available for the function to be minimized. Having said that, I do recognise that you sometimes need to tune the optimizer for a specific problem. My specific motivation for adding differential_evolution is for curve_fitting. For most of my problems function expense isn't enormous, so I don't regard number of function evaluations to be all that important. In those cases finding the global minimum is the key. I've tried comparing basinhopping to DE for harder curvefitting problems and in the example I tried the number of function evaluations was a lot smaller for DE (http://www.itl.nist.gov/div898/strd/index.html - Thurber). (One can always use Levenberg Marquardt to 'polish' the end result) Of course, there are problems where function expense is enormous. However, if that is truly horrendous one can always use the callback function to terminate if you think one is getting towards a solution. cheers, Andrew. -- _____________________________________ Dr. Andrew Nelson _____________________________________

3 2