Mailman 3 February 2021 - SciPy-Dev

Global Optimization Benchmarks
by Andrea Gavana July 11, 2021

July 11, 2021

Dear SciPy Developers & Users, long time no see :-) . I thought to start 2021 with a bit of a bang, to try and forget how bad 2020 has been... So I am happy to present you with a revamped version of the Global Optimization Benchmarks from my previous exercise in 2013. This new set of benchmarks pretty much superseeds - and greatly expands - the previous analysis that you can find at this location: http://infinity77.net/global_optimization/ . The approach I have taken this time is to select as many benchmark test suites as possible: most of them are characterized by test function *generators*, from which we can actually create almost an unlimited number of unique test problems. Biggest news are: 1. This whole exercise is made up of *6,825* test problems divided across *16* different test suites: most of these problems are of low dimensionality (2 to 6 variables) with a few benchmarks extending to 9+ variables. With all the sensitivities performed during this exercise on those benchmarks, the overall grand total number of functions evaluations stands at *3,859,786,025* - close to *4 billion*. Not bad. 2. A couple of "new" optimization algorithms I have ported to Python: - MCS: Multilevel Coordinate Search <https://www.mat.univie.ac.at/~neum/software/mcs/>, it’s my translation to Python of the original Matlab code from A. Neumaier and W. Huyer (giving then for free also GLS and MINQ) I have added a few, minor improvements compared to the original implementation. - BiteOpt: BITmask Evolution OPTimization <https://github.com/avaneev/biteopt> , I have converted the C++ code into Python and added a few, minor modifications. Enough chatting for now. The 13 tested algorithms are described here: http://infinity77.net/go_2021/ High level description & results of the 16 benchmarks: http://infinity77.net/go_2021/thebenchmarks.html Each benchmark test suite has its own dedicated page, with more detailed results and sensitivities. List of tested algorithms: 1. *AMPGO*: Adaptive Memory Programming for Global Optimization: this is my Python implementation of the algorithm described here: http://leeds-faculty.colorado.edu/glover/fred%20pubs/416%20-%20AMP%20(TS)%2… I have added a few improvements here and there based on my Master Thesis work on the standard Tunnelling Algorithm of Levy, Montalvo and Gomez. After AMPGO was integrated in lmfit <https://github.com/lmfit/lmfit-py>, I have improved it even more - in my opinion. 2. *BasinHopping*: Basin hopping is a random algorithm which attempts to find the global minimum of a smooth scalar function of one or more variables. The algorithm was originally described by David Wales: http://www-wales.ch.cam.ac.uk/ BasinHopping is now part of the standard SciPy distribution. 3. *BiteOpt*: BITmask Evolution OPTimization, based on the algorithm presented in this GitHub link: https://github.com/avaneev/biteopt I have converted the C++ code into Python and added a few, minor modifications. 4. *CMA-ES*: Covariance Matrix Adaptation Evolution Strategy, based on the following algorithm: http://www.lri.fr/~hansen/cmaesintro.html http://www.lri.fr/~hansen/cmaes_inmatlab.html#python (Python code for the algorithm) 5. *CRS2*: Controlled Random Search with Local Mutation, as implemented in the NLOpt <http://ab-initio.mit.edu/wiki/index.php/NLopt> package: http://ab-initio.mit.edu/wiki/index.php/NLopt_Algorithms#Controlled_Random_… 6. *DE*: Differential Evolution, described in the following page: http://www1.icsi.berkeley.edu/~storn/code.html DE is now part of the standard SciPy distribution, and I have taken the implementation as it stands in SciPy: https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.differe… 7. *DIRECT*: the DIviding RECTangles procedure, described in: https://www.tol-project.org/export/2776/tolp/OfficialTolArchiveNetwork/NonL… http://ab-initio.mit.edu/wiki/index.php/NLopt_Algorithms#DIRECT_and_DIRECT-L (Python code for the algorithm) 8. *DualAnnealing*: the Dual Annealing algorithm, taken directly from the SciPy implementation: https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.dual_an… 9. *LeapFrog*: the Leap Frog procedure, which I have been recommended for use, taken from: https://github.com/flythereddflagg/lpfgopt 10. *MCS*: Multilevel Coordinate Search, it’s my translation to Python of the original Matlab code from A. Neumaier and W. Huyer (giving then for free also GLS <https://www.mat.univie.ac.at/~neum/software/ls/> and MINQ <https://www.mat.univie.ac.at/~neum/software/minq/>): https://www.mat.univie.ac.at/~neum/software/mcs/ I have added a few, minor improvements compared to the original implementation. See the MCS <http://infinity77.net/go_2021/mcs.html#mcs> section for a quick and dirty comparison between the Matlab code and my Python conversion. 11. *PSWARM*: Particle Swarm optimization algorithm, it has been described in many online papers. I have used a compiled version of the C source code from: http://www.norg.uminho.pt/aivaz/pswarm/ 12. *SCE*: Shuffled Complex Evolution, described in: Duan, Q., S. Sorooshian, and V. Gupta, Effective and efficient global optimization for conceptual rainfall-runoff models, Water Resour. Res., 28, 1015-1031, 1992. The version I used was graciously made available by Matthias Cuntz via a personal e-mail. 13. *SHGO*: Simplicial Homology Global Optimization, taken directly from the SciPy implementation: https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.shgo.ht… List of benchmark test suites: 1. SciPy Extended <http://infinity77.net/go_2021/scipy_extended.html#scipy-extended>: 235 multivariate problems (where the number of independent variables ranges from 2 to 17), again with multiple local/global minima. I have added about 40 new functions to the standard SciPy benchmarks <https://github.com/scipy/scipy/tree/master/benchmarks/benchmarks/go_benchma…> and fixed a few bugs in the existing benchmark models in the SciPy repository. 2. GKLS <http://infinity77.net/go_2021/gkls.html#gkls>: 1,500 test functions, with dimensionality varying from 2 to 6, generated with the super famous GKLS Test Functions Generator <https://arxiv.org/abs/1103.2695>. I have taken the original C code (available at http://netlib.org/toms/) and converted it to Python. 3. GlobOpt <http://infinity77.net/go_2021/globopt.html#globopt>: 288 tough problems, with dimensionality varying from 2 to 5, created with another test function generator which I arbitrarily named “GlobOpt”: https://www.researchgate.net/publication/225566516_A_new_class_of_test_func… . The original code is in C++ and I have bridged it to Python using Cython. *Many thanks* go to Professor Marco Locatelli for providing an updated copy of the C++ source code. 4. MMTFG <http://infinity77.net/go_2021/mmtfg.html#mmtfg>: sort-of an acronym for “Multi-Modal Test Function with multiple Global minima”, this test suite implements the work of Jani Ronkkonen: https://www.researchgate.net/publication/220265526_A_Generator_for_Multimod… . It contains 981 test problems with dimensionality varying from 2 to 4. The original code is in C and I have bridge it to Python using Cython. 5. GOTPY <http://infinity77.net/go_2021/gotpy.html#gotpy>: a generator of benchmark functions using the Bocharov-Feldbaum “Method-Min”, containing 400 test problems with dimensionality varying from 2 to 5. I have taken the Python implementation from https://github.com/redb0/gotpy and improved it in terms of runtime. Original paper from http://www.mathnet.ru/php/archive.phtml?wshow=paper&jrnid=at&paperid=11985&… . 6. Huygens <http://infinity77.net/go_2021/huygens.html#huygens>: this benchmark suite is very different from the rest, as it uses a “fractal” approach to generate test functions. It is based on the work of Cara MacNish on Fractal Functions <https://www.cs.bham.ac.uk/research/projects/ecb/displayDataset.php?id=150>. The original code is in Java, and at the beginning I just converted it to Python: given it was slow as a turtle, I have re-implemented it in Fortran and wrapped it using f2py <http://www.scipy.org/F2py>, then generating 600 2-dimensional test problems out of it. 7. LGMVG <http://infinity77.net/go_2021/lgmvg.html#lgmvg>: not sure about the meaning of the acronym, but the implementation follows the “Max-Set of Gaussians Landscape Generator” described in http://boyuan.global-optimization.com/LGMVG/index.htm . Source code is given in Matlab, but it’s fairly easy to convert it to Python. This test suite contains 304 problems with dimensionality varying from 2 to 5. 8. NgLi <http://infinity77.net/go_2021/ngli.html#ngli>: Stemming from the work of Chi-Kong Ng and Duan Li, this is a test problem generator for unconstrained optimization, but it’s fairly easy to assign bound constraints to it. The methodology is described in https://www.sciencedirect.com/science/article/pii/S0305054814001774 , while the Matlab source code can be found in http://www1.se.cuhk.edu.hk/~ckng/generator/ . I have used the Matlab script to generate 240 problems with dimensionality varying from 2 to 5 by outputting the generator parameters in text files, then used Python to create the objective functions based on those parameters and the benchmark methodology. 9. MPM2 <http://infinity77.net/go_2021/mpm2.html#mpm2>: Implementing the “Multiple Peaks Model 2”, there is a Python implementation at https://github.com/jakobbossek/smoof/blob/master/inst/mpm2.py . This is a test problem generator also used in the smoof <https://github.com/jakobbossek/smoof> library, I have taken the code almost as is and generated 480 benchmark functions with dimensionality varying from 2 to 5. 10. RandomFields <http://infinity77.net/go_2021/randomfields.html#randomfields>: as described in https://www.researchgate.net/publication/301940420_Global_optimization_test… , it generates benchmark functions by “smoothing” one or more multidimensional discrete random fields and composing them. No source code is given, but the implementation is fairly straightforward from the article itself. 11. NIST <http://infinity77.net/go_2021/nist.html#nist>: not exactly the realm of Global Optimization solvers, but the NIST StRD <https://www.itl.nist.gov/div898/strd/nls/nls_main.shtml> dataset can be used to generate a single objective function as “sum of squares”. I have used the NIST dataset as implemented in lmfit <https://github.com/lmfit/lmfit-py/tree/master/NIST_STRD>, thus creating 27 test problems with dimensionality ranging from 2 to 9. 12. GlobalLib <http://infinity77.net/go_2021/globallib.html#globallib>: Arnold Neumaier maintains <https://www.mat.univie.ac.at/~neum/glopt/coconut/Benchmark/Benchmark.html> a suite of test problems termed “COCONUT Benchmark” and Sahinidis has converted the GlobalLib and PricentonLib AMPL/GAMS dataset into C/Fortran code (http://archimedes.cheme.cmu.edu/?q=dfocomp ). I have used a simple C parser to convert the benchmarks from C to Python. The global minima are taken from Sahinidis <http://thales.cheme.cmu.edu/dfo/comparison/comp.html> or from Neumaier or refined using the NEOS server <https://neos-server.org/neos/> when the accuracy of the reported minima is too low. The suite contains 181 test functions with dimensionality varying between 2 and 9. 13. CVMG <http://infinity77.net/go_2021/cvmg.html#cvmg>: another “landscape generator”, I had to dig it out using the Wayback Machine at http://web.archive.org/web/20100612044104/https://www.cs.uwyo.edu/~wspears/… , the acronym stands for “Continuous Valued Multimodality Generator”. Source code is in C++ but it’s fairly easy to port it to Python. In addition to the original implementation (that uses the Sigmoid <https://en.wikipedia.org/wiki/Sigmoid_function> as a softmax/transformation function) I have added a few others to create varied landscapes. 360 test problems have been generated, with dimensionality ranging from 2 to 5. 14. NLSE <http://infinity77.net/go_2021/nlse.html#nlse>: again, not really the realm of Global optimization solvers, but Nonlinear Systems of Equations can be transformed to single objective functions to optimize. I have drawn from many different sources (Publications <https://www.sciencedirect.com/science/article/pii/S0898122111004299>, ALIAS/COPRIN <http://www-sop.inria.fr/coprin/logiciels/ALIAS/Benches/node1.html#SECTION00…> and many others) to create 44 systems of nonlinear equations with dimensionality ranging from 2 to 8. 15. Schoen <http://infinity77.net/go_2021/schoen.html#schoen>: based on the early work of Fabio Schoen and his short note <https://link.springer.com/article/10.1007%2FBF01096734> on a simple but interesting idea on a test function generator, I have taken the C code in the note and converted it into Python, thus creating 285 benchmark functions with dimensionality ranging from 2 to 6. *Many thanks* go to Professor Fabio Schoen for providing an updated copy of the source code and for the email communications. 16. Robust <http://infinity77.net/go_2021/robust.html#robust>: the last benchmark test suite for this exercise, it is actually composed of 5 different kind-of analytical test function generators, containing deceptive, multimodal, flat functions depending on the settings. Matlab source code is available at http://www.alimirjalili.com/RO.html , I simply converted it to Python and created 420 benchmark functions with dimensionality ranging from 2 to 6. Enjoy, and Happy 2021 :-) . Andrea.

