SciPy 1.0: fundamental algorithms for scientific computing in Python — TEI-tagged view

Pauli VirtanenpersName, Ralf GommerspersName, Travis E. OliphantpersName, Matt HaberlandpersName, Tyler ReddypersName, David CournapeaupersName, Evgeni BurovskipersName, Pearu PetersonpersName, Warren WeckesserpersName, Jonathan BrightpersName, Stéfan J. van der WaltpersName, Matthew BrettpersName, Joshua WilsonpersName, K. Jarrod MillmanpersName, Nikolay MayorovpersName, Andrew R. J. NelsonpersName, Eric JonespersName, Robert KernpersName, Eric LarsonpersName, C J CareypersName, İlhan PolatpersName, Yu FengpersName, Eric W. MoorepersName, Jake VanderPlaspersName, Denis LaxaldepersName, Josef PerktoldpersName, Robert CimrmanpersName, Ian HenriksenpersName, E. A. QuinteropersName, Charles R. HarrispersName, Anne M. ArchibaldpersName, Antônio H. RibeiropersName, Fabian PedregosapersName, Paul van MulbregtpersName, Aditya VijaykumarpersName, Alessandro Pietro BardellipersName, Alex RothbergpersName, Andreas HilbollpersName, Andreas KloecknerpersName, Anthony ScopatzpersName, Antony LeepersName, Ariel RokempersName, C. Nathan WoodspersName, Chad FultonpersName, Charles MassonpersName, Christian HäggströmpersName, Clark FitzgeraldpersName, David A. NicholsonpersName, David R. HagenpersName, Dmitrii V. PasechnikpersName, Emanuele OlivettipersName, Eric MartinpersName, Eric WieserpersName, Fabrice SilvapersName, Felix LenderspersName, Florian WilhelmpersName, G. YoungpersName, Gavin A. PricepersName, Gert-Ludwig IngoldpersName, Gregory E. AllenpersName, Gregory R. LeepersName, Hervé AudrenpersName, Irvin ProbstpersName, Jörg P. DietrichpersName, Jacob SilterrapersName, James T WebberpersName, Janko SlavičpersName, Joel NothmanpersName, Johannes BuchnerpersName, Johannes KulickpersName, Johannes L. SchönbergerpersName, José Vinícius de Miranda CardosopersName, Joscha ReimerpersName, Joseph HarringtonpersName, Juan Luis Cano RodríguezpersName, Juan Nunez-IglesiaspersName, Justin KuczynskipersName, Kevin TritzpersName, Martin ThomapersName, Matthew NewvillepersName, Matthias KümmererpersName, Maximilian BolingbrokepersName, Michael TartrepersName, Mikhail PakpersName, Nathaniel J. SmithpersName, Nikolai NowaczykpersName, Nikolay ShebanovpersName, Oleksandr PavlykpersName, Per A. BrodtkorbpersName, Perry LeepersName, Robert T. McGibbonpersName, Roman FeldbauerpersName, Sam LewispersName, Sam TygierpersName, Scott SievertpersName, Sebastiano VignapersName, Stefan PetersonpersName, Surhud MorepersName, Tadeusz PudlikpersName, Takuya OshimapersName, Thomas J. PingelpersName, Thomas P. RobitaillepersName, Thomas SpurapersName, Thouis R. JonespersName, Tim CerapersName, Tim LesliepersName, Tiziano ZitopersName, Tom KrausspersName, Utkarsh UpadhyaypersName, Yaroslav O. HalchenkopersName, Yoshiki Vázquez-BaezapersName (2020date). “SciPy 1.0: fundamental algorithms for scientific computing in Python.” Nature Methodstitle·j.

Object of study — SciPyterm 1.0 as scientific-computing software, technical architecture, development practice, and community infrastructure

Research question — what capabilities, implementation choices, recent improvements, quality practices, and governance make SciPyterm a foundational scientific-computing library

Contribution — an overview of SciPyterm 1.0 capabilities and development practices plus recent advances in sparseterm structures, compiled bindings, optimization, interpolation, testing, and benchmarking

Full text — tagged

The reference list is not part of the text we hold for this paper. Our copy was extracted from the publisher's page and the bibliography did not survive that extraction, so the article below ends before its references. Nothing has been removed by us.

SciPyterm 1.0: fundamental algorithmsterm·mth for scientific computing in Python Abstract SciPyterm is an open-source scientific computing libraryterm·mth for the Python programming languageterm·mth. Since its initial release in 2001, SciPyterm has become a de facto standard for leveraging scientific algorithmsterm·mth in Python, with over 600 unique code contributors, thousands of dependent packages, over 100,000 dependent repositories and millions of downloads per year. In this work, we provide an overview of the capabilities and development practices of SciPyterm 1.0 and highlight some recent technical developments.

Main SciPyterm is a library of numerical routines for the Python programming languageterm·mth that provides fundamental building blocksterm·mth for modeling and solving scientific problems. SciPyterm includes algorithmsterm·mth for optimization, integration, interpolation, eigenvalue problems, algebraic equations, differential equations and many other classes of problems; it also provides specialized data structuresterm, such as sparseterm matrices and k -dimensional trees. SciPyterm is built on top of NumPyterm 1 , 2 , which provides array data structuresterm and related fast numerical routines, and SciPyterm is itself the foundation upon which higher level scientific librariesterm, including scikit-learn 3 and scikit-image 4 , are built. Scientists, engineers and others around the world rely on SciPyterm. For example, published scripts 5 , 6 used in the analysis of gravitational waves 7 , 8 import several subpackagesterm of SciPyterm, and the M87 black hole imaging project cites SciPyterm 9 .

Recently, SciPyterm released version 1.0, a milestone that traditionally signals a library’s API (application programming interfaceterm·mth) being mature enough to be trusted in production pipelines. This version numbering convention, however, belies the history of a project that has become the standard others follow and has seen extensive adoption in research and industry.

SciPyterm’s arrival at this point is surprising and somewhat anomalous. When started in 2001, the library had little funding and was written mainly by graduate students—many of them without a computer science education and often without the blessing of their advisors. To even imagine that a small group of ‘rogue’ student programmers could upend the already well-established ecosystem of research software—backed by millions in funding and many hundreds of highly qualified engineers 10 – 12 —was preposterous.

