<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:lang="en">
  <teiHeader>
    <fileDesc>
      <titleStmt>
        <title>Array programming with NumPy</title>
        <author>Charles R. Harris</author>
        <author>K. Jarrod Millman</author>
        <author>Stéfan J. van der Walt</author>
        <author>Ralf Gommers</author>
        <author>Pauli Virtanen</author>
        <author>David Cournapeau</author>
        <author>Eric Wieser</author>
        <author>Julian Taylor</author>
        <author>Sebastian Berg</author>
        <author>Nathaniel J. Smith</author>
        <author>Robert Kern</author>
        <author>Matti Picus</author>
        <author>Stephan Hoyer</author>
        <author>Marten H. van Kerkwijk</author>
        <author>Matthew Brett</author>
        <author>Allan Haldane</author>
        <author>Jaime Fernández del Río</author>
        <author>Mark Wiebe</author>
        <author>Pearu Peterson</author>
        <author>Pierre Gérard-Marchant</author>
        <author>Kevin Sheppard</author>
        <author>Tyler Reddy</author>
        <author>Warren Weckesser</author>
        <author>Hameer Abbasi</author>
        <author>Christoph Gohlke</author>
        <author>Travis E. Oliphant</author>
      </titleStmt>
      <publicationStmt>
        <p>Tag layer of the DHSS Meta-Tagging Project. The article text is reproduced from the
           staged copy named in sourceDesc and is not altered; the tags are held separately in
           standOff so that overlapping and nested spans are preserved.</p>
      </publicationStmt>
      <sourceDesc>
        <bibl>
          <title>Array programming with NumPy</title>
          <date>2020</date>
          <publisher>Nature</publisher>
          <idno type="DOI">10.1038/s41586-020-2649-2</idno>
          
          <idno type="record">harris2020-array-programming-numpy</idno>
          <note type="staged-file">harris2020-array-programming-numpy.txt, the project's staged copy</note>
          <note type="text-sha1">afbc50968e4c83ec172f82e4d67122912fcd8e8d</note>
          <note type="rights">cc-by</note>
        </bibl>
      </sourceDesc>
    </fileDesc>
    <profileDesc>
      <textClass><keywords><term>computer-science</term></keywords></textClass>
      <particDesc>
        <person xml:id="paper"><p>the paper's own words</p></person>
        <person xml:id="tagger"><p>the tag layer; a sentence written by the tagger about the
          paper, always anchored to a quotation but not itself a quotation</p></person>
      </particDesc>
    </profileDesc>
    <revisionDesc>
      <change when="2026-10-06"
              who="build_paper_edition.py">172 spans located by searching the stored text for the quote's exact words, allowing any whitespace between them</change>
    </revisionDesc>
  </teiHeader>
  <standOff>
    <spanGrp type="tags">
      <span xml:id="t0" from="#a1" to="#a2" type="object_of_study" ana="#object_of_study" resp="#paper">NumPy&#x27;s array concepts, scientific-Python role, interoperability protocols, development model, and future constraints</span>
      <span xml:id="t1" from="#a45" to="#a46" type="research_question" ana="#research_question" resp="#paper">how fundamental array concepts and a shared API organize scientific computation while allowing specialized array implementations to interoperate</span>
      <span xml:id="t2" from="#a1" to="#a2" type="contribution" ana="#contribution" resp="#paper">a review of NumPy&#x27;s array-programming model, ecosystem position, and transition into the standard coordinating API for Python array technologies</span>
      <span xml:id="t3" from="#a1" to="#a2" type="claim_type" ana="#claim_type" resp="#paper">existence</span>
      <span xml:id="t4" from="#a1" to="#a2" type="phenomenon" ana="#phenomenon" resp="#paper">array programming and interoperable scientific computation in Python</span>
      <span xml:id="t5" from="#a15" to="#a16" type="method" ana="#method" resp="#paper">system-or-tool-building<term>system-or-tool-building</term></span>
      <span xml:id="t6" from="#a7" to="#a8" type="mechanisms" ana="#mechanisms[0]" resp="#tagger" cert="0.95">A memory pointer stores the data while type, shape, and strides determine its interpretation.<term>memory pointer and metadata</term></span>
      <span xml:id="t7" from="#a13" to="#a14" type="mechanisms" ana="#mechanisms[1]" resp="#tagger" cert="0.95">Byte-step metadata maps linear computer memory onto multidimensional rows and columns.<term>strides</term></span>
      <span xml:id="t8" from="#a17" to="#a18" type="mechanisms" ana="#mechanisms[2]" resp="#tagger" cert="0.95">Subarray indexing shares data with the original array to constrain memory use.<term>views</term></span>
      <span xml:id="t9" from="#a19" to="#a20" type="mechanisms" ana="#mechanisms[3]" resp="#tagger" cert="0.95">Whole-array expressions delegate element loops and cache-aware execution to NumPy.<term>vectorization</term></span>
      <span xml:id="t10" from="#a21" to="#a22" type="mechanisms" ana="#mechanisms[4]" resp="#tagger" cert="0.95">Operands are virtually duplicated until their shapes agree, without copying data.<term>broadcasting</term></span>
      <span xml:id="t11" from="#a23" to="#a24" type="mechanisms" ana="#mechanisms[5]" resp="#tagger" cert="0.95">Element-wise operations aggregate across selected axes and lower dimensionality.<term>reductions</term></span>
      <span xml:id="t12" from="#a25" to="#a26" type="mechanisms" ana="#mechanisms[6]" resp="#tagger" cert="0.95">OpenBLAS or Intel MKL executes accelerated routines for the available CPU.<term>optimized linear-algebra backends</term></span>
      <span xml:id="t13" from="#a47" to="#a48" type="mechanisms" ana="#mechanisms[7]" resp="#tagger" cert="0.95">NumPy accepts specialized arrays and dispatches each operation to the originating library.<term>array protocols</term></span>
      <span xml:id="t14" from="#a47" to="#a48" type="mechanisms" ana="#mechanisms[8]" resp="#tagger" cert="0.95">CuPy arrays embedded in Dask arrays combine GPU and distributed execution.<term>protocol composition</term></span>
      <span xml:id="t15" from="#a35" to="#a36" type="mechanisms" ana="#mechanisms[9]" resp="#tagger" cert="0.95">Every proposed change runs through an extensive automated test battery.<term>continuous testing</term></span>
      <span xml:id="t16" from="#a39" to="#a40" type="limitations" ana="#limitations[0]" resp="#tagger" cert="0.95">NumPy&#x27;s in-memory data model cannot directly use distributed storage, GPUs, TPUs, or FPGAs.</span>
      <span xml:id="t17" from="#a39" to="#a40" type="limitations" ana="#limitations[1]" resp="#tagger" cert="0.95">Scientific datasets can exceed a single machine&#x27;s memory and reside across machines or in the cloud.</span>
      <span xml:id="t18" from="#a43" to="#a44" type="limitations" ana="#limitations[2]" resp="#tagger" cert="0.95">Trying a new array library can require import changes and verification that the needed NumPy API is implemented.</span>
      <span xml:id="t19" from="#a43" to="#a44" type="limitations" ana="#limitations[3]" resp="#tagger" cert="0.95">Promising specialized array libraries can cease development.</span>
      <span xml:id="t20" from="#a51" to="#a52" type="limitations" ana="#limitations[4]" resp="#tagger" cert="0.95">NumPy still depends heavily on free-time contributions by graduate students and researchers.</span>
      <span xml:id="t21" from="#a55" to="#a56" type="limitations" ana="#limitations[5]" resp="#tagger" cert="0.95">New hardware, languages, interpreters, compilers, and expanding data scale will challenge current interfaces.</span>
      <span xml:id="t22" from="#a57" to="#a58" type="limitations" ana="#limitations[6]" resp="#tagger" cert="0.95">Continuing NumPy&#x27;s leading role requires sustained government, academic, and industry funding.</span>
      <span xml:id="t23" from="#a57" to="#a58" type="limitations" ana="#limitations[7]" resp="#tagger" cert="0.95">Meeting the next decade&#x27;s needs also requires a new generation of graduate students and community contributors.</span>
      <span xml:id="t24" from="#a35" to="#a36" type="controls" ana="#controls[0]" resp="#tagger" cert="0.95">extensive automated test battery<note>eliminates: regressions introduced by proposed NumPy changes · outcome: held</note></span>
      <span xml:id="t25" from="#a35" to="#a36" type="controls" ana="#controls[1]" resp="#tagger" cert="0.95">distributed revision control and code review<note>eliminates: unreviewed or poorly coordinated project changes · outcome: held</note></span>
      <span xml:id="t26" from="#a1" to="#a2" type="concepts" ana="#concepts[0]" resp="#paper" cert="0.95">Array programming<term>Array programming</term></span>
      <span xml:id="t27" from="#a1" to="#a2" type="concepts" ana="#concepts[1]" resp="#paper" cert="0.95">NumPy<term>NumPy</term></span>
      <span xml:id="t28" from="#a1" to="#a2" type="concepts" ana="#concepts[2]" resp="#paper" cert="0.95">scientific Python ecosystem<term>scientific Python ecosystem</term></span>
      <span xml:id="t29" from="#a1" to="#a2" type="concepts" ana="#concepts[3]" resp="#paper" cert="0.95">interoperability layer<term>interoperability layer</term></span>
      <span xml:id="t30" from="#a1" to="#a2" type="concepts" ana="#concepts[4]" resp="#paper" cert="0.95">application programming interface<term>application programming interface</term></span>
      <span xml:id="t31" from="#a1" to="#a2" type="concepts" ana="#concepts[5]" resp="#paper" cert="0.95">API<term>API</term></span>
      <span xml:id="t32" from="#a3" to="#a4" type="concepts" ana="#concepts[6]" resp="#paper" cert="0.95">Numeric<term>Numeric</term></span>
      <span xml:id="t33" from="#a3" to="#a4" type="concepts" ana="#concepts[7]" resp="#paper" cert="0.95">Numarray<term>Numarray</term></span>
      <span xml:id="t34" from="#a3" to="#a4" type="concepts" ana="#concepts[8]" resp="#paper" cert="0.95">best of both worlds<term>best of both worlds</term></span>
      <span xml:id="t35" from="#a7" to="#a8" type="concepts" ana="#concepts[9]" resp="#paper" cert="0.95">NumPy array<term>NumPy array</term></span>
      <span xml:id="t36" from="#a7" to="#a8" type="concepts" ana="#concepts[10]" resp="#paper" cert="0.95">data structure<term>data structure</term></span>
      <span xml:id="t37" from="#a7" to="#a8" type="concepts" ana="#concepts[11]" resp="#paper" cert="0.95">multidimensional arrays<term>multidimensional arrays</term></span>
      <span xml:id="t38" from="#a7" to="#a8" type="concepts" ana="#concepts[12]" resp="#paper" cert="0.95">tensors<term>tensors</term></span>
      <span xml:id="t39" from="#a7" to="#a8" type="concepts" ana="#concepts[13]" resp="#paper" cert="0.95">pointer to memory<term>pointer to memory</term></span>
      <span xml:id="t40" from="#a7" to="#a8" type="concepts" ana="#concepts[14]" resp="#paper" cert="0.95">metadata<term>metadata</term></span>
      <span xml:id="t41" from="#a9" to="#a10" type="concepts" ana="#concepts[15]" resp="#paper" cert="0.95">data type<term>data type</term></span>
      <span xml:id="t42" from="#a11" to="#a12" type="concepts" ana="#concepts[16]" resp="#paper" cert="0.95">shape<term>shape</term></span>
      <span xml:id="t43" from="#a11" to="#a12" type="concepts" ana="#concepts[17]" resp="#paper" cert="0.95">dimensionality<term>dimensionality</term></span>
      <span xml:id="t44" from="#a13" to="#a14" type="concepts" ana="#concepts[18]" resp="#paper" cert="0.95">strides<term>strides</term></span>
      <span xml:id="t45" from="#a13" to="#a14" type="concepts" ana="#concepts[19]" resp="#paper" cert="0.95">C or Fortran memory order<term>C or Fortran memory order</term></span>
      <span xml:id="t46" from="#a15" to="#a16" type="concepts" ana="#concepts[20]" resp="#paper" cert="0.95">indexing<term>indexing</term></span>
      <span xml:id="t47" from="#a15" to="#a16" type="concepts" ana="#concepts[21]" resp="#paper" cert="0.95">operators<term>operators</term></span>
      <span xml:id="t48" from="#a15" to="#a16" type="concepts" ana="#concepts[22]" resp="#paper" cert="0.95">array-aware functions<term>array-aware functions</term></span>
      <span xml:id="t49" from="#a17" to="#a18" type="concepts" ana="#concepts[23]" resp="#paper" cert="0.95">view<term>view</term></span>
      <span xml:id="t50" from="#a19" to="#a20" type="concepts" ana="#concepts[24]" resp="#paper" cert="0.95">vectorization<term>vectorization</term></span>
      <span xml:id="t51" from="#a21" to="#a22" type="concepts" ana="#concepts[25]" resp="#paper" cert="0.95">broadcasting<term>broadcasting</term></span>
      <span xml:id="t52" from="#a23" to="#a24" type="concepts" ana="#concepts[26]" resp="#paper" cert="0.95">reductions<term>reductions</term></span>
      <span xml:id="t53" from="#a25" to="#a26" type="concepts" ana="#concepts[27]" resp="#paper" cert="0.95">pseudorandom numbers<term>pseudorandom numbers</term></span>
      <span xml:id="t54" from="#a25" to="#a26" type="concepts" ana="#concepts[28]" resp="#paper" cert="0.95">OpenBLAS<term>OpenBLAS</term></span>
      <span xml:id="t55" from="#a25" to="#a26" type="concepts" ana="#concepts[29]" resp="#paper" cert="0.95">Intel MKL<term>Intel MKL</term></span>
      <span xml:id="t56" from="#a27" to="#a28" type="concepts" ana="#concepts[30]" resp="#paper" cert="0.95">Python<term>Python</term></span>
      <span xml:id="t57" from="#a31" to="#a32" type="concepts" ana="#concepts[31]" resp="#paper" cert="0.95">SciPy<term>SciPy</term></span>
      <span xml:id="t58" from="#a31" to="#a32" type="concepts" ana="#concepts[32]" resp="#paper" cert="0.95">Matplotlib<term>Matplotlib</term></span>
      <span xml:id="t59" from="#a31" to="#a32" type="concepts" ana="#concepts[33]" resp="#paper" cert="0.95">IPython<term>IPython</term></span>
      <span xml:id="t60" from="#a31" to="#a32" type="concepts" ana="#concepts[34]" resp="#paper" cert="0.95">Jupyter<term>Jupyter</term></span>
      <span xml:id="t61" from="#a33" to="#a34" type="concepts" ana="#concepts[35]" resp="#paper" cert="0.95">exploratory data analysis<term>exploratory data analysis</term></span>
      <span xml:id="t62" from="#a35" to="#a36" type="concepts" ana="#concepts[36]" resp="#paper" cert="0.95">distributed revision control<term>distributed revision control</term></span>
      <span xml:id="t63" from="#a35" to="#a36" type="concepts" ana="#concepts[37]" resp="#paper" cert="0.95">code review<term>code review</term></span>
      <span xml:id="t64" from="#a35" to="#a36" type="concepts" ana="#concepts[38]" resp="#paper" cert="0.95">continuous testing<term>continuous testing</term></span>
      <span xml:id="t65" from="#a39" to="#a40" type="concepts" ana="#concepts[39]" resp="#paper" cert="0.95">in-memory data model<term>in-memory data model</term></span>
      <span xml:id="t66" from="#a39" to="#a40" type="concepts" ana="#concepts[40]" resp="#paper" cert="0.95">graphics processing units<term>graphics processing units</term></span>
      <span xml:id="t67" from="#a39" to="#a40" type="concepts" ana="#concepts[41]" resp="#paper" cert="0.95">tensor processing units<term>tensor processing units</term></span>
      <span xml:id="t68" from="#a39" to="#a40" type="concepts" ana="#concepts[42]" resp="#paper" cert="0.95">field-programmable gate arrays<term>field-programmable gate arrays</term></span>
      <span xml:id="t69" from="#a41" to="#a42" type="concepts" ana="#concepts[43]" resp="#paper" cert="0.95">PyTorch<term>PyTorch</term></span>
      <span xml:id="t70" from="#a41" to="#a42" type="concepts" ana="#concepts[44]" resp="#paper" cert="0.95">Tensorflow<term>Tensorflow</term></span>
      <span xml:id="t71" from="#a41" to="#a42" type="concepts" ana="#concepts[45]" resp="#paper" cert="0.95">JAX<term>JAX</term></span>
      <span xml:id="t72" from="#a41" to="#a42" type="concepts" ana="#concepts[46]" resp="#paper" cert="0.95">sparse arrays<term>sparse arrays</term></span>
      <span xml:id="t73" from="#a41" to="#a42" type="concepts" ana="#concepts[47]" resp="#paper" cert="0.95">non-zero values<term>non-zero values</term></span>
      <span xml:id="t74" from="#a41" to="#a42" type="concepts" ana="#concepts[48]" resp="#paper" cert="0.95">distributed arrays<term>distributed arrays</term></span>
      <span xml:id="t75" from="#a41" to="#a42" type="concepts" ana="#concepts[49]" resp="#paper" cert="0.95">labelled arrays<term>labelled arrays</term></span>
      <span xml:id="t76" from="#a41" to="#a42" type="concepts" ana="#concepts[50]" resp="#paper" cert="0.95">Dask<term>Dask</term></span>
      <span xml:id="t77" from="#a41" to="#a42" type="concepts" ana="#concepts[51]" resp="#paper" cert="0.95">xarray<term>xarray</term></span>
      <span xml:id="t78" from="#a43" to="#a44" type="concepts" ana="#concepts[52]" resp="#paper" cert="0.95">stable array programming interface<term>stable array programming interface</term></span>
      <span xml:id="t79" from="#a47" to="#a48" type="concepts" ana="#concepts[53]" resp="#paper" cert="0.95">protocols<term>protocols</term></span>
      <span xml:id="t80" from="#a47" to="#a48" type="concepts" ana="#concepts[54]" resp="#paper" cert="0.95">contracts of operation<term>contracts of operation</term></span>
      <span xml:id="t81" from="#a47" to="#a48" type="concepts" ana="#concepts[55]" resp="#paper" cert="0.95">specialized arrays<term>specialized arrays</term></span>
      <span xml:id="t82" from="#a47" to="#a48" type="concepts" ana="#concepts[56]" resp="#paper" cert="0.95">dispatches operations<term>dispatches operations</term></span>
      <span xml:id="t83" from="#a47" to="#a48" type="concepts" ana="#concepts[57]" resp="#paper" cert="0.95">CuPy arrays<term>CuPy arrays</term></span>
      <span xml:id="t84" from="#a53" to="#a54" type="concepts" ana="#concepts[58]" resp="#paper" cert="0.95">standard API for tensor computation<term>standard API for tensor computation</term></span>
      <span xml:id="t85" from="#a53" to="#a54" type="concepts" ana="#concepts[59]" resp="#paper" cert="0.95">central coordinating mechanism<term>central coordinating mechanism</term></span>
      <span xml:id="t86" from="#a49" to="#a50" type="concepts" ana="#concepts[60]" resp="#paper" cert="0.95">core scientific infrastructure<term>core scientific infrastructure</term></span>
      <span xml:id="t87" from="#a51" to="#a52" type="concepts" ana="#concepts[61]" resp="#paper" cert="0.95">formal governance structures<term>formal governance structures</term></span>
      <span xml:id="t88" from="#a57" to="#a58" type="concepts" ana="#concepts[62]" resp="#paper" cert="0.95">sustained funding<term>sustained funding</term></span>
      <span xml:id="t89" from="#a57" to="#a58" type="concepts" ana="#concepts[63]" resp="#paper" cert="0.95">community contributors<term>community contributors</term></span>
      <span xml:id="t90" from="#a1" to="#a2" type="unhoused_relations" ana="#unhoused_relations[0]" resp="#tagger" cert="0.95">NumPy → scientific Python ecosystem<note>NumPy underpins the scientific Python ecosystem.</note></span>
      <span xml:id="t91" from="#a3" to="#a4" type="unhoused_relations" ana="#unhoused_relations[1]" resp="#tagger" cert="0.95">NumPy → best of both worlds<note>NumPy emerged as a best-of-both-worlds unification of Numarray and Numeric.</note></span>
      <span xml:id="t92" from="#a3" to="#a4" type="unhoused_relations" ana="#unhoused_relations[2]" resp="#tagger" cert="0.95">NumPy → Numeric<note>NumPy combines Numeric&#x27;s small-array performance and rich C API.</note></span>
      <span xml:id="t93" from="#a3" to="#a4" type="unhoused_relations" ana="#unhoused_relations[3]" resp="#tagger" cert="0.95">NumPy → Numarray<note>NumPy combines features inherited from Numarray.</note></span>
      <span xml:id="t94" from="#a5" to="#a6" type="unhoused_relations" ana="#unhoused_relations[4]" resp="#tagger" cert="0.95">NumPy → Python library<note>NumPy underpins almost every Python library doing scientific or numerical computation.</note></span>
      <span xml:id="t95" from="#a17" to="#a18" type="unhoused_relations" ana="#unhoused_relations[5]" resp="#tagger" cert="0.95">view → memory usage<note>Views share source data and limit memory usage.</note></span>
      <span xml:id="t96" from="#a19" to="#a20" type="unhoused_relations" ana="#unhoused_relations[6]" resp="#tagger" cert="0.95">vectorization → concise code<note>Vectorization permits concise array expressions while NumPy handles loops.</note></span>
      <span xml:id="t97" from="#a21" to="#a22" type="unhoused_relations" ana="#unhoused_relations[7]" resp="#tagger" cert="0.95">broadcasting → data copies<note>Broadcasting matches operand shapes without copying array data.</note></span>
      <span xml:id="t98" from="#a25" to="#a26" type="unhoused_relations" ana="#unhoused_relations[8]" resp="#tagger" cert="0.95">NumPy → OpenBLAS<note>NumPy uses OpenBLAS as one accelerated linear-algebra backend.</note></span>
      <span xml:id="t99" from="#a25" to="#a26" type="unhoused_relations" ana="#unhoused_relations[9]" resp="#tagger" cert="0.95">NumPy → Intel MKL<note>NumPy uses Intel MKL as one accelerated linear-algebra backend.</note></span>
      <span xml:id="t100" from="#a13" to="#a14" type="unhoused_relations" ana="#unhoused_relations[10]" resp="#tagger" cert="0.95">NumPy array → C or Fortran memory order<note>NumPy arrays can use either C or Fortran memory order.</note></span>
      <span xml:id="t101" from="#a41" to="#a42" type="unhoused_relations" ana="#unhoused_relations[11]" resp="#tagger" cert="0.95">sparse arrays → non-zero values<note>Sparse arrays typically contain few non-zero values and store only those values for efficiency.</note></span>
      <span xml:id="t102" from="#a43" to="#a44" type="unhoused_relations" ana="#unhoused_relations[12]" resp="#tagger" cert="0.95">NumPy API → barrier to entry<note>Mimicking the NumPy API lowers the barrier to entry for specialized libraries.</note></span>
      <span xml:id="t103" from="#a43" to="#a44" type="unhoused_relations" ana="#unhoused_relations[13]" resp="#tagger" cert="0.95">stable array programming interface → disruptive schisms<note>A stable NumPy-like interface prevents disruptive community schisms.</note></span>
      <span xml:id="t104" from="#a47" to="#a48" type="unhoused_relations" ana="#unhoused_relations[14]" resp="#tagger" cert="0.95">protocols → dispatches operations<note>Protocols cause NumPy to dispatch operations to the originating library.</note></span>
      <span xml:id="t105" from="#a47" to="#a48" type="unhoused_relations" ana="#unhoused_relations[15]" resp="#tagger" cert="0.95">protocols → specialized arrays<note>Protocols allow specialized arrays to be passed to NumPy functions.</note></span>
      <span xml:id="t106" from="#a53" to="#a54" type="unhoused_relations" ana="#unhoused_relations[16]" resp="#tagger" cert="0.95">NumPy → standard API for tensor computation<note>NumPy has become the standard API for tensor computation.</note></span>
      <span xml:id="t107" from="#a53" to="#a54" type="unhoused_relations" ana="#unhoused_relations[17]" resp="#tagger" cert="0.95">NumPy → central coordinating mechanism<note>NumPy has become a central coordinating mechanism between Python array technologies.</note></span>
      <span xml:id="t108" from="#a57" to="#a58" type="unhoused_relations" ana="#unhoused_relations[18]" resp="#tagger" cert="0.95">NumPy → community contributors<note>NumPy&#x27;s future depends on a new generation of community contributors.</note></span>
      <span xml:id="t109" from="#a1" to="#a2" type="senses" ana="#senses[0]" resp="#tagger" cert="0.95">array programming as compact operations on vectors, matrices, and higher-dimensional arrays</span>
      <span xml:id="t110" from="#a5" to="#a6" type="senses" ana="#senses[1]" resp="#tagger" cert="0.95">NumPy as both a concrete in-memory array library and the foundation of scientific Python</span>
      <span xml:id="t111" from="#a7" to="#a8" type="senses" ana="#senses[2]" resp="#tagger" cert="0.95">NumPy array as pointer-backed homogeneous data interpreted by type, shape, and strides</span>
      <span xml:id="t112" from="#a17" to="#a18" type="senses" ana="#senses[3]" resp="#tagger" cert="0.95">view as a subarray sharing storage with its source rather than copying it</span>
      <span xml:id="t113" from="#a19" to="#a20" type="senses" ana="#senses[4]" resp="#tagger" cert="0.95">vectorization as whole-array expression with optimized implicit element loops</span>
      <span xml:id="t114" from="#a21" to="#a22" type="senses" ana="#senses[5]" resp="#tagger" cert="0.95">broadcasting as virtual operand expansion without copying memory</span>
      <span xml:id="t115" from="#a23" to="#a24" type="senses" ana="#senses[6]" resp="#tagger" cert="0.95">reduction as aggregation across selected axes that lowers array dimensionality</span>
      <span xml:id="t116" from="#a31" to="#a32" type="senses" ana="#senses[7]" resp="#tagger" cert="0.95">scientific Python ecosystem as layers of foundation, technique-specific, and domain-specific libraries</span>
      <span xml:id="t117" from="#a47" to="#a48" type="senses" ana="#senses[8]" resp="#tagger" cert="0.95">protocol as a contract that hands specialized-array operations back to their own library</span>
      <span xml:id="t118" from="#a53" to="#a54" type="senses" ana="#senses[9]" resp="#tagger" cert="0.95">NumPy as the standard tensor API and coordination layer across Python array technologies</span>
      <span xml:id="t119" from="#a3" to="#a4" type="claim_relations" ana="#claim_relations[0]" resp="#tagger" cert="0.95">builds-on → Numeric<note>note: NumPy retained Numeric&#x27;s small-array performance and rich C API.</note></span>
      <span xml:id="t120" from="#a3" to="#a4" type="claim_relations" ana="#claim_relations[1]" resp="#tagger" cert="0.95">builds-on → Numarray<note>note: NumPy combined Numarray&#x27;s feature set with Numeric&#x27;s strengths.</note></span>
      <span xml:id="t121" from="#a31" to="#a32" type="claim_relations" ana="#claim_relations[2]" resp="#tagger" cert="0.95">complements → SciPy and Matplotlib<note>note: The three libraries jointly form the array-programming foundation.</note></span>
      <span xml:id="t122" from="#a27" to="#a28" type="claim_relations" ana="#claim_relations[3]" resp="#tagger" cert="0.95">extends → Python<note>note: Fast array operations and linear algebra let scientific work remain in Python.</note></span>
      <span xml:id="t123" from="#a3" to="#a4" type="concept_edges" ana="#concept_edges[0]" resp="#tagger" cert="0.95">Numeric —distinct-from→ Numarray<note>the relation itself is separately evidenced · strength of the relation: 0.95 · note: Direct stated difference. · the relation stated: Numeric and Numarray had enough differences to divide the community.</note><term>Numeric</term><term>Numarray</term></span>
      <span xml:id="t124" from="#a7" to="#a8" type="concept_edges" ana="#concept_edges[1]" resp="#tagger" cert="0.95">NumPy array —is-a→ data structure<note>the relation itself is separately evidenced · strength of the relation: 1 · note: Explicit categorical definition. · the relation stated: The NumPy array is a data structure.</note><term>NumPy array</term><term>data structure</term></span>
      <span xml:id="t125" from="#a7" to="#a8" type="concept_edges" ana="#concept_edges[2]" resp="#tagger" cert="0.95">multidimensional arrays —same-as→ tensors<note>the relation itself is separately evidenced · strength of the relation: 1 · note: Explicit naming equivalence. · the relation stated: Multidimensional arrays are also known as tensors.</note><term>multidimensional arrays</term><term>tensors</term></span>
      <span xml:id="t126" from="#a7" to="#a8" type="concept_edges" ana="#concept_edges[3]" resp="#tagger" cert="0.95">pointer to memory —part-of→ NumPy array<note>the relation itself is separately evidenced · strength of the relation: 1 · note: The array explicitly consists of this pointer plus metadata. · the relation stated: A pointer to memory is one component of the NumPy array.</note><term>pointer to memory</term><term>NumPy array</term></span>
      <span xml:id="t127" from="#a7" to="#a8" type="concept_edges" ana="#concept_edges[4]" resp="#tagger" cert="0.95">metadata —part-of→ NumPy array<note>the relation itself is separately evidenced · strength of the relation: 1 · note: The array explicitly consists of a pointer plus metadata. · the relation stated: Metadata interpreting stored data is part of the NumPy array.</note><term>metadata</term><term>NumPy array</term></span>
      <span xml:id="t128" from="#a29" to="#a30" type="concept_edges" ana="#concept_edges[5]" resp="#tagger" cert="0.95">NumPy —distinct-from→ Python<note>the relation itself is separately evidenced · strength of the relation: 0.95 · note: Explicit non-membership and independent policy difference. · the relation stated: NumPy is not part of Python&#x27;s standard library and sets its own release policies.</note><term>NumPy</term><term>Python</term></span>
      <span xml:id="t129" from="#a47" to="#a48" type="concept_edges" ana="#concept_edges[6]" resp="#tagger" cert="0.95">protocols —same-as→ contracts of operation<note>the relation itself is separately evidenced · strength of the relation: 1 · note: Explicit parenthetical equivalence. · the relation stated: Protocols are described parenthetically as contracts of operation.</note><term>protocols</term><term>contracts of operation</term></span>
      <span xml:id="t130" from="#a57" to="#a58" type="concept_edges" ana="#concept_edges[7]" resp="#tagger" cert="0.95">sustained funding —causes→ NumPy<note>direction on the measure: increases · the relation itself is separately evidenced · strength of the relation: 0.9 · note: Necessary-resource claim rather than a measured deterministic effect. · the relation stated: Sustained funding is required for NumPy to continue its leading role.