6 21

Using more functionalities from GitHub?
by Pamphile Roy April 5, 2021

April 5, 2021

Hi everyone, I would like to propose to use more functionalities of GitHub. I could not find any reference showing this was discussed before, so I apologize if the following would not be relevant. Teams Currently there is just the triage team, but we could create other teams like one per submodule or for given skill sets. This could allow easier pinging of people on PR. Project We have the roadmap and some issues are acting as meta-issues. But we could use, instead/on top, the integrated project management dashboard. It would be more convenient to keep track of what can be done, who is working on what area, etc. Also, this would clearly be in favor of openness and transparency with the management of the library. Cheers, Pamphile

3 4

Re: [SciPy-Dev] GSoC'21 participation SciPy
by Pamphile Roy March 24, 2021

March 24, 2021

Hi, Thank you for putting this together! I would have some ideas for the ideal pool :) scipy.optimize: Would it be wanted to have a possibility to have workers to evaluate the function during an optimization? In most industrial context, the function is not trivial and might require minutes if not hours or even days to compute. Having a simple way to first parallelise the runs would help. We have machines with easily ten cores now and it would be great to leverage this here. Going that direction, having a more general infrastructure to handle external workers would be great. Sure there are external packages to do this, but then it’s not so trivial if you want to use SciPy’s optimizers. scipy.optimize: What about another optimization method such as EGO? This would require to have a Gaussian Process regressor. scipy.stats: there is an ANOVA section in the roadmap. But is sensitivity analysis in general something which would be of interest. I am thinking about Sobol’ indices (not related to Sobol’ sequence but from the same author), moment based indices, Shapley values, cusunoro, etc. scipy.metamodel: last but not least, a metamodel/response surface module. This is linked to the optimization or sensitivity analysis of expensive functions. Would be sufficient to have Gaussian Process and polynomial chaos expansion. Could also include more general things like linear regression or others things in scipy.interpolate. Cheers, Pamphile @tupui

