Mailman 3 March 2017 - SciPy-Dev

migration of all scipy.org mailing lists
by Ralf Gommers March 22, 2017

March 22, 2017

Hi all, The server for the scipy.org mailing list is in very bad shape, so we (led by Didrik Pinte) are planning to complete the migration of active mailing lists to the python.org infrastructure and to decommission the lists than seem dormant/obsolete. The scipy-user mailing list was already moved to python.org a month or two ago, and that migration went smoothly. These are the lists we plan to migrate: astropy ipython-dev ipython-user numpy-discussion numpy-svn scipy-dev scipy-organizers scipy-svn And these we plan to retire: Announce APUG Ipython-tickets Mailman numpy-refactor numpy-refactor-git numpy-tickets Pyxg scipy-tickets NiPy-devel This will happen asap, likely within a day or two. So two requests: 1. If you see any issue with this plan, please reply and keep Didrik and myself on Cc (we are not subscribed to all lists). 2. If you see this message on a numpy/scipy list, but not on another list (could be due to a moderation queue) then please forward this message again to that other list. Thanks, Ralf

1 0

Sketching-based Matrix Computations
by Jordi Montes March 22, 2017

March 22, 2017

*# I started this discussion on GitHub <https://github.com/scipy/scipy/issues/7122>. This email is a digested version of the conversation to check what people think about this on the mailing list.* TL;DR: *I think having an implementation for some randomize matrix algorithms would be great. I would like to discuss if the community finds it useful too.* Hello, I am Jordi. I have been working on a xdata <http://www.darpa.mil/program/xdata> open source project for the last year called libSkylark <https://xdata-skylark.github.io/libskylark/>. The library is suitable for general statistical data analysis and optimization applications, but it is heavily focused on distributed systems. *Randomized matrix algorithms* have been a hot topic in research the last years. Recent developments have shown their utility in large-scale machine learning and statistical data analysis applications. Although many ML applications would take advantage of the implementation of these algorithms the scope of them goes far beyond. I believe it would be a good idea integrate some of them in Scipy and I would like to know the opinion of others to check if it would be worth it. To my eyes, Randomized Numerical Linear Algebra is big/useful enough to has its submodule. However, this is something that the community has to decide. Meanwhile, to demonstrate that these methods can be useful I would implement them under, scipy.linalg where the scipy linear algebra functions live. The idea is to bring value since the first moment. I will implement Blendenpik <http://epubs.siam.org/doi/10.1137/090767911>, a least-squares solver based on these techniques that outperforms LAPACK by significant factors and scales significantly better than any QR-based solver. The proposal is: - Implement CWT <http://delivery.acm.org/10.1145/2490000/2488620/p81-clarkson.pdf?ip=198.4.8…> . CWT lets us create a matrix *S* such as *SA* is shorter than *A but conservating some properties*. - Compute *QR = SA* using scipy. - From here, there are two potential features: - Implement Blendenpik <http://epubs.siam.org/doi/10.1137/090767911> for solving Linear Square problems faster without losing any accuracy. - Compute the squared row norms to obtain leverage scores. Would be better to start with Blendenpik, because it solves a more common problem by far. I am thinking about doing it for sparse matrices first because CWT can take advantage of it. However, I wonder if the QR method on script takes advantage of sparsity too. I have already set up the development environment so I could start as soon as we decide what to do. As I said, I am open to discussion, so anyone who could be interested is welcome. Thank you, Jordi.

1 0

Re: [SciPy-Dev] CUTEst in Scipy
by Antonio Ribeiro March 21, 2017

March 21, 2017

