使用 NumPy 进行数组编程

导读

这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。文章也回顾其设计、生态影响和作为科研基础设施的地位。

HN 关注点：以 Nature 论文形式为 NumPy 这类基础设施软件带来学术认可，并由此讨论软件引用、历史先驱和 Python/Julia 的性能取舍。

关键词　NumPyarray programmingscientific computingPython

后来怎么样

NumPy 已成为 Python 科学计算的事实标准数组库，被数据科学、机器学习和几乎所有科学计算生态广泛依赖；这篇 Nature 文章也推动了开源基础设施工作获得学术认可。

HN 评论精选

这几条评论里：支持 1　质疑 1　补充 2

支持Nature 论文能为 NumPy 这类基础设施工作带来学术认可、经费和终身教职价值。

不要低估这件事对 NumPy 获得经费、甚至终身教职等认可的影响。我现在在工业界，但从学术界出来的我知道，因构建大量人使用的基础设施而获得认可真的很难。我开发并维护过很多被大量论文使用的库，却总被告知我的工作是“完全没用”。这些工作也一直无法发表，因为在我领域方法类工作永远发不了。NumPy 显然比我的工作影响大得多，但普遍问题仍在。正因为如此，这类文章是件大事，是对很多人十多年工作的一次巨大而迟来的认可。

jofer查看英文原文

Don't underestimate the impact this has on getting funding or even just tenure/etc recognition for working on numpy. I'm in industry these days, but coming from the academic side, it's _really_ hard to get recognized for building the underlying infrastructure that tons of people use. I've built and maintained libraries that are used in a ton of publications, but was always told my work was "utterly and completely useless". It was also always unpublishable, as methods are never publishable in my field. Numpy has (obviously) vastly more respect and impact than my work, but the general problem remains. Articles like this are a _huge_ deal for that reason. It's an immense delayed recognition for over a decade of work from a lot of folks.

补充补充 NumPy/SciPy 的软件引用规范，并讨论更结构化的软件引用方式。

看来 NumPy 有了新的引用文献。“Citing packages in the SciPy ecosystem”列出了 SciPy、NumPy、scikits 和其他 -Py 项目的现有引用方式。更好的引用必需软件的方式，可能是在 JSON-LD、RDFa 或 Microdata 中引用 schema.org/SoftwareApplication 记录；但截至目前，还没有办法从 LaTeX 用 Computer Modern 发布 JSON-LD、RDFa 或 Microdata 链接数据。

westurner查看英文原文

Looks like there's a new citation for NumPy in town. "Citing packages in the SciPy ecosystem" lists the existing citations for SciPy, NumPy, scikits, and other -Py things: https://www.scipy.org/citing.html ( source: https://github.com/scipy/scipy.org/blob/master/www/citing.rst ) A better way to cite requisite software might involve referencing a https://schema.org/SoftwareApplication record in JSON-LD, RDFa, or Microdata; for example: https://news.ycombinator.com/item?id=24489651 But there's as of yet no way to publish JSON-LD, RDFa, or Microdata Linked Data from LaTeX with Computer Modern.

质疑批评 NumPy/Python 科学计算 API 复杂且性能依赖 C，认为 Julia 更优。

人人都用 NumPy，但不是因为想用或 API 本身价值巨大，而是除非每个操作都调用 C，Python 做科学计算太慢。因此 NumPy 必须更大、更不正交，提供大量函数确保用户永远不必落回普通 Python 而承受 100 倍性能损失。这很不幸，也阻止 NumPy 拥有 APL、J、kdb+/q 那种真正数组语言的美感和正交性。这个问题让新的 Python 科学用户难以写出快速代码：一切都可以很快，然后你加一个 if 语句，性能就断崖式下降。我在不同实验室帮过很多人，这是研究者反复遇到的问题。所以 Python 对科学计算所谓易用性是谎言。API 极其复杂，从 NumPy 到 Pandas 到 statsmodels 和 scikit，而且必须如此，因为科学 Python 因性能原因无法组合代码。相比之下，Julia 更易学易用，在科学应用中几乎各方面都比 Python 更好，严格来说更优：性能始终快，数组操作内建于核心语言，不像 Python。你可以自由写 Julia 而不用调用 C。

smabie查看英文原文

Everyone uses numpy, but not because they want to or the API itself provides some massive value. They use it because unless you're calling into C for literally every operation, Python is far too slow to get any scientific computing work done. And because of this, numpy has to be much larger and less orthogonal. It needs to provide a wide range of functions that ensure that the user will never have to drop into regular Python and suffer a 100x performance hit. This is unfortunate, and prevents numpy by having the beauty and orthogonality of true array languages like apl, j, or kdb+/q. This problem makes it difficult for new scientific users of Python to write fast code. Everything can be fast and then you add one if statement and the performance falls off a cliff. I've helped many people in various labs as this is a recurring problem that researchers face. As such, the ease of use that Python supposedly has for scientific computing is a lie. The APIs are extremely complex, from numpy to Pandas to statsmodel and scikit. And they have to be, because scientific Python can't compose code due to performance reasons. In contrast, Julia is much easier to learn, easier to use, and is pretty much better than Python for scientific applications in every way imaginable. In other words, it is strictly superior. The performance is consistently fast and array manipulation is built into the core language, unlike with Python. You are free to write Julia code instead of shelling out to C. I'll probably get down voted, but Python should not be used for new scientific computing projects. I've had tons of experience with ml/financial Python and after trying Julia, I'll never go back willingly. The difference in speed, complexity, ergonomics, and expressivity is so stark it's hard to imagine why anyone would choose Python for a greenfield scientific computing project in 2020, especially since Julia can trivially access all of Python's ecosystem.

补充PDL 早于 NumPy 十年开创了许多数组编程理念，值得被记住。

别忘了至少给 Perl Data Language（PDL）一些功劳。它在 NumPy 出现十年前就开创了许多这些理念，今天仍是相当好用的工具。

hoytech查看英文原文

Let's not forget to give at least some credit to Perl Data Langauge (PDL). It pioneered a lot of these ideas 10 years before NumPy existed, and is still a pretty great tool today: http://pdl.perl.org/index.php?page=FirstSteps

历次讨论

2020Hacker News 讨论帖28 分 · 23 评
2020Hacker News 讨论帖290 分 · 111 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

使用 NumPy 进行数组编程

导读

后来怎么样

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

将 C 编译为安全 Rust：形式化方法

打赏支持

关注向阳乔木