5 8

Faster maximum flow algorithm for scipy.sparse.csgraph
by Touqir Sajed March 1, 2021

March 1, 2021

Dear Scipy developers, This is a continuation of https://github.com/scipy/scipy/issues/13402 . The current implementation of scipy.sparse.csgraph uses Edmond's Karp algorithm which is not quite good in terms of theoretical time complexity but despite of this, the implementation is optimized enough to outperform several other superior (theoretical complexity) algorithms as shown here : https://github.com/scipy/scipy/pull/10566#issuecomment-552615594 . Later I carried out benchmarks ( https://github.com/scipy/scipy/issues/13402#issuecomment-767909167 ) showing that indeed scipy's Edmond-Karp implementation can be significantly beaten with optimized implementations. My original concern was Edmond-Karp's theoretical complexity which limits its performance in some cases (highly dense graphs). So, having another algorithm in scipy with a better theoretical complexity along with proven superior empirical performance makes sense. Only the algorithms here : https://github.com/touqir14/MaxFlow have been shown to significantly outperform scipy's Edmond-Karp. I think it would be good to port one or several of these implementations into scipy. Having solely cython ports will probably be easier to maintain. One thing to ponder here is how much of a complex implementation should we allow if we decide to add new max flow algorithms to scipy. Let me know your thoughts. Cheers, Touqir

