Mailman 3 September 2021 - SciPy-Dev

Re: [SciPy-Dev] Sensitivity analysis module proposal (Robert Kern)
by William Usher Sept. 3, 2021

Sept. 3, 2021

Hi Robert, Thanks for the response. You raise good points. Obviously, that you are interested in the proposal assuages some of that, but I'm still unclear on why you are interested in this. What is the benefit that you think everyone will get by absorbing SALib into scipy? It still looks to me like a mostly-lateral move that will merely be disruptive to your dependent projects more than anything else. The real value of SALib is in providing a consistent interface to a (large) suite of sensitivity analysis methods which allows users to easily switch between those methods. We (as maintainers) could benefit from reducing duplication of code and implementations, such has Sobol’ sequence generation, LHS, and could contribute some of the more general sample generation implementations where appropriate (many are linked directly to the SA implementations and not useful outside of that). We think the scientific community as a whole would benefit from the greater exposure a SciPy implementation of SA would bring - as a large community-led effort - it could provide a neutral forum for further development of these methods. This would likely come at some “cost” to the successful “cottage industry” we’ve established and grown (SALib is getting lots of citations and use). I think a key argument against integration is that it may reduce the agility with which we can add new methods to our SA suite (although this could be mitigated with careful design). I think you raise an important point about our dependent projects, and particularly how we would continue to support legacy releases if developer resources were focussed on a SciPy integration? An attraction is the possibility of funding to support the development of SA within SciPy. Like all open-source projects, we suffer from resourcing issues, and are predominantly volunteer-driven from the academic community. And while we are technically a “multi-developer” community, we’re only a few bus accidents (or career changes) away from being a lone-maintainer. Will From: Robert Kern <robert.kern(a)gmail.com<mailto:robert.kern@gmail.com>> Subject: Re: [SciPy-Dev] Sensitivity analysis module proposal Date: 2 September 2021 at 16:14:13 CEST To: SciPy Developers List <scipy-dev(a)python.org<mailto:scipy-dev@python.org>> Cc: Jon Herman <jdherman(a)ucdavis.edu<mailto:jdherman@ucdavis.edu>>, Takuya Iwanaga <iwanaga.takuya(a)anu.edu.au<mailto:iwanaga.takuya@anu.edu.au>> On Thu, Sep 2, 2021 at 9:12 AM William Usher <wusher(a)kth.se<mailto:wusher@kth.se>> wrote: Hi; I’m one of the maintainers of SALib<https://pypi.org/project/SALib/>, a Python library which offers implementations of popular global sensitivity analysis approaches including Sobol’, Morris, DMIM, DGSM, FAST and others. We’ve been approached<https://github.com/SALib/SALib/issues/463> by roy.pamphile(a)gmail.com<mailto:roy.pamphile@gmail.com> regarding the possibility of either - contributing the entire SALib library to SciPy, or - contributing key functions from SALib to SciPy, keeping SALib as a user-friendly wrapper around the SciPy implementations + extensions that don’t fit within SciPy’s remit. We believe that this move could overall benefit the scientific and sensitivity analysis communities. I laid out my general rubric for considering absorbing functionality into scipy the last time this was brought up: https://mail.python.org/pipermail/scipy-dev/2021-April/024715.html Obviously, that you are interested in the proposal assuages some of that, but I'm still unclear on why you are interested in this. What is the benefit that you think everyone will get by absorbing SALib into scipy? It still looks to me like a mostly-lateral move that will merely be disruptive to your dependent projects more than anything else. -- Robert Kern _______________________________________________ SciPy-Dev mailing list SciPy-Dev(a)python.org<mailto:SciPy-Dev@python.org> https://mail.python.org/mailman/listinfo/scipy-dev

3 2

Sensitivity analysis module proposal
by William Usher Sept. 2, 2021

Sept. 2, 2021

Hi; I’m one of the maintainers of SALib<https://pypi.org/project/SALib/>, a Python library which offers implementations of popular global sensitivity analysis approaches including Sobol’, Morris, DMIM, DGSM, FAST and others. We’ve been approached<https://github.com/SALib/SALib/issues/463> by roy.pamphile(a)gmail.com<mailto:roy.pamphile@gmail.com> regarding the possibility of either - contributing the entire SALib library to SciPy, or - contributing key functions from SALib to SciPy, keeping SALib as a user-friendly wrapper around the SciPy implementations + extensions that don’t fit within SciPy’s remit. We believe that this move could overall benefit the scientific and sensitivity analysis communities. We’ve discussed this internally, and would be open to either of the above options. What are the next steps? Kind regards, Will Usher [cid:image001.jpg@01D51FA4.648A23D0] Dr. Will Usher Assistant Professor in Integrated Assessment for Sustainable Development, KTH Royal Institute of Technology Division of Energy Systems School of Industrial Engineering and Management KTH Royal Institute of Technology Brinellvägen 68 SE-100 44 Stockholm, Sweden wusher(a)kth.se<mailto:wusher@kth.se> +46 (0)8 790 74 61 https://www.energy.kth.se/research/energy-systems https://www.github.com/kth-desa https://www.github.com/osemosys https://www.github.com/salib

3 2

ENH: Add Conjugate Residual (CR) method
by 赵刚 Sept. 2, 2021

Sept. 2, 2021

Dear all, I submitted a PR to support Conjugate Residual (CR) method: https://github.com/scipy/scipy/pull/14675 which can be used in symmetric indefinite or Hermitian systems.The algorithm is formally similar to Conjugate Gradient (CG) but mathematically equivalent to Minimal Residual (MINRES). For symmetric positive-definite problems, CR has the same convergence as CG. But for symmetric indefinite problems, CR has almost the same iterative steps and less computation in each iteration than MINRES, which means higher computational efficiency. The arrival of CR algorithm will further enrich the Krylov subspace methods implemented in SciPy and give users more/better choices. The PR is only a part of CR type methods which include CR, Bi-CR, Generalized CR, GCRO and GCRO-DR etc. This large class of algorithms are widely used in some specific problems and play an important role. So we intend to implement CR first, and then implement Bi-CR and GCR methods respectively. The PR used the functional features of NumPy and SciPy to implement the CR method. Hope you like it. Thanks. Best Regards, Gang

1 0