Thank you for the insightful answer Nikolay! I agree with you that include CUTEst dependency to Scipy could be troublesome, and furthermore it could be very painful to make this interface work well for more than one operational systems... The solution of implementing and store the benchmark somewhere else is not ideal but seems a good option because it make things simpler. About the use of NIST test suite: Thank you for the suggestion Andrew, but I don't think it is a good test suit for the methods I intend to implement. 2017-03-20 19:23 GMT-03:00 <scipy-dev-request(a)scipy.org>: > Send SciPy-Dev mailing list submissions to > scipy-dev(a)scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.scipy.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request(a)scipy.org > > You can reach the person managing the list at > scipy-dev-owner(a)scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. CUTEst in Scipy (Antonio Ribeiro) > 2. Re: CUTEst in Scipy (Nikolay Mayorov) > 3. Re: CUTEst in Scipy (Andrew Nelson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Mar 2017 15:24:14 -0300 > From: Antonio Ribeiro <antonior92(a)gmail.com> > To: scipy-dev(a)scipy.org > Subject: [SciPy-Dev] CUTEst in Scipy > Message-ID: > <CAFStupFHFEk-JpGFgPikTvi5D+zq9VUG_K94k=7Pu+A5X79zPQ@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I am developing my google of summer proposal about constrained optimisation > in Scipy > and it will be very important to have a good set of benchmarks. > > There is a great library with diverse optimisation benchmarks called CUTEst > <https://ccpforge.cse.rl.ac.uk/gf/project/cutest/wiki/>. It is under LGPL > 2.1 license. > > This CUTEst library include a huge amount of problem sets > and is often used in optimisation papers. Furthermore, many of the > available > optimisation software provide some interface to it. I am interested in > using problems from this set in my project and I want to ask how > should I proceed? > > 1) Select a subset of tests from the CUTEst library and implement them in > native python under scipy. > > 2) Include some interface to CUTEst in scipy. By what I understand LGPL > license is > more restrictive than BSD-3 used by Scipy. In this case, could we ask for > permission? > > 3) There is an interface for CUTEst implemented in the library pyOpus > (under GPL3 license) > <http://fides.fe.uni-lj.si/pyopus/download1.html>. Since this is a > library > external to Scipy (with an incompatible license) how should I proceed in > this case: can I make my benchmarks dependent on it? Can we ask permission > for include this interface in Scipy? > > Any suggestions on how to proceed and what to include in my proposal is > very welcome. > > Ant?nio >

1 0

Re: [SciPy-Dev] SciPy-Dev Digest, Vol 161, Issue 28
by Matt Newville March 20, 2017

March 20, 2017

Date: Tue, 21 Mar 2017 09:21:59 +1100 > From: Andrew Nelson <andyfaff(a)gmail.com> > To: SciPy Developers List <scipy-dev(a)scipy.org> > Subject: Re: [SciPy-Dev] CUTEst in Scipy > Message-ID: > <CAAbtOZc2JnOvgvzH4jEB3mpLBm_YZNCj9xy1q_PG2YN2+EMD4w@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > There are some least squares problems from the NIST test suite in the > benchmarks/benchmarks/go_benchmark_functions, but they're couched in terms > of a simple scalar (chi2) minimisation problem, and they are all bounded > problems. > > The NIST StRD test suite ( http://www.itl.nist.gov/div898/strd/nls/nls_main.shtml) could be considered for inclusion as a test suite for scipy.optimize. These are generally small but non-trivial problems for unconstrained non-linear optimization. Each of the 20+ data sets comes with 2 sets of starting values for the variables and certified values for both best fit values and estimated uncertainties. I believe that none of the optimizers in scipy.optimize will get the right answer to published precision in every case, though leastsq and least_squares can solve most of these problems reasonably well from at least 1 of the 2 starting points. This may imply that these problems are not "sparse" in the sense of what (as far as I understand) the GSOC project intends to focus on. But, they are a good set of test cases to include in any assessment of an optimization algorithm. The NIST StRD datasets are public domain. There is existing test code in lmfit to use these data sets with most of the scipy optimizers. This could easily be modified to be part of scipy. See https://github.com/lmfit/lmfit-py/tree/master/NIST_STRD and https://github.com/lmfit/lmfit-py/blob/master/tests/test_NIST_Strd.py for more details. Also, note that the tests focus only on the quality of the results. They may record number of iterations, but make no attempt to benchmark the runtime. I think that migrating this test suite to scipy would not be a huge undertaking, though I cannot say whether that is an appropriate use of time for the proposed GSOC project. Cheers, --Matt