2 1

ENH: improve RBF interpolation
by Trever Hines Feb. 28, 2021

Feb. 28, 2021

Hello scipy developers, I would like to contribute code to scipy to address some issues regarding RBF interpolation. The code can be found on my branch here <https://github.com/treverhines/scipy/blob/improve-rbf-interpolation/scipy/i…>. My contribution consists of two new classes for scattered N-D interpolation: 1. `RBFInterpolator`: This is intended to be a replacement for `Rbf` that addresses issues mentioned in 9904 <https://github.com/scipy/scipy/issues/9904> and 4790 <https://github.com/scipy/scipy/issues/4790>. Namely, the major differences with `Rbf` are 1) the usage is similar to `NearestNDInterpolator` and `LinearNDInterpolator` making it easier to swap out different interpolation methods, 2) the sign of the smoothing parameter is correct (see page 10 of these lecture notes <http://pages.stat.wisc.edu/~wahba/stat860public/lect/lect8/lect8.pdf>), and 3) the interpolant includes polynomial terms. For some RBF choices (values of “linear”, “thin_plate”, “cubic”, “quintic”, or “multiquadratic” for `function` in `Rbf`), the additional polynomial terms are needed to ensure that the interpolation problem is well-posed (see theorem 3.2.7 in this document <http://amadeus.math.iit.edu/~fass/603_ch3.pdf>). Without the additional polynomial terms for these RBFs, I have noticed that some values for the smoothing parameter (with the corrected sign) result in an obviously erroneous interpolant. Even when the chosen RBF does not require additional polynomial terms, they still can improve the quality of the interpolant. In particular, the polynomial terms are able to accommodate shifts or linear trends in data, which the RBFs tend to struggle with by themselves. 2. `KNearestRBFInterpolator`: This class performs RBF interpolation using only the k nearest data points to each interpolation point (which was suggested in 5180 <https://github.com/scipy/scipy/issues/5180>). This class is useful when there are too many observations for `RBFInterpolator` (on the order of tens of thousands) and you want an interpolant that *looks* smoother than what you get with `NearestNDInterpolator` or `LinearNDInterpolator`. My concern with interpolation using the k nearest neighbors is that it is a bit of an ad hoc strategy to work around computational limitations. That being said, I have seen a similar strategy used in the Kriging <https://pro.arcgis.com/en/pro-app/latest/help/analysis/geostatistical-analy…> world (Kriging is a form of RBF interpolation). I would appreciate your feedback on whether you think these would be valuable contributions to scipy. If so, I will make the pull request after adding benchmarks, unit tests, and more docs. Thanks, Trever

