Mailman 3 July 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

Code formatting: black
by Pamphile Roy July 5, 2021

July 5, 2021

Hi everyone, I have been recently working on using black on our code base. I have created this PR https://github.com/scipy/scipy/pull/14330 <https://github.com/scipy/scipy/pull/14330>. There are lots of points, hence I invite you to come over and comment directly instead of replying to this email. Thanks in advance for having a look, I hope we can make this work together! Cheers, Pamphile

2 3

qhull FFI
by Nil Goyette July 5, 2021

July 5, 2021

Hi all, I've been trying to use qhull in a Rust project so of course I wondered how SciPy managed to do it before I tried to code my own FFI. When my version didn't work, I looked deeper in SciPy and there's something I don't understand. We can find several definitions In qhull_src/src/libqhull_r.h, like facetT ctypedef struct facetT: coordT offset coordT *center coordT *normal facetT *previous; facetT *next; ... a total of 16 fields And the "corresponding" definitions in qhull.pyx struct facetT { coordT offset; coordT *normal; union { 6 fields } coordT *center; facetT *next facetT *previoust ... A total of 37 fields Now I'm puzzled. There are several missing fields and they are wrongly ordered! I'm not a FFI expert at all but, as a programmer, I would have thought that the definitions needed to match perfectly, at least for the order and the number of bytes (total and per field). Can someone please explain to me why only some fields match and why this is not a problem? Thank you. Nil Goyette -- During this time of social distancing, we offer free webinars on subjects that matter. <https://www.imeka.ca/webinars/> CONFIDENTIALITY NOTICE: This message, and any attachments, is intended only for the use of the addressee or his authorized representative. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or his authorized representative, you are hereby notified that any dissemination, distribution or copying of this message and any attachments is strictly prohibited. The integrity of this message cannot be guaranteed on the Internet, IMEKA shall not be liable for its content if altered, changed or falsified. If you have received this message in error, please contact immediately the sender and delete this message and any attachments from your system. AVIS DE CONFIDENTIALITÉ : Ce message, ainsi que tout fichier qui y est joint, est destiné exclusivement aux personnes à qui il est adressé. Il peut contenir des informations de nature confidentielle qui ne doivent être divulguées en vertu des lois applicables. Si vous n'êtes pas le destinataire de ce message ou un mandataire autorisé de celui-ci, vous êtes avisé par la présente que toute impression, diffusion, distribution ou reproduction de ce message et de tout fichier qui y est joint est strictement interdite. L'intégrité de ce message n'étant pas assurée sur Internet, IMEKA ne peut être tenue responsable de son contenu s'il a été altéré, déformé ou falsifié. Si ce message vous a été transmis par erreur, veuillez en aviser sans délai l'expéditeur et l'effacer ainsi que tout fichier joint sans en conserver de copie.

2 2

Re: [SciPy-Dev] proposal to use SciPy project funds for build and CI improvements
by Pamphile Roy July 5, 2021

July 5, 2021

+1 for both the project and the new repository. (Glad to read about the log as well!) Thanks Ralf. Cheers, Pamphile > On 5 Jul 2021, at 00:01, Tyler Reddy <tyler.je.reddy(a)gmail.com> wrote: > > > +1 > >> On Sun, 4 Jul 2021 at 15:47, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: >> Hi all, >> >> I'd like to make a proposal to use some project funds to make faster progress on moving to a new build system and improving our CI timeout issues. >> >> Because this is the first such proposal, let me first deal with the meta issue of _how_ to deal with this. At the start of the year I co-wrote NEP 48 (https://numpy.org/neps/nep-0048-spending-project-funds.html) to have a framework for NumPy for spending project funds. I'd like to follow that NEP also for SciPy. So I'll make the proposal here, in accordance with that NEP, and then the other thing is to figure out where to put it up as a PR (or wiki page, or ...). For that my proposal is: create a new repo called something like `project-mgmt`, where we can put such proposals as well as meeting minutes, presentations, and other content. And have a single summary page in Markdown format with a list of all proposals made, linking out to the full proposals. >> >> On to the actual proposal, keeping in mind https://numpy.org/neps/nep-0048-spending-project-funds.html#defining-fundab…. >> >> Title: Accelerating the move to Meson as the SciPy build system >> Cost: $12,000 >> Time duration: 3 months >> Team members: Matthew Brett (funded), Ralf Gommers (unfunded), Gagandeep Singh (unfunded), Smit Lunagariya (funded) >> >> Context: >> Multiple people recently told me that our current build system and CI issues are a pain point for working on SciPy. We have CI timeouts on our main repo, scipy-wheels is a pain, conda-forge is also timing out on aarch64 and ppc64le build. And I've found myself spending a whole day or weekend several times in the past months to fix broken CI jobs due to build/packaging issues. >> About 4 months ago, I wrote an RFC to move to Meson as a build system, see https://github.com/scipy/scipy/issues/13615. Since then I have spent a lot of time on this, and also used Quansight Labs funding to get one of my colleagues, Gagandeep Singh, to help me move this forward faster (and he has been super helpful). Getting a Linux + OpenBLAS dev build is close to done (16 of 20 modules complete, all that's left is `misc`, `io`, `integrate` and `signal` - probably those can be completed in the coming week). >> Doing everything else, like adding support for Windows/aarch64/MKL/ILP64/etc. is still a lot of work. There's a tracking issue at https://github.com/rgommers/scipy/issues/22. Some of this stuff is pretty specialized, e.g., building wheels, and Fortran-on-Windows. It will take a long time to complete if it's just me spending time on the weekends. >> Matthew Brett is available to help soon. He has written multibuild and dealt with build/packaging topics for a long time, so I think he would be able to make progress quickly. He wants to work on this topic as an independent contractor (I won't add rates here, that's for the core team to look at - but they're very reasonable). >> The overall goals of this effort are: >> Get a (mostly) feature-complete Meson based build system in place by the end of October, so we can ship it in the 1.8.0 release. If all goes well, get rid of the `numpy.distutils` based build 1 release later. >> Resolve all our CI timeout issues. If the build system alone isn't enough (it should be though), analyze the remaining issues and figure out how to tackle whatever is still problematic. >> The deliverables are, in order of priority: >> Add capability to build release artifacts (wheels, sdist). I did some initial tests at the start with mesonpep517, but I have no idea if it works for SciPy and what bugs are lurking there. >> macOS support >> Add support for things we need to a dev.py interface (basically, like runtests.py in that it can do everything, like building docs, running benchmarks, etc.) >> Contribute a few things we need, or that would make the build setup better, to Meson. For example, I think we'd want to be able to use `py3.install_sources` on generated targets. Of course I'm still new-ish to Meson, so it could well be that after making a proposal on the Meson issue tracker, another solution will be preferred. >> Windows support >> Improve build dependency detection and configuration - in particular BLAS/LAPACK flavors. >> Clean up as many build warnings as possible, and silence the rest. The goal is to have a CI job that is completely silent (passes with `-Werror`). >> Optimize build time further, including on CI (e.g., reuse build cache between jobs). >> I'd like to use 75% of the funds to pay Matthew, and 25% of the funds to take on a talented intern, Smit Lunagariya. He is comfortable working in Python, C and C++, and will be able to help with deliverables 7 and 8, as well as with testing and other tasks. >> >> Overall I'm not certain that this amount of funds is enough to complete every last deliverable on this list; it's hard to estimate. But we should certainly get close, and be able to ship a Meson build in 1.8.0. >> >> For a quick sketch of the benefits: >> On my machine the build time is currently 13 minutes with numpy.distutils and 90 seconds with Meson >> The build log goes from >10,000 lines (mostly noise) to ~100 lines (mostly configuration info). >> Why should this be a funded activity? For two reasons: (1) build and CI issues are probably the number one maintenance issue we have, and (2) most people find working on build/CI boring and painful, and hence it doesn't happen with volunteer-only activities. Even regular maintenance of our CI is hard - recently jobs have been broken for 1-2 weeks at a time a couple of times. And the scipy-wheels repo is in even worse shape. >> >> My proposal is to designate this topic as high priority, let the core team approve the compensation levels for the funded people, and get the work started. For reporting on progress and to have some accountability about how we spent the funds, I propose a short report (say 1 page, giving a status update and linking the main PRs made or issues closed) when half the funds are spent, and another such report at the end. >> >> In addition I'll plan to write a small development grant for this when the next call for that opens up, because I think we want Matthew to continue working on this after this $12,000 has been spent. I'd like to get everything as good as it can be, so other projects can easily adopt Meson as well - to also achieve my not-so-secret goal of not having to integrate numpy.distutils capabilities into setuptools once distutils is removed from Python. >> >> Thoughts? >> >> Cheers, >> Ralf >> >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev(a)python.org >> https://mail.python.org/mailman/listinfo/scipy-dev > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev(a)python.org > https://mail.python.org/mailman/listinfo/scipy-dev

1 0

Static Typing
by Pamphile Roy July 4, 2021

July 4, 2021

Hi everyone, In a recent PR (https://github.com/scipy/scipy/pull/14284 <https://github.com/scipy/scipy/pull/14284>), we had a discussion about static typing. My understanding from previous PRs, the inclusion of MyPy in the CI and discussions during our last community meetups, was that we wanted to gradually start adding type annotations in our code base. Thanks to the great help of Bas van Beek and others, we have a few common bricks we can use to ease the process. What is your opinion about adding annotations? I expressed my position in the issue. TL;DR I am in favour of adding type annotations. This greatly helps anyone using an IDE and downstream libraries like SciKit-Learn are basically waiting for us. Lastly, I am putting here again the link to the last Python Community survey https://www.jetbrains.com/lp/python-developers-survey-2020/ <https://www.jetbrains.com/lp/python-developers-survey-2020/>, static typing is the most wanted feature. Cheers, Pamphile

8 11

GSoC: Integrating library UNU.RAN in SciPy
by Tirth Patel July 4, 2021

July 4, 2021

Hi all, I have been working on integrating UNU.RAN in scipy.stats for a few weeks on my fork (https://github.com/tirthasheshpatel/scipy/pull/6) with my mentors, Christoph and Nicholas. The design is still fairly basic but is almost ready for initial reviews. Also, it builds on Windows, macOS, and Linux. Tests pass with an exception of unrelated failures on Linux. I am planning to propose a PR on SciPy this week but before I do that, I thought it would be a good idea to summarize the progress here. The methods I propose to add and details regarding the parameters they take can be found in this excel sheet: https://docs.google.com/spreadsheets/d/1r36HypXwpit7sHt9YAe3K7yPL7HNNuQjTkb…. Feel free to comment on the sheet if you have any suggestions. The API looks something like this: import numpy as np from scipy.stats import TransformedDensityRejection pdf = lambda x: 1 - x*x dpdf = lambda x: -2*x urng = np.random.default_rng(123) rng = TransformedDensityRejection(pdf, dpdf, domain=(-1,1), seed=urng) # sample a 100,000 samples from the distribution rvs = rng.rvs(100_000) # evaluate the upper bound of the PPF at some points in the domain u = np.linspace(0, 1, num=1000) ppf_hat = rng.ppf_hat(u) Internal API ------------ For Python callbacks, I have used the `ccallback` API and used setjmp/longjmp for error handling. Using `ctypes` gives similar performance but I wasn't able to figure out a way to handle errors occurring in UNU.RAN and in the callbacks. Here is the C code I wrote to acquire and release the callbacks: https://github.com/tirthasheshpatel/scipy/blob/unuran_c_thunk/scipy/stats/u… For more details on the internal design of the API, I have attempted to create a few flowcharts on draw.io but they are very much a WIP: https://drive.google.com/file/d/1TH70SSvvc5eF6-YmDO8kFNvLqKaGROW-/view?usp=… Other Notes ----------- I think NumPy 1.19 introduced a stable interface for its Generator API. Before that the RandomState API was stable. But RandomState doesn't have a Cython Interface and its Python interface is very slow to be practically useful. For instance, it takes around 7ms to sample 100,000 samples from the normal distribution using the TDR method on NumPy >= 1.19 while it takes around 911ms on NumPy == 1.18 which is around 130 times slower! Is there a plan to drop 1.16 soon and can we use the unstable Generator API from 1.17 onwards or would it too unsafe? Maybe this discussion isn't suited here but I just thought to put it out as a note. Anyways, please feel free to comment on the design, naming convention, etc and suggest changes/ideas that would be good to incorporate before proposing a PR on SciPy. Thanks for reading this! -- Kind Regards, Tirth Patel

3 5