1 0

NumPy 1.12.1 released
by Charles R Harris March 18, 2017

March 18, 2017

Hi All, I'm pleased to announce the release of NumPy 1.12.1. NumPy 1.12.1 supports Python 2.7 and 3.4 - 3.6 and fixes bugs and regressions found in NumPy 1.12.0. In particular, the regression in f2py constant parsing is fixed. Wheels for Linux, Windows, and OSX can be found on pypi. Archives can be downloaded from github <https://github.com/numpy/numpy/releases/tag/v1.12.1>. *Contributors* A total of 10 people contributed to this release. People with a "+" by their names contributed a patch for the first time. * Charles Harris * Eric Wieser * Greg Young * Joerg Behrmann + * John Kirkham * Julian Taylor * Marten van Kerkwijk * Matthew Brett * Shota Kawabuchi * Jean Utke + *Fixes Backported* * #8483: BUG: Fix wrong future nat warning and equiv type logic error... * #8489: BUG: Fix wrong masked median for some special cases * #8490: DOC: Place np.average in inline code * #8491: TST: Work around isfinite inconsistency on i386 * #8494: BUG: Guard against replacing constants without `'_'` spec in f2py. * #8524: BUG: Fix mean for float 16 non-array inputs for 1.12 * #8571: BUG: Fix calling python api with error set and minor leaks for... * #8602: BUG: Make iscomplexobj compatible with custom dtypes again * #8618: BUG: Fix undefined behaviour induced by bad `__array_wrap__` * #8648: BUG: Fix `MaskedArray.__setitem__` * #8659: BUG: PPC64el machines are POWER for Fortran in f2py * #8665: BUG: Look up methods on MaskedArray in `_frommethod` * #8674: BUG: Remove extra digit in `binary_repr` at limit * #8704: BUG: Fix deepcopy regression for empty arrays. * #8707: BUG: Fix ma.median for empty ndarrays Cheers, Chuck

1 0

GSoC'17: Circular statistics
by Vladislav Iakovlev March 16, 2017

March 16, 2017

Hello! My name is Vladislav Iakovlev. I am a master student of Department of Applied Math, HSE University, Moscow, Russia. I have never contributed to open source projects, but I would be happy to start it with SciPy. I noticed that existing functionality for circular statistics is insufficient. So, I want to suggest an idea for GSoC: implement it to scipy.stats. My plan is to do it through the next steps: 1) Develop the class rv_circular, analogous to rv_continuous adjusted to circular statistic functions. 2) Develop derived classes for circular distributions. 3) Develop point estimations and statistical tests functions. During the summer, I assume to implement materials from chapters 1-8 of the book “MARDIA, K. V. AND JUPP , P. E. (2000), Directional Statistics, John Wiley”, documentation and unit tests for it. Is this idea interesting for the Community? I’m glad to any feedback.

4 4

GSoC17 scipy.diff & B-splines questions
by Evgeny Zhurko March 16, 2017

March 16, 2017

Hi, My name's Evgeny Zhurko. I'm a 3'rd year student of the Belarusian State University of Informatics and Radioelectronics, Minsk, Belarus. I want to participate in GSoC with Scipy. About scipy.diff: It's not necessary to invent the wheel, so, as for me, the best way to implement this idea will be moving numerical and algorithm differentiation from numdifftools to scipy with some changes (new class NDerivative for n> = 1 - from GSOC15 discussion). API proposed by Maniteja Nandana (GSoC15) i find reasonable, but with small controversal questions: I think it's not necessary to separate `richardson` as a special method, because we can include richardson interpolation as a required part of computing. N (derivative order) was proposed 1-4. Numdifftools can compute derivative of order 1-10, so scipy will compute the same :-) Current scipy functionality has parameter "method" as '2-point' or '3-point'. I adhere to the naming 'forward', 'backward', 'central', 'complex', 'multicomplex' for parameter "method". Boundary optional param should be added in new API as a change numdifftools. Estimates: it's not very hard task to move numdifftools to scipy with small changing functionality. So, optional part of idea can be partially implemented as required part of idea. About B-spline improvement: Do you want to be able to read the relevant literature? :-) Generally speaking, i find this idea the most interesting and the hardest for me, because i never worked with splines before. Best Regards, Evgeny Zhurko