3 3

(no subject)
by Christoph Baumgarten Feb. 28, 2021

Feb. 28, 2021

Hi, I implemented the Cramer-von-Mises test for two samples in PR 13263 <https://github.com/scipy/scipy/pull/13263>, The proposed name is cramervonmises_2samp. The one-sample version (cramervonmises) was already released in version 1.6.0. Since a few names of tests in scipy.stats were recently discussed on the mailing list (though cramervonmises was not), I just wanted to mention the PR here in case there are concerns about the name. One additional remark: for the KS test, there are three functions: kstest, ks_1samp, ks_2samp and kstest can be used both for the one- and two-sample tests. In my view, this makes the definition of kstest quite complicated since the meaning of the parameters depends on the version of the test and one needs a helper function _parse_kstest_args(data1, data2, args, N) in stats/stats.py So maybe cramervonmises_1samp and cramervonmises_2samp would have been a good choice, though I hope the names cramervonmises and cramervonmises_2samp also guide the user when to use which function. (While writing this message, I noted that the documentation of cramervonmises should state more clearly that it is about the one-sample test, e.g. "Perform the Cramér-von Mises test for goodness of fit.' --> 'Perfrom the one-sample ...') Any views? Thanks for your feedback Christoph

2 1

mypy 0.770 is broken on Python 3.9.0a5
by Tirth Patel Feb. 26, 2021