Audit 2026-09-28: DOUBTFUL - read against its span and kept, but NumPy&#x27;s future REQUIRES sustained funding; causes &#x27;NumPy&#x27; drops the object.</note><term>sustained funding</term><term>NumPy</term></span>
      <span xml:id="t131" from="#a1" to="#a2" type="content_tags" ana="#content_tags.findings[0]" resp="#tagger" cert="0.95">NumPy is the primary array-programming library for Python and a foundation of the scientific-Python ecosystem.</span>
      <span xml:id="t132" from="#a3" to="#a4" type="content_tags" ana="#content_tags.findings[1]" resp="#tagger" cert="0.95">NumPy unified Numarray&#x27;s features with Numeric&#x27;s small-array performance and C API.</span>
      <span xml:id="t133" from="#a5" to="#a6" type="content_tags" ana="#content_tags.findings[2]" resp="#tagger" cert="0.95">The NumPy array has become Python&#x27;s de facto exchange format for array data.</span>
      <span xml:id="t134" from="#a17" to="#a18" type="content_tags" ana="#content_tags.findings[3]" resp="#tagger" cert="0.95">Views share data with their source arrays and therefore limit memory usage.</span>
      <span xml:id="t135" from="#a19" to="#a20" type="content_tags" ana="#content_tags.findings[4]" resp="#tagger" cert="0.95">Vectorization expresses multi-line element loops as concise Python expressions while NumPy performs near-optimal looping.</span>
      <span xml:id="t136" from="#a21" to="#a22" type="content_tags" ana="#content_tags.findings[5]" resp="#tagger" cert="0.95">Broadcasting virtually duplicates operands so differently shaped arrays can participate in one operation without memory copies.</span>
      <span xml:id="t137" from="#a31" to="#a32" type="content_tags" ana="#content_tags.findings[6]" resp="#tagger" cert="0.95">NumPy, SciPy, Matplotlib, and an interactive environment form the foundation of array programming in Python.</span>
      <span xml:id="t138" from="#a35" to="#a36" type="content_tags" ana="#content_tags.findings[7]" resp="#tagger" cert="0.95">Continuous testing, revision control, and code review support collaboration and error reduction.</span>
      <span xml:id="t139" from="#a39" to="#a40" type="content_tags" ana="#content_tags.findings[8]" resp="#tagger" cert="0.95">NumPy&#x27;s in-memory CPU model cannot directly use distributed storage or specialized accelerator hardware.</span>
      <span xml:id="t140" from="#a43" to="#a44" type="content_tags" ana="#content_tags.findings[9]" resp="#tagger" cert="0.95">Specialized libraries often imitate NumPy&#x27;s API to lower adoption barriers and preserve a stable interface.</span>
      <span xml:id="t141" from="#a47" to="#a48" type="content_tags" ana="#content_tags.findings[10]" resp="#tagger" cert="0.95">More than four hundred popular NumPy functions participate in protocol-based dispatch.</span>
      <span xml:id="t142" from="#a47" to="#a48" type="content_tags" ana="#content_tags.findings[11]" resp="#tagger" cert="0.95">Protocol composition permits NumPy code to run at scale on distributed multi-GPU systems with minimal changes.</span>
      <span xml:id="t143" from="#a53" to="#a54" type="content_tags" ana="#content_tags.findings[12]" resp="#tagger" cert="0.95">NumPy has become both the standard tensor-computation API and a coordinating mechanism among Python array technologies.</span>
      <span xml:id="t144" from="#a57" to="#a58" type="content_tags" ana="#content_tags.findings[13]" resp="#tagger" cert="0.95">Future viability requires sustained funding and a new generation of contributors.</span>
      <span xml:id="t145" from="#a1" to="#a2" type="content_tags" ana="#content_tags.definitions[0]" resp="#tagger" cert="0.95">compact array-level syntax for accessing, manipulating, and operating on vectors, matrices, and higher-dimensional arrays<term>array programming</term></span>
      <span xml:id="t146" from="#a7" to="#a8" type="content_tags" ana="#content_tags.definitions[1]" resp="#tagger" cert="0.95">a data structure that stores and accesses multidimensional arrays through a memory pointer plus data-type, shape, and stride metadata<term>NumPy array</term></span>
      <span xml:id="t147" from="#a9" to="#a10" type="content_tags" ana="#content_tags.definitions[2]" resp="#tagger" cert="0.95">metadata describing the nature and fixed byte width of array elements<term>data type</term></span>
      <span xml:id="t148" from="#a11" to="#a12" type="content_tags" ana="#content_tags.definitions[3]" resp="#tagger" cert="0.95">the number of elements on each axis, whose axis count determines dimensionality<term>shape</term></span>
      <span xml:id="t149" from="#a13" to="#a14" type="content_tags" ana="#content_tags.definitions[4]" resp="#tagger" cert="0.95">byte offsets for moving among rows, columns, and other dimensions in linear memory<term>strides</term></span>
      <span xml:id="t150" from="#a17" to="#a18" type="content_tags" ana="#content_tags.definitions[5]" resp="#tagger" cert="0.95">an indexed subarray that shares its source array&#x27;s data<term>view</term></span>
      <span xml:id="t151" from="#a19" to="#a20" type="content_tags" ana="#content_tags.definitions[6]" resp="#tagger" cert="0.95">operating on complete arrays instead of individual elements<term>vectorization</term></span>
      <span xml:id="t152" from="#a21" to="#a22" type="content_tags" ana="#content_tags.definitions[7]" resp="#tagger" cert="0.95">virtual duplication that makes operand shapes match without copying data<term>broadcasting</term></span>
      <span xml:id="t153" from="#a23" to="#a24" type="content_tags" ana="#content_tags.definitions[8]" resp="#tagger" cert="0.95">element-by-element aggregation across one, several, or all array axes<term>reductions</term></span>
      <span xml:id="t154" from="#a41" to="#a42" type="content_tags" ana="#content_tags.definitions[9]" resp="#tagger" cert="0.95">arrays that typically store only their few non-zero values<term>sparse arrays</term></span>
      <span xml:id="t155" from="#a41" to="#a42" type="content_tags" ana="#content_tags.definitions[10]" resp="#tagger" cert="0.95">arrays whose dimensions are referred to by name rather than index<term>labelled arrays</term></span>
      <span xml:id="t156" from="#a47" to="#a48" type="content_tags" ana="#content_tags.definitions[11]" resp="#tagger" cert="0.95">contracts that pass specialized arrays through NumPy functions and dispatch operations to their originating libraries<term>array protocols</term></span>
      <span xml:id="t157" from="#a5" to="#a6" type="content_tags" ana="#content_tags.quantities[0]" resp="#tagger" cert="0.95">15 years — interval between NumPy&#x27;s 2005 emergence and this 2020 review</span>
      <span xml:id="t158" from="#a11" to="#a12" type="content_tags" ana="#content_tags.quantities[1]" resp="#tagger" cert="0.95">one-dimensional — dimensionality of the vector example</span>
      <span xml:id="t159" from="#a11" to="#a12" type="content_tags" ana="#content_tags.quantities[2]" resp="#tagger" cert="0.95">four-dimensional — dimensionality of the colour-video example</span>
      <span xml:id="t160" from="#a13" to="#a14" type="content_tags" ana="#content_tags.quantities[3]" resp="#tagger" cert="0.95">(24, 8) — strides for a 4-by-3 array of eight-byte floating-point values</span>
      <span xml:id="t161" from="#a47" to="#a48" type="content_tags" ana="#content_tags.quantities[4]" resp="#tagger" cert="0.95">over four hundred — popular NumPy functions supported by interoperability protocols</span>
      <span xml:id="t162" from="#a47" to="#a48" type="content_tags" ana="#content_tags.quantities[5]" resp="#tagger" cert="0.95">millions of cores — scale claimed for protocol-composed parallel execution</span>
      <span xml:id="t163" from="#a37" to="#a38" type="content_tags" ana="#content_tags.quantities[6]" resp="#tagger" cert="0.95">hundreds of junior scientists — people given professional software-development experience by Astropy</span>
      <span xml:id="t164" from="#a57" to="#a58" type="content_tags" ana="#content_tags.quantities[7]" resp="#tagger" cert="0.95">next decade — planning horizon for NumPy&#x27;s changing technical landscape</span>
      <span xml:id="t165" from="#a9" to="#a10" type="content_tags" ana="#content_tags.variables[0]" resp="#tagger" cert="0.95">data type<term>data type</term></span>
      <span xml:id="t166" from="#a11" to="#a12" type="content_tags" ana="#content_tags.variables[1]" resp="#tagger" cert="0.95">shape<term>shape</term></span>
      <span xml:id="t167" from="#a13" to="#a14" type="content_tags" ana="#content_tags.variables[2]" resp="#tagger" cert="0.95">strides<term>strides</term></span>
      <span xml:id="t168" from="#a13" to="#a14" type="content_tags" ana="#content_tags.variables[3]" resp="#tagger" cert="0.95">memory order<term>memory order</term></span>
      <span xml:id="t169" from="#a23" to="#a24" type="content_tags" ana="#content_tags.variables[5]" resp="#tagger" cert="0.95">axes<term>axes</term></span>
      <span xml:id="t170" from="#a41" to="#a42" type="content_tags" ana="#content_tags.variables[6]" resp="#tagger" cert="0.95">non-zero values<term>non-zero values</term></span>
      <span xml:id="t171" from="#a39" to="#a40" type="content_tags" ana="#content_tags.variables[7]" resp="#tagger" cert="0.95">specialized hardware<term>specialized hardware</term></span>
    </spanGrp>
  </standOff>
  <text>
    <body>
        <p><anchor xml:id="a0"/> Array programming with NumPy</p>
        <p>Abstract</p>
        <p><anchor xml:id="a1"/>Array programming provides a powerful, compact and expressive syntax for accessing, manipulating and operating on data in vectors, matrices and higher-dimensional arrays. NumPy is the primary array programming library for the Python language. It has an essential role in research analysis pipelines in fields as diverse as physics, chemistry, astronomy, geoscience, biology, psychology, materials science, engineering, finance and economics. For example, in astronomy, NumPy was an important part of the software stack used in the discovery of gravitational waves 1 and in the first imaging of a black hole 2 . Here we review how a few fundamental array concepts lead to a simple and powerful programming paradigm for organizing, exploring and analysing scientific data. NumPy is the foundation upon which the scientific Python ecosystem is constructed. It is so pervasive that several projects, targeting audiences with specialized needs, have developed their own NumPy-like interfaces and array objects. Owing to its central position in the ecosystem, NumPy increasingly acts as an interoperability layer between such array computation libraries and, together with its application programming interface (API), provides a flexible framework to support the next decade of scientific and industrial analysis.<anchor xml:id="a2"/></p>
        <p>Subject terms: Computational neuroscience, Solar physics, Computational science, Computer science, Software</p>
        <p>Main</p>
        <p><anchor xml:id="a3"/>Two Python array packages existed before NumPy. The Numeric package was developed in the mid-1990s and provided array objects and array-aware functions in Python. It was written in C and linked to standard fast implementations of linear algebra 3 , 4 . One of its earliest uses was to steer C++ applications for inertial confinement fusion research at Lawrence Livermore National Laboratory 5 . To handle large astronomical images coming from the Hubble Space Telescope, a reimplementation of Numeric, called Numarray, added support for structured arrays, flexible indexing, memory mapping, byte-order variants, more efficient memory use, flexible IEEE 754-standard error-handling capabilities, and better type-casting rules 6 . Although Numarray was highly compatible with Numeric, the two packages had enough differences that it divided the community; however, in 2005 NumPy emerged as a ‘best of both worlds’ unification 7 —combining the features of Numarray with the small-array performance of Numeric and its rich C API.<anchor xml:id="a4"/></p>
        <p><anchor xml:id="a5"/>Now, 15 years later, NumPy underpins almost every Python library that does scientific or numerical computation 8 – 11 , including SciPy 12 , Matplotlib 13 , pandas 14 , scikit-learn 15 and scikit-image 16 . NumPy is a community-developed, open-source library, which provides a multidimensional Python array object along with array-aware functions that operate on it. Because of its inherent simplicity, the NumPy array is the de facto exchange format for array data in Python.<anchor xml:id="a6"/></p>
        <p>NumPy operates on in-memory arrays using the central processing unit (CPU). To utilize modern, specialized storage and hardware, there has been a recent proliferation of Python array packages. Unlike with the Numarray–Numeric divide, it is now much harder for these new libraries to fracture the user community—given how much work is already built on top of NumPy. However, to provide the community with access to new and exploratory technologies, NumPy is transitioning into a central coordinating mechanism that specifies a well defined array programming API and dispatches it, as appropriate, to specialized array implementations.</p>
        <p>NumPy arrays</p>
        <p><anchor xml:id="a7"/>The NumPy array is a data structure that efficiently stores and accesses multidimensional arrays 17 (also known as tensors), and enables a wide variety of scientific computation. It consists of a pointer to memory, along with metadata used to interpret the data stored there, notably ‘data type’, ‘shape’ and ‘strides’ (Fig. 1a ).<anchor xml:id="a8"/></p>
        <p>The NumPy array incorporates several fundamental array concepts. a , The NumPy array data structure and its associated metadata fields. b , Indexing an array with slices and steps. These operations return a ‘view’ of the original data. c , Indexing an array with masks, scalar coordinates or other arrays, so that it returns a ‘copy’ of the original data. In the bottom example, an array is indexed with other arrays; this broadcasts the indexing arguments before performing the lookup. d , Vectorization efficiently applies operations to groups of elements. e , Broadcasting in the multiplication of two-dimensional arrays. f , Reduction operations act along one or more axes. In this example, an array is summed along select axes to produce a vector, or along two axes consecutively to produce a scalar. g , Example NumPy code, illustrating some of these concepts.</p>
        <p><anchor xml:id="a9"/>The data type describes the nature of elements stored in an array. An array has a single data type, and each element of an array occupies the same number of bytes in memory. Examples of data types include real and complex numbers (of lower and higher precision), strings, timestamps and pointers to Python objects.<anchor xml:id="a10"/></p>
        <p><anchor xml:id="a11"/>The shape of an array determines the number of elements along each axis, and the number of axes is the dimensionality of the array. For example, a vector of numbers can be stored as a one-dimensional array of shape N , whereas colour videos are four-dimensional arrays of shape ( T , M , N , 3).<anchor xml:id="a12"/></p>
        <p><anchor xml:id="a13"/>Strides are necessary to interpret computer memory, which stores elements linearly, as multidimensional arrays. They describe the number of bytes to move forward in memory to jump from row to row, column to column, and so forth. Consider, for example, a two-dimensional array of floating-point numbers with shape (4, 3), where each element occupies 8 bytes in memory. To move between consecutive columns, we need to jump forward 8 bytes in memory, and to access the next row, 3 × 8 = 24 bytes. The strides of that array are therefore (24, 8). NumPy can store arrays in either C or Fortran memory order, iterating first over either rows or columns. This allows external libraries written in those languages to access NumPy array data in memory directly.<anchor xml:id="a14"/></p>
        <p><anchor xml:id="a15"/>Users interact with NumPy arrays using ‘indexing’ (to access subarrays or individual elements), ‘operators’ (for example, +, − and × for vectorized operations and @ for matrix multiplication), as well as ‘array-aware functions’; together, these provide an easily readable, expressive, high-level API for array programming while NumPy deals with the underlying mechanics of making operations fast.<anchor xml:id="a16"/></p>
        <p><anchor xml:id="a17"/>Indexing an array returns single elements, subarrays or elements that satisfy a specific condition (Fig. 1b ). Arrays can even be indexed using other arrays (Fig. 1c ). Wherever possible, indexing that retrieves a subarray returns a ‘view’ on the original array such that data are shared between the two arrays. This provides a powerful way to operate on subsets of array data while limiting memory usage.<anchor xml:id="a18"/></p>
        <p><anchor xml:id="a19"/>To complement the array syntax, NumPy includes functions that perform vectorized calculations on arrays, including arithmetic, statistics and trigonometry (Fig. 1d ). Vectorization—operating on entire arrays rather than their individual elements—is essential to array programming. This means that operations that would take many tens of lines to express in languages such as C can often be implemented as a single, clear Python expression. This results in concise code and frees users to focus on the details of their analysis, while NumPy handles looping over array elements near-optimally—for example, taking strides into consideration to best utilize the computer’s fast cache memory.<anchor xml:id="a20"/></p>
        <p><anchor xml:id="a21"/>When performing a vectorized operation (such as addition) on two arrays with the same shape, it is clear what should happen. Through ‘broadcasting’ NumPy allows the dimensions to differ, and produces results that appeal to intuition. A trivial example is the addition of a scalar value to an array, but broadcasting also generalizes to more complex examples such as scaling each column of an array or generating a grid of coordinates. In broadcasting, one or both arrays are virtually duplicated (that is, without copying any data in memory), so that the shapes of the operands match (Fig. 1d ). Broadcasting is also applied when an array is indexed using arrays of indices (Fig. 1c ).<anchor xml:id="a22"/></p>
        <p><anchor xml:id="a23"/>Other array-aware functions, such as sum, mean and maximum, perform element-by-element ‘reductions’, aggregating results across one, multiple or all axes of a single array. For example, summing an n -dimensional array over d axes results in an array of dimension n − d (Fig. 1f ).<anchor xml:id="a24"/></p>
        <p><anchor xml:id="a25"/>NumPy also includes array-aware functions for creating, reshaping, concatenating and padding arrays; searching, sorting and counting data; and reading and writing files. It provides extensive support for generating pseudorandom numbers, includes an assortment of probability distributions, and performs accelerated linear algebra, using one of several backends such as OpenBLAS 18 , 19 or Intel MKL optimized for the CPUs at hand (see Supplementary Methods for more details).<anchor xml:id="a26"/></p>
        <p>Altogether, the combination of a simple in-memory array representation, a syntax that closely mimics mathematics, and a variety of array-aware utility functions forms a productive and powerfully expressive array programming language.</p>
        <p>Scientific Python ecosystem</p>
        <p><anchor xml:id="a27"/>Python is an open-source, general-purpose interpreted programming language well suited to standard programming tasks such as cleaning data, interacting with web resources and parsing text. Adding fast array operations and linear algebra enables scientists to do all their work within a single programming language—one that has the advantage of being famously easy to learn and teach, as witnessed by its adoption as a primary learning language in many universities.<anchor xml:id="a28"/></p>
        <p><anchor xml:id="a29"/>Even though NumPy is not part of Python’s standard library, it benefits from a good relationship with the Python developers. Over the years, the Python language has added new features and special syntax so that NumPy would have a more succinct and easier-to-read array notation. However, because it is not part of the standard library, NumPy is able to dictate its own release policies and development patterns.<anchor xml:id="a30"/></p>
        <p><anchor xml:id="a31"/>SciPy and Matplotlib are tightly coupled with NumPy in terms of history, development and use. SciPy provides fundamental algorithms for scientific computing, including mathematical, scientific and engineering routines. Matplotlib generates publication-ready figures and visualizations. The combination of NumPy, SciPy and Matplotlib, together with an advanced interactive environment such as IPython 20 or Jupyter 21 , provides a solid foundation for array programming in Python. The scientific Python ecosystem (Fig. 2 ) builds on top of this foundation to provide several, widely used technique-specific libraries 15 , 16 , 22 , that in turn underlie numerous domain-specific projects 23 – 28 . NumPy, at the base of the ecosystem of array-aware libraries, sets documentation standards, provides array testing infrastructure and adds build support for Fortran and other compilers.<anchor xml:id="a32"/></p>
        <p>NumPy is the base of the scientific Python ecosystem. Essential libraries and projects that depend on NumPy’s API gain access to new array implementations that support NumPy’s array protocols (Fig. 3 ).</p>
        <p>Many research groups have designed large, complex scientific libraries that add application-specific functionality to the ecosystem. For example, the eht-imaging library 29 , developed by the Event Horizon Telescope collaboration for radio interferometry imaging, analysis and simulation, relies on many lower-level components of the scientific Python ecosystem. In particular, the EHT collaboration used this library for the first imaging of a black hole. Within eht-imaging, NumPy arrays are used to store and manipulate numerical data at every step in the processing chain: from raw data through calibration and image reconstruction. SciPy supplies tools for general image-processing tasks such as filtering and image alignment, and scikit-image, an image-processing library that extends SciPy, provides higher-level functionality such as edge filters and Hough transforms. The ‘scipy.optimize’ module performs mathematical optimization. NetworkX 22 , a package for complex network analysis, is used to verify image comparison consistency. Astropy 23 , 24 handles standard astronomical file formats and computes time–coordinate transformations. Matplotlib is used to visualize data and to generate the final image of the black hole.</p>
        <p><anchor xml:id="a33"/>The interactive environment created by the array programming foundation and the surrounding ecosystem of tools—inside of IPython or Jupyter—is ideally suited to exploratory data analysis. Users can fluidly inspect, manipulate and visualize their data, and rapidly iterate to refine programming statements. These statements are then stitched together into imperative or functional programs, or notebooks containing both computation and narrative. Scientific computing beyond exploratory work is often done in a text editor or an integrated development environment (IDE) such as Spyder. This rich and productive environment has made Python popular for scientific research.<anchor xml:id="a34"/></p>
        <p><anchor xml:id="a35"/>To complement this facility for exploratory work and rapid prototyping, NumPy has developed a culture of using time-tested software engineering practices to improve collaboration and reduce error 30 . This culture is not only adopted by leaders in the project but also enthusiastically taught to newcomers. The NumPy team was early to adopt distributed revision control and code review to improve collaboration on code, and continuous testing that runs an extensive battery of automated tests for every proposed change to NumPy. The project also has comprehensive, high-quality documentation, integrated with the source code 31 – 33 .<anchor xml:id="a36"/></p>
        <p><anchor xml:id="a37"/>This culture of using best practices for producing reliable scientific software has been adopted by the ecosystem of libraries that build on NumPy. For example, in a recent award given by the Royal Astronomical Society to Astropy, they state: “The Astropy Project has provided hundreds of junior scientists with experience in professional-standard software development practices including use of version control, unit testing, code review and issue tracking procedures. This is a vital skill set for modern researchers that is often missing from formal university education in physics or astronomy” 34 . Community members explicitly work to address this lack of formal education through courses and workshops 35 – 37 .<anchor xml:id="a38"/></p>
        <p>The recent rapid growth of data science, machine learning and artificial intelligence has further and dramatically boosted the scientific use of Python. Examples of its important applications, such as the eht-imaging library, now exist in almost every discipline in the natural and social sciences. These tools have become the primary software environment in many fields. NumPy and its ecosystem are commonly taught in university courses, boot camps and summer schools, and are the focus of community conferences and workshops worldwide. NumPy and its API have become truly ubiquitous.</p>
        <p>Array proliferation and interoperability</p>
        <p>NumPy provides in-memory, multidimensional, homogeneously typed (that is, single-pointer and strided) arrays on CPUs. It runs on machines ranging from embedded devices to the world’s largest supercomputers, with performance approaching that of compiled languages. For most its existence, NumPy addressed the vast majority of array computation use cases.</p>
        <p><anchor xml:id="a39"/>However, scientific datasets now routinely exceed the memory capacity of a single machine and may be stored on multiple machines or in the cloud. In addition, the recent need to accelerate deep-learning and artificial intelligence applications has led to the emergence of specialized accelerator hardware, including graphics processing units (GPUs), tensor processing units (TPUs) and field-programmable gate arrays (FPGAs). Owing to its in-memory data model, NumPy is currently unable to directly utilize such storage and specialized hardware. However, both distributed data and also the parallel execution of GPUs, TPUs and FPGAs map well to the paradigm of array programming: therefore leading to a gap between available modern hardware architectures and the tools necessary to leverage their computational power.<anchor xml:id="a40"/></p>
        <p><anchor xml:id="a41"/>The community’s efforts to fill this gap led to a proliferation of new array implementations. For example, each deep-learning framework created its own arrays; the PyTorch 38 , Tensorflow 39 , Apache MXNet 40 and JAX arrays all have the capability to run on CPUs and GPUs in a distributed fashion, using lazy evaluation to allow for additional performance optimizations. SciPy and PyData/Sparse both provide sparse arrays, which typically contain few non-zero values and store only those in memory for efficiency. In addition, there are projects that build on NumPy arrays as data containers, and extend its capabilities. Distributed arrays are made possible that way by Dask, and labelled arrays—referring to dimensions of an array by name rather than by index for clarity, compare x[:, 1] versus x.loc[:, &#x27;time&#x27;]—by xarray 41 .<anchor xml:id="a42"/></p>
        <p><anchor xml:id="a43"/>Such libraries often mimic the NumPy API, because this lowers the barrier to entry for newcomers and provides the wider community with a stable array programming interface. This, in turn, prevents disruptive schisms such as the divergence between Numeric and Numarray. But exploring new ways of working with arrays is experimental by nature and, in fact, several promising libraries (such as Theano and Caffe) have already ceased development. And each time that a user decides to try a new technology, they must change import statements and ensure that the new library implements all the parts of the NumPy API they currently use.<anchor xml:id="a44"/></p>
        <p><anchor xml:id="a45"/>Ideally, operating on specialized arrays using NumPy functions or semantics would simply work, so that users could write code once, and would then benefit from switching between NumPy arrays, GPU arrays, distributed arrays and so forth as appropriate. To support array operations between external array objects, NumPy therefore added the capability to act as a central coordination mechanism with a well specified API (Fig. 2 ).<anchor xml:id="a46"/></p>
        <p><anchor xml:id="a47"/>To facilitate this interoperability, NumPy provides ‘protocols’ (or contracts of operation), that allow for specialized arrays to be passed to NumPy functions (Fig. 3 ). NumPy, in turn, dispatches operations to the originating library, as required. Over four hundred of the most popular NumPy functions are supported. The protocols are implemented by widely used libraries such as Dask, CuPy, xarray and PyData/Sparse. Thanks to these developments, users can now, for example, scale their computation from a single machine to distributed systems using Dask. The protocols also compose well, allowing users to redeploy NumPy code at scale on distributed, multi-GPU systems via, for instance, CuPy arrays embedded in Dask arrays. Using NumPy’s high-level API, users can leverage highly parallel code execution on multiple systems with millions of cores, all with minimal code changes 42 .<anchor xml:id="a48"/></p>
        <p>NumPy’s API and array protocols expose new arrays to the ecosystem. In this example, NumPy’s ‘mean’ function is called on a Dask array. The call succeeds by dispatching to the appropriate library implementation (in this case, Dask) and results in a new Dask array. Compare this code to the example code in Fig. 1g .</p>
        <p>These array protocols are now a key feature of NumPy, and are expected to only increase in importance. The NumPy developers—many of whom are authors of this Review—iteratively refine and add protocol designs to improve utility and simplify adoption.</p>
        <p>Discussion</p>
        <p>NumPy combines the expressive power of array programming, the performance of C, and the readability, usability and versatility of Python in a mature, well tested, well documented and community-developed library. Libraries in the scientific Python ecosystem provide fast implementations of most important algorithms. Where extreme optimization is warranted, compiled languages can be used, such as Cython 43 , Numba 44 and Pythran 45 ; these languages extend Python and transparently accelerate bottlenecks. Owing to NumPy’s simple memory model, it is easy to write low-level, hand-optimized code, usually in C or Fortran, to manipulate NumPy arrays and pass them back to Python. Furthermore, using array protocols, it is possible to utilize the full spectrum of specialized hardware acceleration with minimal changes to existing code.</p>
        <p>NumPy was initially developed by students, faculty and researchers to provide an advanced, open-source array programming library for Python, which was free to use and unencumbered by license servers and software protection dongles. There was a sense of building something consequential together for the benefit of many others. Participating in such an endeavour, within a welcoming community of like-minded individuals, held a powerful attraction for many early contributors.</p>
        <p>These user–developers frequently had to write code from scratch to solve their own or their colleagues’ problems—often in low-level languages that preceded Python, such as Fortran 46 and C. To them, the advantages of an interactive, high-level array library were evident. The design of this new tool was informed by other powerful interactive programming languages for scientific computing such as Basis 47 – 50 , Yorick 51 , R 52 and APL 53 , as well as commercial languages and environments such as IDL (Interactive Data Language) and MATLAB.</p>
        <p><anchor xml:id="a49"/>What began as an attempt to add an array object to Python became the foundation of a vibrant ecosystem of tools. Now, a large amount of scientific work depends on NumPy being correct, fast and stable. It is no longer a small community project, but core scientific infrastructure.<anchor xml:id="a50"/></p>
        <p><anchor xml:id="a51"/>The developer culture has matured: although initial development was highly informal, NumPy now has a roadmap and a process for proposing and discussing large changes. The project has formal governance structures and is fiscally sponsored by NumFOCUS, a nonprofit that promotes open practices in research, data and scientific computing. Over the past few years, the project attracted its first funded development, sponsored by the Moore and Sloan Foundations, and received an award as part of the Chan Zuckerberg Initiative’s Essentials of Open Source Software programme. With this funding, the project was (and is) able to have sustained focus over multiple months to implement substantial new features and improvements. That said, the development of NumPy still depends heavily on contributions made by graduate students and researchers in their free time (see Supplementary Methods for more details).<anchor xml:id="a52"/></p>
        <p><anchor xml:id="a53"/>NumPy is no longer merely the foundational array library underlying the scientific Python ecosystem, but it has become the standard API for tensor computation and a central coordinating mechanism between array types and technologies in Python. Work continues to expand on and improve these interoperability features.<anchor xml:id="a54"/></p>
        <p><anchor xml:id="a55"/>Over the next decade, NumPy developers will face several challenges. New devices will be developed, and existing specialized hardware will evolve to meet diminishing returns on Moore’s law. There will be more, and a wider variety of, data science practitioners, a large proportion of whom will use NumPy. The scale of scientific data gathering will continue to increase, with the adoption of devices and instruments such as light-sheet microscopes and the Large Synoptic Survey Telescope (LSST) 54 . New generation languages, interpreters and compilers, such as Rust 55 , Julia 56 and LLVM 57 , will create new concepts and data structures, and determine their viability.<anchor xml:id="a56"/></p>
        <p><anchor xml:id="a57"/>Through the mechanisms described in this Review, NumPy is poised to embrace such a changing landscape, and to continue playing a leading part in interactive scientific computation, although to do so will require sustained funding from government, academia and industry. But, importantly, for NumPy to meet the needs of the next decade of data science, it will also need a new generation of graduate students and community contributors to drive it forward.<anchor xml:id="a58"/></p>
        <p>Supplementary information</p>
        <p>This file contains Supplementary Methods, including Supplementary Figure 1 and additional references.</p>
        <p>Acknowledgements</p>
        <p>We thank R. Barnowski, P. Dubois, M. Eickenberg, and P. Greenfield, who suggested text and provided helpful feedback on the manuscript. K.J.M. and S.J.v.d.W. were funded in part by the Gordon and Betty Moore Foundation through grant GBMF3834 and by the Alfred P. Sloan Foundation through grant 2013-10-27 to the University of California, Berkeley. S.J.v.d.W., S.B., M.P. and W.W. were funded in part by the Gordon and Betty Moore Foundation through grant GBMF5447 and by the Alfred P. Sloan Foundation through grant G-2017-9960 to the University of California, Berkeley.</p>
        <p>Author contributions</p>
        <p>K.J.M. and S.J.v.d.W. composed the manuscript with input from others. S.B., R.G., K.S., W.W., M.B. and T.R. contributed text. All authors contributed substantial code, documentation and/or expertise to the NumPy project. All authors reviewed the manuscript.</p>
        <p>Competing interests</p>
        <p>The authors declare no competing interests.</p>
        <p>Footnotes</p>
        <p>Contributor Information</p>
        <p>K. Jarrod Millman, Email: millman@berkeley.edu.</p>
        <p>Stéfan J. van der Walt, Email: stefanv@berkeley.edu</p>
        <p>Ralf Gommers, Email: ralf.gommers@gmail.com.</p>
        <p>Supplementary information</p>
        <p>is available for this paper at 10.1038/s41586-020-2649-2.</p>
        <p>References</p>
        <p>Associated Data</p>
        <p>Supplementary Materials</p>
        <p>This file contains Supplementary Methods, including Supplementary Figure 1 and additional references.<anchor xml:id="a59"/></p>
    </body>
  </text>
</TEI>