Yet the philosophical motivations behind a fully open tool stack, combined with an excited, friendly community with a singular focus, have proven auspicious in the long run. They led not only to the library described in this paper, but also to an entire ecosystem of related packages ( https://wiki.python.org/moin/NumericAndScientific ) and a variety of social activities centered around them ( https://wiki.python.org/moin/PythonConferences ). The packages in the SciPy ecosystemterm share high standards of implementation, documentation and testing, and a culture eager to learn and adopt better practices—both for community management and software development.

Background Here we capture a selective history of some milestones and important events in the growth of SciPyterm. Despite what we highlight here, it is important to understand that a project like SciPyterm is only possible because of the contributions of very many contributors—too many to mention individually, but each bringing an important piece to the puzzle.

Python is an interpreted, high-level, general-purpose computer programming language, designed by Guido van Rossum in the late 1980s, with a dynamic type system and an emphasis on readability and rapid prototyping 13 ( https://github.com/python/cpython ). As a general-purpose programming languageterm·mth, it had no special support for scientific data structuresterm or algorithmsterm·mth, unlike many of the other established computation platforms of the time. Yet scientists soon discovered the language’s virtues, such as its ability to wrap C and Fortran libraries, and to then drive those libraries interactively. Scientists could thereby gain access to a wide variety of existing computational libraries without concerning themselves with low-level programming concepts such as memory management.

In 1995, Jim Hugunin, a graduate student at the Massachusetts Institute of Technology, wrote the first message in a new Python Matrix Special Interest Group (Matrix-SIG) mailing list 14 : “There seems to be a fair amount of interest in the Python community concerning the addition of numeric operations to Python. My own desire is to have as large a library of matrix based functions available as possible (linear algebra, eigenfunctions, signal processing, statistics, etc.). In order to ensure that all of these libraries interoperate, there needs to be agreement on a basic matrix object that can be used to represent arrays of numbers.”

Over the next several months, conversations on that mailing list by, among others, Jim FultonpersName, Jim Hugunin, Paul Dubois, Konrad Hinsen and Guido van Rossum led to the creation of a package called Numeric with an array object that supported a high number of dimensions. Jim Hugunin explained the utility of Python for numerical computation 15 : “I’ve used almost all of the available numerical languages at one time or another over the past 8 years. One thing I’ve noticed is that over time, the designers of these languages are steadily adding morepersName of the features that one would expect to find in a general-purpose programming languageterm·mth.”

This remains a distinguishing feature of Python for science and one of the reasons why it has been so successful in the realm of data science: instead of adding general features to a language designed for numerical and scientific computing, here scientific featuresterm·mth are added to a general-purpose language. This broadens the scope of problems that can be addressed easily, expands the sources of data that are readily accessible and increases the size of the community that develops code for the platform.

SciPyterm begins By the late 1990s, discussions appeared on Matrix-SIG expressing a desire for a complete scientific data analysis environment 16 . Travis OliphantpersName, a PhD student at the Mayo Clinic, released a number of packages 17 , 18 that built on top of the Numeric array package, and provided algorithmsterm·mth for signal processing, special functions, sparseterm matrices, quadrature, optimization, fast Fourier transforms and morepersName. One of these packages, Multipack ( http://pylab.sourceforge.net/multipack.html ), was a set of extension modules that wrapped Fortran and C libraries to solve nonlinear equations and least-squares problems, integrate differential equations and fit splines. Robert KernpersName, then an undergraduate student (and currently a SciPyterm core developer), provided compilation instructions under Windows. Around the same time, Pearu PetersonpersName, a PhD student from Estonia, released F2PY 19 , a command line tool for binding Python and Fortran codes, and wrote modules for linear algebra and interpolation. Eric JonespersName, while a graduate student at Duke University, wrote packages to support his dissertation, including a parallel job scheduler and genetic optimizer. Gary Strangman, a postdoctoral fellow at Harvard Medical School, published several descriptive and inferential statistical routines 20 .

With a rich programming environment and a numerical array object in place, the time was ripe for the development of a full scientific software stack. In 2001, Eric JonespersName and Travis Vaught founded Enthought Scientific Computing Solutions (now Enthought, Inc.) in Austin, Texas, USA. To simplify the tool stack, they created the SciPyterm project, centered around the SciPy libraryterm, which would subsume all the above-mentioned packages. The new project quickly gained momentum, with a website and code repository 21 appearing in February, and a mailing list announced 22 in June 2001. By August 2001, a first release was announced 23 , an excerpt of which is shown in Box 1 . In September, the first documentation was published 24 . The first SciPyterm workshop 25 was held in September 2002 at Caltech—a single track, two-day event with 50 participants, many of them developers of SciPyterm and surrounding libraries.

At this point, scientific Python started attracting morepersName serious attention; code that started as side projects by graduate students had grown into essential infrastructureterm at national laboratories and research institutes. For example, Paul Dubois at Lawrence Livermore National Laboratory (LLNL) took over the maintenance of Numeric and funded the writing of its manual 26 , and the Space Telescope Science Institute (STScI), which was in charge of Hubble Space Telescope science operations, decided to replace their custom scripting language and analysis pipeline with Python 27 . As STScI continued to use Python for an increasingly large portion of the Hubble Space Telescope data analysis pipeline, they encountered problems with the Python numerical array container. Numeric, the original array package, was suitable for small arrays, but not for the large images processed by STScI. With the Numeric maintainerterm’s blessing, the decision was made to write NumArray 28 , a library that could handle data on a larger scale. Unfortunately, NumArray proved inefficient for small arrays, presenting the community with a rather unfortunate choice. In 2005, Travis OliphantpersName combined the best elements of Numeric and NumArray, thereby solving the dilemma. NumPyterm 1.0 was released 29 in October 2006, paving the way for the reunified scientific Python community to mature.

SciPyterm matures By the middle to late 2000s, SciPyterm was starting to mature after a long phase of significant growth and adoption. The scope of the SciPy libraryterm narrowed, while the breadth of the ecosystem grew through a new type of auxiliary package: the scikitterm·mth ( https://www.scipyterm.org/scikitsterm·mth.html ), a complementary library developed outside SciPyterm, allowing for morepersName rapid exploration of experimental ideas while maintaining familiar style and development methodology. In SciPyterm itself, tooling, development, documentation and release processes became morepersName professional. The library was expanded carefully, with the patience affordable in open-source projects and via best practices, which are increasingly common in the scientific Python ecosystem and industry 30 .

Early versions of SciPyterm had minimal documentation, but this began to change with the 2006 release of a Guide to NumPyterm 1 . In 2007, Sphinx 31 made it possible to render hypertext and PDF documents automatically from plain text (docstrings) interspersed with Python code, and in 2008, pydocweb 32 enabled collaborative documentation development in a wiki-like fashion. The SciPyterm Documentation Project 33 , 34 used these tools to complete documentation of SciPyterm’s user-facing functionality: offering t-shirts to contributors from around the world in exchange for high-quality text, it collected contributions from over 75 people to produce an 884-page manual 35 . Since then, SciPyterm has remained committed to maintaining high-quality documentation as part of the normal development cycle.

In the early SciPyterm workshops, recurrent topics reflected the state of development, with emphasis being placed on the underlying array package, plotting, parallel processing, acceleration/wrapping and user interfaces. By 2004, presentations about the application of SciPyterm to scientific problems began to appear. The event also started to draw in morepersName keynote speakers from outside the community, such as Guido van Rossum (creator of Python, 2006), Ivan Krstić (One Laptop per Child, 2007), Alex Martelli (Google, 2008) and Peter Norvig (Google Research, 2009). The informal workshop grew from a small gathering of core developers into an international conference with hundreds of attendees, increased funding, a published proceedings and scholarships for attending students. By 2010, the US SciPyterm conference had multiple tracks, and satellite conferences were being organized by volunteers elsewhere, such as EuroSciPy (since 2008) and SciPyterm India (since 2009). Special sessions and minisymposia dedicated to scientific Python began appearing at many other events. For example, a three-part minisymposium organized for International Conferences on Computational Science and Engineering (CSE) 2009 was featured in SIAM News 36 .

In 2007, Python had a strong enough presence in science and engineering that the editors of IEEE Computing in Science and Engineering solicited a special issue about Python in science 37 , edited by Paul Dubois. However, Python was still sufficiently niche that the average reader would need additional information to decide whether it would be useful in their own work. The follow-up March/April 2011 Python for Scientists and Engineers special issue 38 focused morepersName on the core parts of the scientific Python ecosystem 39 including NumPyterm 2 , Cython 40 and Mayavi 41 . Python became so pervasive that journals began publishing domain-specific special issues. For example, in 2015, Frontiers in Neuroinformatics published a collectionterm of 25 articles—covering topics including modeling and simulation, data collectionterm, electrophysiology, visualization as well as stimulus generation and presentation—called Python in Neuroscience 42 .

SciPyterm today As of February 2019, the SciPy libraryterm consists of nearly 600,000 lines of open-source code organized in 16 subpackagesterm summarized in Box 2 . The development team and community currently interact and operate primarily on GitHub, an online version control and task management platform. Over 110,000 GitHub repositories and 6,500 packages depend on SciPyterm 43 . Some of the major feature highlights from the three years preceding SciPyterm 1.0 are discussed in the “Key technical improvements” section below, and milestones in its history are highlighted in Fig. 1 . Fig. 1 Major milestones from SciPyterm’s initial release in 2001 to the release of SciPyterm 1.0 in 2017. Note that SciKitsterm·mth and GitHub have been introduced in the Background section; morepersName information about Cython and SciPyterm subpackagesterm (for example, scipyterm.sparseterm) is available in the ‘Architecture and implementation choices’ section, BLAS/LAPACK support is detailed in the ‘Key technical improvements’ section, and continuous integrationterm is discussed in the ‘Test and benchmark suiteterm’ section.

SciPyterm is an open-source package that builds on the strengths of Python and Numeric, providing a wide range of fast scientific and numeric functionality. SciPyterm’s current module set includes the following: Special functions (Bessel, Hankel, Airy and others) Signal/image processing 2D plotting capabilities Integration ODE solvers Optimization (simplex, BFGS, Newton-CG and others) Genetic algorithmsterm·mth Numeric to C++ expression compiler Parallel programming tools Splines and interpolation Other items The SciPy libraryterm is organized as a collectionterm of subpackagesterm. The 16 subpackagesterm include mathematical building blocksterm (for example, linear algebra, Fourier transforms, special functions), data structuresterm (for example, sparseterm matrices, k -D trees), algorithmsterm·mth (for example, numerical optimization and integration, clustering, interpolation, graph algorithmsterm·mth, computational geometry) and higher-level data analysis functionalityterm·mth (for example, signal and image processing, statistical methods).

Here we summarize the scope and capabilities of each subpackageterm. Additional information is available in the SciPyterm tutorial ( https://docs.scipyterm.org/doc/scipyterm/reference/tutorial/ ) and API reference ( https://docs.scipyterm.org/doc/scipyterm/reference/index.html#api-reference ).

cluster The cluster subpackageterm contains cluster.vq, which provides vector quantization and k -means algorithmsterm·mth, and cluster.hierarchy, which provides functions for hierarchical and agglomerative clustering.

constants Physical and mathematical constants, including the CODATA recommended values of the fundamental physical constants 119 .

fftpack Fast Fourier Transform routines. In addition to the FFT itself, the subpackageterm includes functions for the discrete sine and cosine transforms and for pseudo-differential operators.

integrate The integrate subpackageterm provides tools for the numerical computation of single and multiple definite integrals and for the solution of ordinary differential equations, including initial value problems and two-point boundary value problems.

interpolate The interpolate subpackageterm contains spline functions and classes, one-dimensional and multi-dimensional (univariate and multivariate) interpolation classes, Lagrange and Taylor polynomial interpolators, and wrappers for FITPACK 53 and DFITPACK functions.

A collectionterm of functions and classes for reading and writing Matlab ( https://www.mathworks.com/products/matlab.html ), IDL, Matrix Market 120 , Fortran, NetCDF 121 , Harwell-Boeing 122 , WAV and ARFF data files.

linalg Linear algebra functions, including elementary functions of a matrix, such as the trace, determinant, norm and condition number; basic solver for Ax = b ; specialized solvers for Toeplitz matrices, circulant matrices, triangular matrices and other structured matrices; least-squares solver and pseudo-inverse calculations; eigenvalue and eigenvector calculations (basic and generalized); matrix decompositions, including Cholesky, Schur, Hessenberg, LU , LDL T , QR , QZ , singular value and polar; and functions to create specialized matrices, such as diagonal, Toeplitz, Hankel, companion, Hilbert and morepersName.

ndimage This subpackageterm contains various functions for multi-dimensional image processing, including convolution and assorted linear and nonlinear filters (Gaussian filter, median filter, Sobel filter and others); interpolation; region labeling and processing; and mathematical morphology functions.

misc A collectionterm of functions that did not fit into the other subpackagesterm. Although this subpackageterm still exists in SciPyterm 1.0, an effort is underway to deprecate or relocate the contents of this subpackageterm and remove it.

odr Orthogonal distance regression, including Python wrappers for the Fortran library ODRPACK 54 .

optimize This subpackageterm includes simplex and interior-point linear programming solvers, implementations of many nonlinear minimization algorithmsterm·mth, a routine for least-squares curve fitting, and a collectionterm of general nonlinear solvers for root-finding.

signal The signal subpackageterm focuses on signal processing and basic linear systems theory. Functionality includes convolution and correlation, splines, filtering and filter design, continuous and discrete time linear systems, waveform generation, window functions, wavelet computations, peak finding and spectral analysis.

sparseterm This subpackageterm includes implementations of several representations of sparseterm matrices. scipyterm.sparseterm.linalg provides a collectionterm of linear algebra routines that work with sparseterm matrices, including linear equation solvers, eigenvalue decomposition, singular value decomposition and LU factorization. scipyterm.sparseterm.csgraph provides a collectionsterm of graph algorithmsterm·mth for which the graph is represented using a sparseterm matrix. Algorithmsterm·mth include connected components, shortest path, minimum spanning tree and morepersName.

spatialterm This subpackageterm provides spatialterm data structuresterm and algorithmsterm·mth, including the k -d tree, Delaunay triangulation, convex hulls and Voronoi diagrams. scipyterm.spatialterm.distance provides a large collectionterm of distance functions, along with functions for computing the distance between all pairs of vectors in a given collectionterm of points or between all pairs from two collectionsterm of points.

special The name comes from the class of functions traditionally known as special functions, but over time, the subpackageterm has grown to include functions beyond the classical special functions. A morepersName appropriate characterization of this subpackageterm is simply useful functions. It includes a large collectionterm of the classical special functions such as Airy, Bessel and others; families of orthogonal polynomials; the Gamma function, and functions related to it; functions for computing the PDF, CDF and quantile function for several probability distributionsterm; information theory functions; combinatorial functions comb and factorial; and morepersName.

stats The stats subpackageterm provides a large collectionterm of continuous and discrete probability distributionsterm, each with methods to compute the PDF or PMF, CDF, moments and other statistics, generation of random variates and morepersName; statistical tests, including tests on equality of means/medians/variance (such as the t -test) and tests whether a sample is drawn from a certain distribution (such as the Kolmogorov-Smirnov test); measures of correlation, including Pearson’s r , Kendall’s τ , and Spearman’s ρ coefficients; descriptive statistics including trimmed values; kernel density estimation; and transformations of data such as the Box-Cox power transformation.

Architecture and implementation choices Project scope SciPyterm provides fundamental algorithmsterm·mth for scientific computing. The breadth of its scope was derived from the guide to available mathematical software (GAMS) classification system 44 . In areas that move relatively slowly, for example, linear algebra, SciPyterm aims to provide complete coverage. In other areas it aims to provide fundamental building blocksterm·mth while interacting well with other packages specialized in that area. For example, SciPyterm provides what one expects to find in a statistics textbook (probability distributionsterm, hypothesis tests, frequency statistics, correlation functions, and morepersName), whereas Statsmodels 45 provides morepersName advanced statistical estimators and inference methods, scikit-learn 3 covers machine learning, and PyMC3 46 , emcee 47 and PyStan ( http://mc-stan.org ) cover Bayesian statistics and probabilistic modeling. scikit-image 4 provides image processing capabilities beyond SciPyterm’s ndimage, SymPy 48 provides a Python interface for symbolic computation, and sparseterm.csgraph and spatialterm offer basic tools for working with graphs and networks compared to specialized libraries such as NetworkX 49 .

We use the following criteria to determine whether to include new functionality in SciPyterm: The algorithmterm·mth is of relevance to multiple fields of science. The algorithmterm·mth is demonstrably important. For example, it is classic enough to be included in textbooks, or it is based on a peer-reviewed article that has a substantial number of citations.

In terms of software systems and architecture, SciPyterm’s scope matches NumPyterm’s: algorithmsterm·mth for in-memory computing on single machines, with support for a wide range of data typesterm·var and process architecturesterm·var. Distributed computing and support for graphics processing units (GPUs) were explicitly out of scope at the 1.0 release point, but this has been revised in our roadmap (see Discussion).

Language choices According to analysis using the linguist library ( https://github.com/github/linguist ), SciPyterm is approximately 50% Python, 25% Fortran, 20% C, 3% Cython and 2% C++, with a dash of TeX, Matlab, shell script and Make. The distribution of secondary programming languages in SciPyterm is a compromise between a powerful, performance-enhancing language that interacts well with Python (that is, Cython) and the usage of languages (and their libraries) that have proven reliable and performant over many decades.

Fortran, despite its age, is still a high-performance scientific programming language with continued contemporary usage 50 . Thus, we wrap the following excellent, field-tested Fortran libraries to provide Python convenience while benefiting from their performanceterm: QUADPACK 51 and ODEPACK 52 for numerical integration and solution of initial value problems; FITPACK 53 , ODRPACK 54 and MINPACK 55 for curve-fitting and least-squares minimization; FFTPACK 56 , 57 for performing Fourier transforms; ARPACK 58 for solving eigenvalue problems; ALGORITHMterm·mth 644 (ref. 59 ) for computing Bessel functions; and CDFLIB 60 for evaluating cumulative density functions.

Rounding out the top three languages in SciPyterm is C, which is also extremely well-established over several decades 61 of scientific computing. The C libraries that we wrap in SciPyterm include trlib 62 for optimization, SuperLU 63 , 64 for solving sparseterm linear systems, Qhull 65 for computational geometry and Cephes ( http://www.netlib.org/cephes/ ) for special functions.

Cython has been described as a creole language that mixes the best parts of Python and lower-level C/C++ paradigms 40 . We often use Cython as a glue between well-established, low-level scientific computing libraries written in C/C++ and the Python interface offered by SciPyterm. We also use Cython to enable performanceterm enhancements in Python code, especially for cases where heavily used inner loops benefit from a compiled code with static typing.

For implementing new functionality, Python is the still the language of choice. If Python performanceterm·var is an issue, then we prefer the use of Cython followed by C, C++ or Fortran (in that order). The main motivation for this is maintainability: Cython has the highest abstraction level, and most Python developers will understand it. C is also widely known, and easier for the current core development team to manage than C++ and especially Fortran.

The position that SciPyterm occupies near the foundation of the scientific Python ecosystem is such that adoption of new languages or major dependencies is generally unlikely; our choices are strongly driven by long-term stability. GPU acceleration, new transpiling libraries and the latest JIT compilation approaches (for example, Numba 66 ) are very powerful but have traditionally fallen outside the remit of the main SciPy libraryterm. That said, we have recently increased our efforts to support compatibility with some of these options, and our full test suiteterm·mth passed with the PyPy JIT compiler 67 at the 1.0 release point.

API and ABI evolution The API for SciPyterm consists of approximately 1,500 functions and classes. Our policy for evolving the API over time is that new functionality can be added, while removing or changing existing functionality can only be done if the benefits exceed the (often significant) costs to users and only after giving clear deprecation warnings to those users for at least one year. In general, we encourage changes that improve clarity in the API of the library but strongly discourage breaking backward compatibility, given our position near the base of the scientific Python computing stack.

In addition to the Python API, SciPyterm has C and Cython interfaces. Therefore, we also have to consider the application binary interface (ABI). This ABI has been stable for a long time, and we aim to evolve it only in a backward-compatible way.

Key technical improvements Here we describe key technical improvements made in the last three years.

Data structuresterm Sparseterm matrices scipyterm.sparseterm offers seven sparse matrix data structuresterm, also known as sparse formatsterm. The most important ones are the row- and column-compressed formats (CSRterm and CSCterm, respectively). These offer fast major-axis indexingterm·var and fast matrix-vector multiplicationterm·var, and are used heavily throughout SciPyterm and dependent packages.

Over the last three years, our sparseterm matrix handling internals were rewritten and performanceterm was improved. Iterating over and slicing of CSCterm and CSRterm matrices is now up to 35% faster, and the speed of coordinate (COO)/diagonal (DIA) to CSRterm/CSCterm matrix format conversions has increased. SuperLU 63 was updated to version 5.2.1, enhancing the low-level implementations leveraged by a subset of our sparseterm offerings.

From a new features standpoint, scipyterm.sparseterm matrices and linear operators now support the Python matrix multiplication (@) operator. We added scipyterm.sparseterm.norm and scipyterm.sparseterm.random for computing sparseterm matrix norms and drawing random variates from arbitrary distributions, respectively. Also, we made a concerted effort to bring the scipyterm.sparseterm API into line with the equivalent NumPyterm API where possible.

cKDTreeterm·mth The scipyterm.spatialterm.ckdtreeterm·mth module, which implements a space-partitioning data structureterm that organizes points in k -dimensional space, was rewritten in C++ with templated classes. Support was added for periodic boundary conditions, which are often used in simulations of physical processes.

In 2013, the time complexity of the k -nearest-neighbor searchterm from cKDTreeterm·mth.query was approximately loglinear 68 , consistent with its formal description 69 . Since then, we enhanced cKDTreeterm·mth.query by reimplementing it in C++term, removing memory leaks and allowing release of the global interpreter lock (GIL) so that multiple threads may be used 70 . This generally improved performanceterm on any given problem while preserving the asymptotic complexity.

In 2015, SciPyterm added the sparseterm_distance_matrix routine for generating approximate sparseterm distance matrices between KDTree objects by ignoring all distances that exceed a user-provided value. This routine is not limited to the conventional L2 (Euclidean) norm but supports any Minkowski p -norm between 1 and infinity. By default, the returned data structureterm is a dictionary of keys (DOK)-based sparseterm matrix, which is very efficient for matrix construction. This hashing approach to sparseterm matrix assembly can be seven times faster than constructing with CSRterm format 71 , and the C++ level sparseterm matrix construction releases the Python GIL for increased performanceterm. Once the matrix is constructed, distance value retrieval has an amortized constant time complexity 72 , and the DOK structure can be efficiently converted to a CSRterm, CSCterm or COO matrix to allow for speedy arithmetic operations.

In 2015, the cKDTreeterm·mth dual tree counting algorithmterm·mth 73 was enhanced to support weights 74 , which are essential in many scientific applications, for example, computing correlation functions of galaxies 75 .

Unified bindings to compiled code LowLevelCallable As of SciPyterm version 0.19, it is possible for users to wrap low-level functions in a scipy.LowLevelCallableterm·mth object that reduces the overheadterm of calling compiled C functions, such as those generated using Numba or Cython, directly from Python. Supported low-level functions include PyCapsule objects, ctypes function pointers and cffi function pointers. Furthermore, it is possible to generate a low-level callback function automatically from a Cython module using scipy.LowLevelCallableterm·mth.from_cython.

Cython bindings for BLAS, LAPACK and special SciPyterm has provided special functions and leveraged basic linear algebra subprograms (BLAS) and linear algebra package (LAPACK) 76 routines for many years. SciPyterm now additionally includes Cython 40 wrappers for many BLAS and LAPACK routines (added in 2015) and the special functions provided in the scipyterm.special subpackageterm (added in 2016), which are available in scipyterm.linalg.cython_blas, scipyterm.linalg.cython_lapack and scipyterm.special.cython_special, respectively. When writing algorithmsterm·mth in Cython, it is typically morepersName efficient to call directly into the libraries SciPyterm wraps rather than indirectly, using SciPyterm’s Python APIs. These low-level interfaces for Cython can also be used outside of the SciPyterm codebase to gain access to the functions in the wrapped libraries while avoiding the overheadterm of Python function calls. This can give performance gainsterm of one or two orders of magnitude for many use cases.

Developers can also use the low-level Cython interfacesterm without linking against the wrapped libraries 77 . This lets other extensions avoid the complexity of finding and using the correct libraries. Avoiding this complexity is especially important when wrapping libraries written in Fortran. Not only can these low-level wrappers be used without a Fortran compiler, they can also be used without having to handle all the different Fortran compiler ABIs and name mangling schemes.

Most of these low-level Cython wrappers are generated automatically to help with both correctness and ease of maintenance. The wrappers for BLAS and LAPACK are primarily generated using type information that is parsed from the BLAS and LAPACK source files using F2PY 19 , though a small number of routines use hand-written type signatures instead. The input and output types of each routine are saved in a data file that is read at build time and used to generate the corresponding Cython wrapper files. The wrappers in scipyterm.special.cython_special are also generated from a data file containing type information for the wrapped routines.

Since SciPyterm can be built with LAPACK 3.4.0 or later, Cython wrappers are only provided for the routines that maintain a consistent interface across all supported LAPACK versions. The standard BLAS interface provided by the various existing BLAS libraries is not currently changing, so changes are not generally needed in the wrappers provided by SciPyterm. Changes to the Cython wrappers for the functions in scipyterm.special follow corresponding changes to the interface of that subpackageterm.

Numerical optimization The scipyterm.optimize subpackageterm provides functions for the numerical solution of several classes of root finding and optimization problems. Here we highlight recent additions through SciPyterm 1.0.

Linear optimization A new interior-point optimizerterm for continuous linear programming problems, linprog with method = ’interior-point’, was released with SciPyterm 1.0. Implementing the core algorithmterm·mth of the commercial solver MOSEK 78 , it solves all of the 90+ NETLIB LP benchmark problems 79 tested. Unlike some interior point methods, this homogeneous self-dual formulationterm provides certificates of infeasibility or unboundedness as appropriate.

A presolve routineterm 80 solves trivial problems and otherwise performs problem simplifications, such as bound tightening and removal of fixed variables, and one of several routines for eliminating redundant equality constraints is automatically chosen to reduce the chance of numerical difficulties caused by singular matrices. Although the main solver implementation is pure Python, end-to-end sparseterm matrix support and heavy use of SciPyterm’s compiled linear system solvers—often for the same system with multiple right hand sides owing to the predictor-corrector approach—provide speed sufficient for problems with tens of thousands of variables and constraints.

Nonlinear optimization: local minimization The minimize functionterm provides a unified interface for finding local minima of nonlinear optimization problems. Four new methods for unconstrained optimization were added to minimize in recent versions of SciPyterm: dogleg, trust-ncg, trust-exact and trust-krylov. All are trust-region methods that build a local model of the objective function based on first and second derivative information, approximate the best point within a local ‘trust region’ and iterate until a local minimum of the original objective function is reached, but each has unique characteristics that make it appropriate for certain types of problems. For instance, trust-exact achieves fast convergence by solving the trust-region subproblem almost exactly, but it requires the second derivative Hessian matrix to be stored and factored every iteration, which may preclude the solution of large problems (≥1,000 variables). In contrast, trust-ncg and trust-krylov are well suited to large-scale optimization problems because they do not need to store and factor the Hessian explicitly, instead using second derivative information in a faster, approximate way. We compare the characteristics of all minimize methods in detail in Table 1 , which illustrates the level of completeness that SciPyterm aims for when covering a numerical method or topic. Table 1 Optimization methods from minimize Nelder-Mead Powell COBYLA CG BFGS L-BFGS-G SLSQP TNC Newton-CG dogleg trust-ncg trust-exact trust-Krylov Version added 0.6* 0.6* 0.6* 0.6* 0.6* 0.6* 0.9 0.6* 0.6* 0.13 0.13 0.19 1.0 Wrapper ✓ ✓ ✓ ✓ ✓ First derivatives ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Second derivatives ~ ~ ~ ✓ ✓ ✓ ✓ ✓ ✓ Iterative Hessian factorization ✓ ✓ ✓ ✓ Local convergence L S L S S* S* Q S* Q S* Global convergence ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Trust region Neither LS TR LS LS LS LS LS LS TR TR TR TR Bound constraints ✓ ✓ ✓ ✓ Equality constraints ✓ Inequality constraints ✓ ✓ References 98 , 99 100 101 – 103 104 , 105 105 106 , 107 108 – 111 112 105 105 , 113 105 , 114 115 , 116 62 , 117 Optimization methods from minimize, which solves problems of the form min x f x , where x ∈ R n and f : R n → R . ‘Version added’ specifies the algorithmterm·mth’s first appearance in SciPyterm. Algorithmsterm·mth with version added “0.6*” were added in version 0.6 or before. ‘Wrapper’ indicates whether the implementation available in SciPyterm wraps a function written in a compiled language (for example, C or FORTRAN). ‘First derivatives’ and ‘second derivatives’ indicate whether first or second order derivatives are required. When ‘second derivatives’ is flagged with ‘~’, the algorithmterm·mth accepts but does not require second-order derivatives from the user; it computes an approximation internally and uses it to accelerate method convergence. ‘Iterative Hessian factorization’ denotes algorithmsterm·mth that factorize the Hessian in an iterative way, which does not require explicit matrix factorization or storage of the Hessian. ‘Local convergence’ gives a lower bound on the rate of convergence of the iteration sequence once the iterate is sufficiently close to the solution: linear (L), superlinear (S) and quadratic (Q). Convergence rates denoted S* indicate that the algorithmterm·mth has a superlinear rate for the parameters used in SciPyterm, but can achieve a quadratic convergence rate with other parameter choices. ‘Global convergence’ is marked for the algorithmsterm·mth with guarantees of convergence to a stationary point (that is, a point x * for which ∇ f x * = 0 ); this is not a guarantee of convergence to a global minimum. ‘Lines-search’ (LS) or ‘trust-region’ (TR) indicates which of the two globalization approaches is used by the algorithmterm·mth. The table also indicates which algorithmsterm·mth can deal with constraints on the variables. We distinguish among bound constraints ( x l ≤ x ≤ x u ), equality constraints ( c eq x = 0 ) and inequality constraints ( c ineq x ≥ 0 ).

Nonlinear optimization: global minimization As minimize may return any local minimum, some problems require the use of a global optimization routine. The new scipy.optimize.differential_evolutionterm function 81 , 82 is a stochastic global optimizerterm·mth that works by evolving a population of candidate solutions. In each iteration, trial candidates are generated by combination of candidates from the existing population. If the trial candidates represent an improvement, then the population is updated. Most recently, the SciPyterm benchmark suiteterm gained a comprehensive set of 196 global optimization problems for tracking the performanceterm of existing solvers over time and for evaluating whether the performanceterm of new solvers merits their inclusion in the package.

Statistical distributions The scipyterm.stats subpackageterm contains morepersName than 100 probability distributionsterm: 96 continuous and 13 discrete univariate distributions, and 10 multivariate distributions. The implementation relies on a consistent framework that provides methods to sample random variates, to evaluate the cumulative distribution function (CDF) and the probability density function (PDF), and to fit parameters for every distribution. Generally, the methods rely on specific implementations for each distribution, such as a closed-form expression of the CDF or a sampling algorithmterm·mth, if available. Otherwise, default methods are used based on generic code, for example, numerical integration of the PDF to obtain the CDF. Key recent distributions added to scipyterm.stats include the histogram-based distribution in scipyterm.stats.rv_histogram and the multinomial distribution in scipyterm.stats.multinomial (used, for example, in natural language processing 83 ).

Polynomial interpolators Historically, SciPyterm relied heavily on the venerable FITPACK Fortran library by P. Dierckx 53 , 84 for univariate interpolation and approximation of data, but the original monolithic design and API for interaction between SciPyterm and FITPACK was limiting for both users and developers.

Implementing a new, modular design of polynomial interpolators was spread over several releases. The goals of this effort were to have a set of basic objects representing piecewise polynomialsterm, to implement a collectionterm of algorithmsterm·mth for constructing various interpolators, and to provide users with building blocks for constructing additional interpolators.

At the lowest level of the new design are classes that represent univariate piecewise polynomialsterm: PPoly (SciPyterm 0.13) 85 , BPoly (SciPyterm 0.13) and BSpline (SciPyterm 0.19) 86 , which allow efficient vectorized evaluations, differentiation, integration and root-finding. PPoly represents piecewise polynomialsterm in the power basis in terms of breakpoints and coefficients at each interval. BPoly is similar and represents piecewise polynomialsterm in the Bernstein basis (which is suitable, for example, for constructing Bézier curves). BSpline represents spline curvesterm, that is, linear combinations of B-spline basis elementsterm 87 .

In the next layer, these polynomial classes are used to construct several common ways of interpolating data: CubicSpline (SciPyterm 0.18) 88 constructs a twice differentiable piecewise cubic function, Akima1DInterpolator and PCHIPInterpolator implement two classic prescriptions for constructing a C 1 continuous monotone shape-preserving interpolator 89 , 90 .

Test and benchmark suiteterm Test suiteterm·mth Test-driven development has been described as a way to manage fear and uncertainty when making code changes 91 . For each component of SciPyterm, we write multiple small executable tests that verify its intended behavior. The collectionterm of these, known as a ‘test suiteterm·mth’, increases confidence in the correctness and accuracyterm of the library, and allows us to make code modifications known not to alter desired behavior. According to the practice of continuous integrationterm 92 , all proposed contributions to SciPyterm are temporarily integrated with the master branch of the library before the test suiteterm·mth is run, and all tests must be passed before the contribution is permanently merged. Continuously monitoring the number of lines of code in SciPyterm covered by unit tests is one way we maintain some certainty that changes and new features are correctly implemented.

The SciPyterm test suiteterm·mth is orchestrated by a continuous integrationterm matrix that includes POSIX and Windows (32/64-bit) platforms managed by Travis CI and AppVeyor, respectively. Our tests cover Python versions 2.7, 3.4, 3.5, 3.6, and include code linting with pyflakes and pycodestyle. There are morepersName than 13,000 unit tests in the test suiteterm·mth, which is written for usage with the pytest ( https://docs.pytest.org/en/latest ) framework. In Fig. 2 , we show historical test coverageterm data generated using a Docker-based approach ( https://github.com/tylerjereddy/scipy-cov-track ). With the exception of the removal of ∼61,000 lines of compiled code for SciPyterm v0.14, the volume of both compiled (C, C++ and Fortran) and Python code has increased between releases, as have the number of lines covered by unit tests. Test coverageterm at the SciPyterm 1.0 release point was at 87% for Python code according to pytest-cov ( https://pypi.org/project/pytest-cov/ ). Coverage of compiled (C, C++ and Fortran) code was only 45% according to gcov ( https://gcc.gnu.org/onlinedocs/gcc/Gcov.html ), but the compiled codebase is much morepersName robust than this figure would suggest as the figure does not correct for the inclusion of reputable vendor code, the original library of which is well-tested; generated code, for which full coverage is impractical; and deprecated code, which does not require unit tests. Documentation for the code is automatically built and published by the CircleCI service to facilitate evaluation of documentation changes/integrity. Fig. 2 Python and compiled code volume in SciPyterm over time.

Benchmark suiteterm In addition to ensuring that unit tests are passing, it is important to confirm that the performanceterm of the SciPyterm codebase improves over time. Since February 2015, the performanceterm of SciPyterm has been monitored with Airspeed Velocity (asv https://github.com/airspeed-velocity/asv ). SciPyterm’s run.py script conveniently wraps asv features such that benchmark results over time can be generated with a single console command. For example, in Fig. 3 we illustrate the improvement of scipyterm.spatialterm.cKDTreeterm·mth.query over roughly nine years of project history. The tree used in the benchmark was generated without application of toroidal topology (boxsize = None), and tests were performed by Airspeed Velocity 0.4 using Python 2.7, NumPyterm 1.8.2 and Cython versions 0.27.3, 0.21.1 and 0.18 (for improved backward compatibility). Substantial performanceterm improvements were realized when cKDTreeterm·mth was fully Cythonized and again when it was rewritten in C++. Fig. 3 Results of the scipyterm.spatialterm.cKDTreeterm·mth.query benchmark from the introduction of cKDTreeterm·mth to the release of SciPyterm 1.0. The benchmark generates a k -d tree from uniformly distributed points in an m -dimensional unit hypercube, then finds the nearest (Euclidean) neighbor in the tree for each of 1,000 query points. Each marker in the figure indicates the execution timeterm·var of the benchmark for a commit in the master branch of SciPyterm.

Project organization and community Governance SciPyterm adopted an official governance document ( https://docs.scipyterm.org/doc/scipyterm/reference/dev/governance/governance.html ) on August 3, 2017. A steering councilterm, currently composed of 18 members, oversees daily development of the project by contributing code and reviewing contributions from the community. Council members have commit rights to the project repository, but they are expected to merge changes only when there are no substantive community objections. The chair of the steering councilterm, Ralf GommerspersName, is responsible for initiating biannual technical reviews of project direction and summarizing any private council activities to the broader community. The project’s benevolent dictator for life, Pauli VirtanenpersName, has overruling authority on any matter, but is expected to act in good faith and only exercise this authority when the steering councilterm cannot reach agreement.

SciPyterm’s official code of conduct was approved on October 24, 2017. In summary, there are five specific guidelines: be open to everyone participating in our community; be empathetic and patient in resolving conflicts; be collaborative, as we depend on each other to build the library; be inquisitive, as early identification of issues can prevent serious consequences; and be careful with wording. The code of conduct specifies how breaches can be reported to a code of conduct committee and outlines procedures for the committee’s response. Our diversity statement “welcomes and encourages participation by everyone.”

Maintainersterm and contributors The SciPyterm project has ~100 unique contributors for every 6-month release cycle. Anyone with the interest and skills can become a contributor; the SciPyterm contributor guide ( https://scipyterm.github.io/devdocs/dev/contributor/contributor_toc.html ) provides guidance on how to do that. In addition, the project currently has 15 active (volunteer) maintainersterm: people who review the contributions of others and do everything else needed to ensure that the software and the project move forward. Maintainersterm are critical to the health of the project 93 ; their skills and efforts largely determine how fast the project progresses, and they enable input from the much larger group of contributors. Anyone can become a maintainerterm, too, as they are selected on a rolling basis from contributors with a substantial history of high-quality contributions.

Funding The development cost of SciPyterm is estimated in excess of 10 million dollars by Open Hub ( https://www.openhub.net/p/scipyterm/estimated_cost ). Yet the project is largely unfunded, having been developed predominantly by graduate students, faculty and members of industry in their free time. Small amounts of funding have been applied with success: some meetings were sponsored by universities and industry, Google’s Summer of Code program supported infrastructure and algorithmterm·mth work, and teaching grant funds were used early on to develop documentation. However, funding from national agencies, foundations and industry has not been commensurate with the enormous stack of important software that relies on SciPyterm. MorepersName diverse spending to support planning, development, management and infrastructure would help SciPyterm remain a healthy underpinning of international scientific and industrial endeavors.

Downstream projects The scientific Python ecosystem includes many examples of domain-specific software libraries building on top of SciPyterm features and then returning to the base SciPy libraryterm to suggest and even implement improvements. For example, there are common contributors to the SciPyterm and Astropy core libraries 94 , and what works well for one of the codebases, infrastructures or communities is often transferred in some form to the other. At the codebase level, the binned_statistic functionality is one such cross-project contribution: it was initially developed in an Astropy-affiliated package and then placed in SciPyterm afterward. In this perspective, SciPyterm serves as a catalyst for cross-fertilization throughout the Python scientific computing community.

Discussion SciPyterm has a strong developer community and a massive user base. GitHub traffic metrics report roughly 20,000 unique visitors to the source website between 14 May 2018 and 27 May 2018 (near the time of writing), with 721 unique copies (‘clones’) of the codebase over that time period. The developer community at that time consisted of 610 unique contributors of source code, with morepersName than 19,000 commits accepted into the codebase (GitHub page data).

From the user side, there were 13,096,468 downloads of SciPyterm from the Python Packaging Index (PyPI) 95 and 5,776,017 via the default channel of the conda ( https://github.com/ContinuumIO/anaconda-package-data ) package manager during the year 2017. These numbers establish a lower bound on the total number of downloads by users given that PyPI and conda are only two of several popular methods for installing SciPyterm. The SciPyterm website ( http://www.scipyterm.org/ ), which has been the default citation in the absence of a peer-reviewed paper, has been cited over 3,000 times ( https://scholar.google.com/scholar?cites=2086009121748039507 ). Some of the most prominent uses of or demonstrations of credibility for SciPyterm include the LIGO-Virgo scientific collaboration that lead to the observation of gravitational waves 96 , the fact that SciPyterm is shipped directly with macOS and in the Intel distribution for Python 97 , and that SciPyterm is used by 47% of all machine learning projects on GitHub ( https://github.blog/2019-01-24-the-state-of-the-octoverse-machine-learning/ ).

Nevertheless, SciPyterm continually strives to improve. The SciPyterm Roadmap ( https://docs.scipyterm.org/doc/scipy-1.0.0/reference/roadmap.html , https://scipyterm.github.io/devdocs/roadmap.html ), summarized in Table 2 , is a continually updated document maintained by the community that describes some of the major directions for improvement for the project, as well as specific limitations and matters that require assistance moving forward. In addition to the items on the roadmap, we are still working to increase the number of SciPyterm usage tutorials beyond our current 15 section offering. Also, the low-level Cython code in our library (which interacts with C-level code and exposes it for Python usage) could use some measure of modernization, including migration to typed memoryviews to handle NumPyterm arrays. Table 2 Summary of SciPyterm Roadmap items following 1.0 release SciPyterm subpackageterm Summary of change optimize A few morepersName high-quality global optimizers fftpack Reduce overlap with NumPyterm equivalent linalg Reduce overlap with NumPyterm equivalent interpolate New spline fitting and arithmetic routines interpolate New transparent tensor-product splines interpolate New non-uniform rational B-splines interpolate Mesh refinement and coarsening of B-splines and tensor products signal Migrate spline functionality to interpolate signal Second order sections update to match capabilities in other routines linalg Support a morepersName recent version of LAPACK ndimage Clarify usage of the ‘data point’ coordinate model, and add additional wrapping modes sparseterm Incorporate sparseterm arrays from Sparseterm package 118 sparseterm.linalg Add PROPACK wrappers for faster SVD spatialterm Add support for (quaternion) rotation matrices special Precision improvements for hypergeometric, parabolic cylinder and spheroidal wave functions A problem faced by many open-source projects is attracting and retaining developers. Although it is normal for some individuals to contribute to a project for a while and then move on, too much turnoverterm can result in the loss of institutional memoryterm, leading to mistakes of the past being repeated, APIs of new code becoming inconsistent with the old code and a drifting project scope. We are fortunate that the SciPyterm project continues to attract enthusiastic and competent new developers while maintaining the involvement of a small but dedicated old guard. There are contributors who were present in the early years of the project who still contribute to discussions of bug reports and reviews of new code contributions. Our benevolent dictator for life has been with the project for morepersName than 10 years and is still actively contributing code, and the head of our steering councilterm, who also acts as a general manager, is approaching his eleventh anniversary. An additional half dozen or so active developers have been contributing steadily for five or morepersName years. The combination of a committed old guard and a host of new contributors ensures that SciPyterm will continue to grow while maintaining a high level of quality.

A final important challenge to address is the accommodation of GPU and distributed computingterm·mth without disrupting our conventional and heavily used algorithmterm·mth/API infrastructure. Although the exact approach we will adopt across the entire library to leverage these emerging technologies remains unclear, and was not a priority at the 1.0 release point, we now have a concrete implementation of a subpackageterm that allows for the experimental use of multiple backends, such as GPU-tractable data structuresterm, in the new scipyterm.fft. This will be described in detail in a future report.

Reporting Summary Further information on research design is available in the Nature Research Reporting Summary linked to this article.

Supplementary information Reporting Summary