Feb. 26, 2021

I recently proposed gh-13613 (https://github.com/scipy/scipy/pull/13613) which adds CI for type checking and noticed this failure: ``` scipy/_lib/_uarray/_backend.py:96: error: syntax error in type comment [syntax] Found 1 error in 1 file (checked 662 source files) ``` I don't see any errors with Python 3.8.0 and mypy 0.770, mypy 0.780, and mypy 0.812 (latest release). So, this probably has something to do with Python 3.9.0a5 (which is currently being installed on ubuntu-latest). I checked with mypy 0.780, mypy 0.800, and mypy 0.812 on Python 3.9.0a5. This error disappears in all those versions but dozens of others arise. I think this error is related to python/mypy#8614 (https://github.com/python/mypy/issues/8614) which got fixed in mypy>=0.780. So, if I am not wrong, we have two options here: - Stick with Python 3.8 and mypy 0.770. - Use mypy latest (0.812 currently) which works for both Python 3.8 and Python 3.9. I think the latter would be a better choice as NumPy does it and mypy is changing fast so it will help keep up with new changes. I have a fix for all the errors occurring with mypy latest (mypy 0.812) and would add the changes to the PR if there is a consensus to go that way! -- Kind Regards, Tirth Patel

2 1

Re: [SciPy-Dev] merged scipy.stats.qmc with quasi-Monte Carlo functionality
by Pamphile Roy Feb. 23, 2021

Feb. 23, 2021

Hi everyone, First of all, thank you for everyone who helped with adding QMC (scipy.stats.qmc) :). I wanted to give an overview of the current work in progress and some perspectives. Waiting for reviews: * Using QMC in scipy.optimize: https://github.com/scipy/scipy/pull/13469 <https://github.com/scipy/scipy/pull/13469> (had a few reviews, could be shipped fast and blocking Stefan Endres to work on improvements of shgo). * New QMC method (LHS optimized): https://github.com/scipy/scipy/pull/13471 <https://github.com/scipy/scipy/pull/13471> (code was originally in the QMC PR and received initial reviews thanks to Matt Haberland, but since then nothing more). * General tutorial: https://github.com/scipy/scipy/pull/13487 <https://github.com/scipy/scipy/pull/13487> (finished but Art Owen might drop in and add things, this could also wait for another PR). * Small Cython refactoring of an internal function of Sobol’: https://github.com/scipy/scipy/pull/13514 <https://github.com/scipy/scipy/pull/13514> (waiting for a maintainer to be merged). Work in progress: * Port to Cython (Pythran is being looked at too) of discrepancy functions (thanks Arthur Volant): https://github.com/scipy/scipy/pull/13576 <https://github.com/scipy/scipy/pull/13576> . Other Cythonization which have not been looked at yet, see this issue https://github.com/scipy/scipy/issues/13474 <https://github.com/scipy/scipy/issues/13474> . Perspectives: * Other scrambling methods (for Halton and Sobol’, but could also have more generic things like randomization of any QMC). * Use QMC with any distribution from scipy.stats. There is an issue with some initial discussions, would need more opinion for me to continue and propose a PR: https://github.com/scipy/scipy/issues/13368 <https://github.com/scipy/scipy/issues/13368>. * Add other QMC methods: lattice rules, other low discrepancy sequences, adaptive LHS, etc. * Add other uniformity criteria: L-inf, minimum spanning tree, discrepancy over sub-spaces, etc. * General method to construct an optimal design based on a metric. (Similar to what I propose with LHS optimized). * Your ideas. Thanks in advance for your help. Cheers, Pamphile