3 3

Opinions on deprecating and removing scipy.interpolate.interpolate_wrapper?
by Evgeni Burovski March 16, 2017

March 16, 2017

Hi, Here's this corner of scipy.interpolate: In [1]: from scipy.interpolate.interpolate_wrapper import <TAB> _interpolate linear absolute_import logarithmic atleast_1d_and_contiguous nearest block np block_average_above print_function division These functions are tested, but are not documented, and not exposed to the top level namespace. These were added in 2008 and have only received a handful maintenance touches since then. They look like bits and pieces from some larger effort which went unfinished and abandoned. Here's a PR which proposes to deprecate and eventually remove them, https://github.com/scipy/scipy/pull/7187 Are you using these functions? Would you miss them if they're gone? Do you see a benefit from them being kept? Would you use them if they are documented? Please speak up. Cheers, Evgeni

1 0

[GSoC 2017] Nose to Pytest Migration - conclusions from previous thread
by Karan Desai March 13, 2017

March 13, 2017

Hello developers, I wrote an introductory thread about two weeks ago, expressing my interest in this project. The thread grew very huge and it took me a while to aggregate the suggestions and views of all the fellow developers of the community. Meanwhile, I also inspected the test suite of scipy. I am putting up my conclusions and thoughts further. As an added information, I should specify, as earlier that I have dropped nose and integrated pytest properly into "joblib". Some of the test suite designs were positively affirmed by a Pytest core developer on the issue thread. Here they go: 1. The homepage of Nose after its release of 1.3.7 states that it is no longer maintained. I see no reason continue supporting it, as now or later we will have to let it go. Also I am sure many prominent libraries having scipy or numpy as dependency have already started the shift. 2. If we are using pytest, then we should make full usage of pytest alone. A small utility library like joblib with a few hunderds of tests cut down around 700 lines of code by adopting pytest design. 3. While testing utils can be kept independent of pytest, we should fully embrace pytest for own own unit tests. or even better, we can thinly wrap pytest and make array assertion possible by plain assert keyword statements in some way. ( I haven't thought about it yet ). 4. Making the test suites just work with pytest is a matter of one PR, or a weekend's work and I agree with developers of scikit-image. But it takes more time to complete redesign tests in flavor of pytest, after all we have to think about future contributors joining in. People experienced with pytest should fine the test suite design familiar, for contributions. I think that scikit-image has achieved the former, but still might need some PRs for the latter ( I'm glad to help in future ). 5. Here are some notable changes which are required for pytest transition: 6. Plain assert keyword statements.Pytest's own raise and warn assert helpers produce cleaner error logs on failure.Use pytest's parametrization to get rid of yield based tests and form compact tests.Fixtures like tmpdir, capsys, monkeypatch and others provided by pytest help reduce a lot of boiler plate code. 7. Analyzing the test suite of scipy, I think that it is perfectly fine to adopt a strategy I used before in Joblib. I will present my first draft soon, and it will be heavily inspired from this issue thread: https://www.github.com/joblib/joblib/issues/411 . I made around 20 PRs and after merge of every PR, the suite was in a working condition, so keeping a separate branch shall not be required. I suggest on not falling back to unittests as it will increase the boilerplate code heavily. The reason of not supporting both nosetests and pytest is because they have different flavours, and that it would be difficult to keep up with nose an pytest always comes with something interesting every two months in new releases. I will be happy to hear and work upon further suggestions. Thanks. Regards,Karan.

6 8

Re: [SciPy-Dev] SciPy-Dev Digest, Vol 161, Issue 16
by Antonio Ribeiro March 12, 2017

March 12, 2017

*And what is the "default" method for point 2 would be?* I am thinking about make it dependent on what is provided by the user: if the user provide the hessian the method would use it, otherwise the default would be a quasi-newton hessian approximation. I agree with the choice of a trust-region approach, it really seems the most sensible choice. Furthermore, thank you for the references, I will take a look. > On Mar 12, 2017, at 16:49, scipy-dev-request(a)scipy.org wrote: > > Send SciPy-Dev mailing list submissions to > scipy-dev(a)scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.scipy.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request(a)scipy.org > > You can reach the person managing the list at > scipy-dev-owner(a)scipy.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: SciPy-Dev Digest, Vol 161, Issue 12 (Nikolay Mayorov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 13 Mar 2017 00:49:19 +0500 > From: Nikolay Mayorov <nikolay.mayorov(a)zoho.com> > To: "SciPy Developers List" <scipy-dev(a)scipy.org> > Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 161, Issue 12 > Message-ID: <15ac4116913.d223fc4b16616.7056875246372910426(a)zoho.com> > Content-Type: text/plain; charset="utf-8" > > Nevertheless, the implementation > > of a solver in native Python/Cython still have it advantages and should not be discarded: > > > > > > Totally support this. Having "inhouse" implementation has the advantages listed by Antonio and additionally it adds substance to scipy project, such that it is not just a collection of wrappers. Obviously some balance between the two approaches should be maintained. I think GSoC is the most proper place to write new mathematical/algorithmic code. I would even suggest not to include any wrapper considerations in your proposal (for this particular GSoC case), but it's only my opinion here. > > > > > - About the Nikolay question about the interface to use: my plan is to try to implement the > > solver inside the ?minimize? interface in scipy. If needed I can move to a new interface > > that gives me more freedom. > > > > > > I think fitting it into "minimize" would be optimal, but if something very annoying/inconvenient/inconsistent will pop up it can be reconsidered I guess. > > > > After having a set of benchmarks my idea is to implement an interior points method. > > > > > > It sound interesting, especially because it will be completely new for scipy. > > > > > 3) After that I would like to include different possibilities of Hessian approximation to > > the method (BFGS, L-BFGS, approximated by finite-differences or provided by the user?) > > > > > And what is the "default" method for point 2 would be? > > > 4) And, if I have time, I would like to also implement a SQP solver. It would probably not be the > > > same as the one used in SLSQP. > > > > > If you develop good intuition to the problem and code base during the first 3 points it might be possible to do it rather quickly, I believe. > > > > > There are several variations of interior points methods and I am still deciding which > > one to implement among the several available options. I have seen both > > line-search and trust-region methods being used in literature and in implemented solvers > > > > > My intuition (not necessary correct) that trust-region methods are somewhat more powerful / advanced that line-search methods + you already started to study / implement trust-region methods in your PR + there is a very solid and detailed book on trust-region methods you mentioned + me too have some experience with trust-region methods + there is some code for solving trust-region subproblems (like your exact method or I wrote a 2-by-2 method for subspace approach). I would maybe suggest to look into trust-region approach more closely based on all that. > > > > As for the references I suggest to scan MATLAB manual https://www.mathworks.com/help/optim/ug/constrained-nonlinear-optimization-… it contains good references to papers (but you probably found them already). > > > > > > ---- On Sun, 12 Mar 2017 00:41:39 +0500 Antonio Ribeiro <antonior92(a)gmail.com> wrote ---- > > > > > I would like to start by thanking both Matt Haberland and Nikolay Mayorov for making > > themselves avaliable for mentoring me. I would like very much to have the opportunity > > to be mentored by one or even both of you. > > > > About the questions raised about the project: > > > > - To have a wrapper for ?ipopt? in scipy would be nice and, if the owners give permission, > > it could be one of the items of the proposal. Nevertheless, the implementation > > of a solver in native Python/Cython still have it advantages and should not be discarded: > > i) the code in python is much more readable, furthermore native code make it easier for scipy collaborators > > to add new features and maintain it; ii) Using the proper Numpy and LAPACK functions > > for expensive operations and using Cython when needed, our implementation can be as > > fast as C or FORTRAN implementations; iii) It is easier to maintain coherence of interface > > with other scipy methods using a native implementation. > > - About the Nikolay question about the interface to use: my plan is to try to implement the > > solver inside the ?minimize? interface in scipy. If needed I can move to a new interface > > that gives me more freedom. > > > > About what to implement and in what order of priority: > > > > 1) Nikolay idea implement a set of benchmarks from the beginning is very good, > > it would allow to compare my method with other already implemented solvers > > and to assess the quality of my solver during its development. > > 2) After having a set of benchmarks my idea is to implement an interior points method. > > In my opinion interior points methods should be the priority because they are able to > > handle a large range of problems reasonably well. They are very powerful algorithms > > for large-scale problems and usually are able to deal with medium/small > > problems reasonably well too. > > 3) After that I would like to include different possibilities of Hessian approximation to > > the method (BFGS, L-BFGS, approximated by finite-differences or provided by the user?) > > 4) And, if I have time, I would like to also implement a SQP solver. It would probably not be the > > same as the one used in SLSQP. > > > > There are several variations of interior points methods and I am still deciding which > > one to implement among the several available options. I have seen both > > line-search and trust-region methods being used in literature and in implemented solvers > > (for instance "ipopt? uses a line-search approach while ?KNITRO? uses a trust-region approach). > > I have found a good reference about trust-region interior point methods in the > > Conn, Gould and Toint ?Trust-Region methods? book; Nocedal and Wright book also have > > a small chapter about nonlinear interior point methods that can be useful. Furthermore, > > I am looking into papers and surveys about the subject. I would much appreciate > > any recommendation or reference about the subject. Same thing with SQP methods. > > > > Best regards, > > Ant?nio > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mar 11, 2017, at 14:01, scipy-dev-request(a)scipy.org wrote: > > > > > > Send SciPy-Dev mailing list submissions to > > > scipy-dev(a)scipy.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://mail.scipy.org/mailman/listinfo/scipy-dev > > > or, via email, send a message with subject or body 'help' to > > > scipy-dev-request(a)scipy.org > > > > > > You can reach the person managing the list at > > > scipy-dev-owner(a)scipy.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: SciPy-Dev Digest, Vol 161, Issue 11 (Denis Akhiyarov) > > > 2. Re: SciPy-Dev Digest, Vol 161, Issue 11 (Matt Haberland) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Sat, 11 Mar 2017 09:08:17 -0600 > > > From: Denis Akhiyarov <denis.akhiyarov(a)gmail.com> > > > To: scipy-dev(a)scipy.org > > > Subject: Re: [SciPy-Dev] SciPy-Dev Digest, Vol 161, Issue 11 > > > Message-ID: > > > <CALxxJLQhh-e-tM5u0EijBbWaC0etaChxkLt61LEy=EPg0A-J-A(a)mail.gmail.com> > > > Content-Type: text/plain; charset="utf-8" > > > > > > I used ipopt for interior-point method from python, are you trying to add > > > something similar to scipy? if yes, why not just add a wrapper for ipopt, > > > since the license looks not restrictive? > > > > > > On Fri, Mar 10, 2017 at 1:40 PM, <scipy-dev-request(a)scipy.org> wrote: > > > > > >> Send SciPy-Dev mailing list submissions to > > >> scipy-dev(a)scipy.org > > >> > > >> To subscribe or unsubscribe via the World Wide Web, visit > > >> https://mail.scipy.org/mailman/listinfo/scipy-dev > > >> or, via email, send a message with subject or body 'help' to > > >> scipy-dev-request(a)scipy.org > > >> > > >> You can reach the person managing the list at > > >> scipy-dev-owner(a)scipy.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: GSoC2017: Constrained Optimisation in Scipy (Matt Haberland) > > >> 2. Re: GSoC2017: Constrained Optimisation in Scipy (Nikolay Mayorov) > > >> > > >> > > >> ---------------------------------------------------------------------- > > >> > > >> Message: 1 > > >> Date: Fri, 10 Mar 2017 10:01:32 -0800 > > >> From: Matt Haberland <haberland(a)ucla.edu> > > >> To: SciPy Developers List <scipy-dev(a)scipy.org> > > >> Subject: Re: [SciPy-Dev] GSoC2017: Constrained Optimisation in Scipy > > >> Message-ID: > > >> <CADuxUiyK_d3BvjinikmG_k8LTh8JczMFPwboNaSerdnsWFp=yQ@ > > >> mail.gmail.com> > > >> Content-Type: text/plain; charset="utf-8" > > >> > > >> The choice of nonlinear optimization algorithm can have a dramatic impact > > >> on the speed and quality of the solution, and the best choice for a > > >> particular problem can be difficult to determine a priori, so it is > > >> important to have multiple options available. > > >> > > >> My work in optimal control leads to problems with (almost entirely) > > >> nonlinear constraints, and the use of derivative information is essential > > >> for reasonable performance, leaving SLSQP as the only option in SciPy right > > >> now. However, the problems are also huge and very sparse with a specific > > >> structure, so SLSQP is not very effective, and not nearly as effective as a > > >> nonlinear optimization routine could be. So despite SciPy boasting 14 > > >> options for minimization of a nonlinear objective, it wasn't suitable for > > >> this work (without the use of an external solver). > > >> > > >> I think SciPy is in need of at least one solver designed to handle large, > > >> fully nonlinear problems, and having two would be much better. Interior > > >> point and SQP are good, complementary options. > > >> > > >> On Thu, Mar 9, 2017 at 2:38 PM, Antonio Ribeiro <antonior92(a)gmail.com> > > >> wrote: > > >> > > >>> Hello, my name is Antonio and I am a Brazilian electrical engineer > > >>> currently pursuing my master degree. I have contributed to scipy.optimize > > >>> and scipy.signal implementing functions "iirnotch", "irrpeak" > > >>> <https://github.com/scipy/scipy/pull/6404>and the method > > >>> "trust-region-exact" <https://github.com/scipy/scipy/pull/6919> (under > > >>> revision). I am interested in applying for the Google Summer of Code 2017 > > >>> to work with the Scipy optimisation package. > > >>> > > >>> My proposal is to improve scipy.optimize adding optimisation methods that > > >>> are able to deal with non-linear constraints. Currently the only > > >>> implemented methods able to deal with non-linear constraints are the > > >>> FORTRAN wrappers SLSQP and COBYLA. > > >>> > > >>> SLSQP is a sequential quadratic programming method and COBYLA is a > > >>> derivative-free optimisation method, they both have its limitations: > > >>> SLSQP is not able to deal with sparse > > >>> hessians and jacobians and is unfit for large-scale problems and COBYLA, > > >>> as other derivative-free methods, is a good choice for optimise noisy > > >>> objective functions, however usually presents a poorer performance then > > >>> derivative-based methods when the derivatives are available (or even when > > >>> they are computed by automatic differentiation or finite differences). > > >>> > > >>> My proposal is to implement in Scipy one or more state-of-the-art solvers > > >>> (interior point and SQP methods) for constrained optimisation problems. I > > >>> would like to get some feedback about this, discuss the relevance of it > > >> for > > >>> Scipy and get some suggestions of possible mentors. > > >>> > > >>> _______________________________________________ > > >>> SciPy-Dev mailing list > > >>> SciPy-Dev(a)scipy.org > > >>> https://mail.scipy.org/mailman/listinfo/scipy-dev > > >>> > > >>> > > >> > > >> > > >> -- > > >> Matt Haberland > > >> Assistant Adjunct Professor in the Program in Computing > > >> Department of Mathematics > > >> 7620E Math Sciences Building, UCLA > > >>

1 0