NEP 3 — 清理 numpy.core 的数学配置#

作者

大卫·库纳波

接触

大卫@ar媒体京都-u .交流 J.P

日期

2008-09-04

地位

延期

执行摘要

在构建 numpy.core 之前,我们使用一些配置测试来收集有关可用数学函数的一些信息。多年来,配置变得复杂,以至于很难轻松支持新平台。

该提案的目标是清理数学功能的配置,以便于维护。

目前的问题#

目前,数学配置主要测试一些数学函数,并相应地配置numpy。但当前系统不是独立测试每个所需的功能,而是更多地使用平台隐式知识来解决特定平台的奇怪问题。这违背了仅测试功能的正常理念,即 autoconf 理念,它展示了可移植性的路径(至少在 Unix 上)[1] 这会导致问题,因为在现有平台上修改或添加配置会破坏隐含的假设,而无需澄清的解决方案。

例如,在 Windows 上,当使用 mingw 构建 numpy 时,最好强制执行配置 sizeof(long double) == sizeof(double),因为 mingw 使用 MS 运行时,而 MS 运行时不支持 long double。不幸的是,这样做会破坏 mingw 数学函数检测,因为隐含假设 mingw 具有配置 sizeof(long double) != sizeof(double)。

另一个例子是仅使用一个函数测试一组函数:如果找到 expf,则假设所有基本浮点函数都可用。相反,每个函数都应该独立测试(expf、sinf 等)。

要求

我们有两个强烈的要求:
  • 它不应该破坏任何当前支持的平台

  • 它不应该使配置变慢(1-2秒是可以接受的)

提议

我们建议打破任何隐含的假设,并独立地测试每个数学函数,就像 autoconf 通常所做的那样。由于测试大量函数可能非常耗时,因此我们将使用类似于 autoconf 中的 AC_CHECK_FUNCS_ONCE 的方案,即一次测试一组函数,并且仅在其损坏的情况下才进行每个函数检查。当第一次检查起作用时,它应该与当前方案一样快,除了显式检查假设(例如,将一起检查 HAVE_LONGDOUBLE_FUNCS 隐含的所有函数)。

问题

静态与非静态?对于基本函数,我们是否应该将它们定义为静态?

执照

本文档已置于公共领域。

[1]:这里自动预订