1 0

Re: [SciPy-Dev] Boost for stats
by Sam Wallan Feb. 22, 2021

Feb. 22, 2021

Hello, I’ve been working on a spreadsheet that compares Boost and SciPy. I looked at statistical distributions, special functions, and ODE solvers. Here’s the google sheets link: https://docs.google.com/spreadsheets/d/1zVaau6k1_0yQNW107D81RVCirWEN8sXwcYa… I’ve left it on suggestion mode with that sharing link, so if anyone has any thoughts please feel free to leave a comment. It looks like Boost may have a lot to add! Regards, Sam > On Feb 15, 2021, at 4:48 AM, scipy-dev-request(a)python.org wrote: > > Send SciPy-Dev mailing list submissions to > scipy-dev(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request(a)python.org > > You can reach the person managing the list at > scipy-dev-owner(a)python.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: Boost for stats (Neal Becker) > 2. Re: Boost for stats (Hans Dembinski) > 3. Re: Boost for stats (Ralf Gommers) > 4. Re: Boost for stats (Neal Becker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 15 Feb 2021 07:23:38 -0500 > From: Neal Becker <ndbecker2(a)gmail.com> > To: SciPy Developers List <scipy-dev(a)python.org> > Subject: Re: [SciPy-Dev] Boost for stats > Message-ID: > <CAG3t+pHTnLa+EHL5G=_Esvi1unvYO0+DNnv8RxGKryuTS+jBUg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I have been using (and it's predecessor before it, > boost::python) to package c++ code for python use for many years, > including some of boost libraries. > pybind11 is easy to use and is much better than e.g., cython for > packaging c++ code. pybind11 is also header-only. > > I would also like to call attention for anyone interested in > scientific software and c++ to a wonderful library (header-only), > xtensor > https://xtensor.readthedocs.io/en/latest/ > > On Mon, Feb 15, 2021 at 7:15 AM Hans Dembinski <hans.dembinski(a)gmail.com> wrote: >> >> >>> On 15. Feb 2021, at 08:26, Andrew Nelson <andyfaff(a)gmail.com> wrote: >>> >>> My questions would be: >>> >>> - how portable is the boost code in general? >> >> It is very portable. The core goal of Boost is to offer implementations with quality and portability on par with the C++ standard library implementations. Non-portable extensions are sometimes used to speed up things, but there is always a standard compliant vanilla version. In practice, maintainers test portability with CI on Windows, OSX, Linux, using various versions of gcc, clang, msvc, intel, see e.g. >> >> https://github.com/boostorg/math/blob/develop/.github/workflows/ci.yml >> >> and the Boost build farm from the days before free CI for OSS was easily available, >> >> https://www.boost.org/development/tests/master/developer/move.html >> >> Not all compilers/platforms are fully compliant, of course. Boost uses workarounds to combat that and submits bug reports on the compiler bug trackers. >> >>> - how easy is it to install the library. >> >> As Nicholas mentioned, Boost.Math (and Boost.Histogram) is header-only, so it is sufficient to include the headers. >> >> Best regards, >> Hans >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev(a)python.org >> https://mail.python.org/mailman/listinfo/scipy-dev > > > > -- > Those who don't understand recursion are doomed to repeat it > > > ------------------------------ > > Message: 2 > Date: Mon, 15 Feb 2021 13:35:25 +0100 > From: Hans Dembinski <hans.dembinski(a)gmail.com> > To: SciPy Developers List <scipy-dev(a)python.org> > Subject: Re: [SciPy-Dev] Boost for stats > Message-ID: <13411649-82A4-4EC1-A58C-FAA3DDFF11D1(a)gmail.com> > Content-Type: text/plain; charset=us-ascii > > >> On 15. Feb 2021, at 01:47, Warren Weckesser <warren.weckesser(a)gmail.com> wrote: >> >> * The Boost histogram library might provide some benefits over the >> existing NumPy and SciPy options. (Hans Dembinski, the author >> of the histrogram library, has already commented in this email >> thread.) > > I would happily support this. We currently offer a Python front-end to Boost.Histogram > https://github.com/scikit-hep/boost-histogram > which includes a numpy.histogram compatible interface. > > Switching to Boost.Histogram may offer performance benefits, see > https://boost-histogram.readthedocs.io/en/latest/notebooks/PerformanceCompa… > > Compared to np.histogram we saw a 1.7 times increase - single threaded, more if multiple threads are used. Compared to np.histogram2d we saw a 11 times increase. These numbers should probably be checked more carefully before decisions are made. > > Boost.Histogram offers generalised histograms with arbitrary accumulators per cell, so it could also replace the implementations of https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.binned_sta… and friends. > > Best regards, > Hans > > ------------------------------ > > Message: 3 > Date: Mon, 15 Feb 2021 13:41:51 +0100 > From: Ralf Gommers <ralf.gommers(a)gmail.com> > To: SciPy Developers List <scipy-dev(a)python.org> > Subject: Re: [SciPy-Dev] Boost for stats > Message-ID: > <CABL7CQjYZh0CyA6Kx5FULw2KaYMmdrLbm0Jecztc5+4z+r8OJg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, Feb 15, 2021 at 1:35 PM Hans Dembinski <hans.dembinski(a)gmail.com> > wrote: > >> >>> On 15. Feb 2021, at 01:47, Warren Weckesser <warren.weckesser(a)gmail.com> >> wrote: >>> >>> * The Boost histogram library might provide some benefits over the >>> existing NumPy and SciPy options. (Hans Dembinski, the author >>> of the histrogram library, has already commented in this email >>> thread.) >> >> I would happily support this. We currently offer a Python front-end to >> Boost.Histogram >> https://github.com/scikit-hep/boost-histogram >> which includes a numpy.histogram compatible interface. >> >> Switching to Boost.Histogram may offer performance benefits, see >> >> https://boost-histogram.readthedocs.io/en/latest/notebooks/PerformanceCompa… >> >> Compared to np.histogram we saw a 1.7 times increase - single threaded, >> more if multiple threads are used. Compared to np.histogram2d we saw a 11 >> times increase. These numbers should probably be checked more carefully >> before decisions are made. >> >> Boost.Histogram offers generalised histograms with arbitrary accumulators >> per cell, so it could also replace the implementations of >> https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.binned_sta… >> and friends. >> > > That would be really nice. binned_statistic is currently pure Python, and > can be a performance hotspot (I've seen multiple cases of that in dealing > with image and geospatial data). > > Cheers, > Ralf >

5 7

SciPy 2021 Conference Seeking Submissions and Reviewers
by Matt Haberland Feb. 20, 2021

Feb. 20, 2021

Dear SciPy Developers, Besides an incredible library, "SciPy" is also the name of a conference about scientific computing with Python and the scientific Python ecosystem as a whole. This year's conference, SciPy 2021 <https://www.scipy2021.scipy.org/>, will be held virtually from July 14 - July 16, with two days before for tutorials and two days after for developer sprints. Registration <https://www.scipy2021.scipy.org/register> is now open! There's nothing more motivating than a deadline, right? Well, there are just three days left to submit your talk, poster, or tutorial: submissions <https://www.scipy2021.scipy.org/talk-poster-presentations> are due at 11:59 p.m. on Monday, February 22. We also seek volunteers to review submissions over the next few weeks. Please indicate your interest here <https://docs.google.com/forms/d/e/1FAIpQLSeXp3VzmgzVmmJdBAiw7Nvi0O85oR7CAf0…> . Feel free to contact me if you have any questions about the conference, and I hope to "see" you there! Matt

1 0