ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

Numba 0.64.0 版本解析:NumPy 2.4 支持、np.moveaxis 新增与关键 Bug 修复详解

Numba 0.64.0 版本解析:NumPy 2.4 支持、np.moveaxis 新增与关键 Bug 修复详解 编译器高性能计算【免费下载链接】numbaNumPy aware dynamic Python compiler using LLVM项目地址https://gitcode.com/gh_mirrors/nu/numba点击查看免费下载Numba 0.64.0 是一个重要的主版本发布核心亮点是正式支持 NumPy 2.4同时新增了对np.moveaxis的 nopython 模式支持并修复了np.all/np.any标量处理、数组布局转换 readonly 处理、s390x 整数类型提升、Python 3.11 大整数幂运算精度等一系列问题。本文以官方发布说明docs/source/release/0.64.0-notes.rst为骨架结合仓库源码与测试用例逐项剖析这些变更的实现原理与迁移影响帮助读者在升级到 0.64.0 时顺利完成 NumPy 兼容性切换并规避潜在陷阱。版本概览与兼容性声明Numba 0.64.0 发布于 2026 年 2 月 18 日属于主版本major release发布。发布说明开篇即点明本版本的核心能力变化Numba now supports NumPy 2.4.这一定位意味着使用 0.64.0 的开发者可以在已经升级到 NumPy 2.4 的 Python 环境中继续使用 Numba 的 nopython 模式对数组操作进行 JIT 编译而无需回退 NumPy 版本。与 NumPy 支持同步推进的还有对 Python 3.14 的持续适配见 PR#10256、#10339的 CI/依赖更新以及 CI 从 Azure 向 GitHub Actions 迁移、osx-64 被列入 Tier 2 支持列表等工程化调整PR#10347、#10384。从发布说明的 PR 列表看0.64.0 汇聚了来自社区十余名贡献者的约 30 个合并请求内容涵盖 NumPy 兼容、新功能、缺陷修复、CI/文档维护四大类。本文聚焦其中的功能性变更逐个展开源码级分析。NumPy 2.4 支持两个必须注意的 API 移除NumPy 2.4 对 Numba 最直接的影响是移除了两个旧 API若代码中仍在调用它们升级后会在 nopython 模式下直接报错。官方建议如下np.trapz 已被移除改用 np.trapezoidNumPy 2.4 中np.trapz被彻底移除替代方案是np.trapezoid该函数自 NumPy 2.0 起即已可用迁移时只需将调用名从np.trapz替换为np.trapezoid参数签名y、x、dx、axis保持一致。np.in1d 已被移除改用 np.isinNumPy 2.4 中np.in1d被彻底移除替代方案是np.isin语义等价判断第一个数组中的元素是否出现在第二个数组中迁移时替换函数名即可np.isin同样支持assume_unique、invert等参数。这两项调整的落地由 PR#10393add Numpy 2.4 support完成并配套 PR#10417Fix: NumPy2.4 CI test error修复了 CI 中的兼容性测试问题。对于 Numba 使用者来说这是升级 0.64.0 时最需要主动执行的代码迁移动作——因为 Numba 的 nopython 模式并不拦截对已移除 API 的调用错误会以 TypingError 或运行时错误的形式暴露出来提前替换更稳妥。新功能np.moveaxis 的 nopython 模式支持np.moveaxis是 NumPy 中用于将数组的轴移动到新位置的高频函数常用于维度重排。此前 Numba 的 nopython 模式并不支持它0.64.0 通过 PR#10366补齐了这一能力。实现原理基于 transpose 的轴重排Numba 对np.moveaxis的实现位于 numba/np/arrayobj.py通过overload(np.moveaxis)注册overload(np.moveaxis) def numpy_moveaxis(a, source, destination): if not isinstance(a, types.Array): raise errors.TypingError(The first argument a must be an array) ... def impl(a, source, destination): source normalize_axis_tuple(np.moveaxis, source, ndim, source) destination normalize_axis_tuple(np.moveaxis, destination, ndim, destination) if len(source) ! len(destination): raise ValueError(...) order_list [n for n in range(a.ndim) if n not in source] for dest, src in sorted(zip(destination, source)): order_list.insert(dest, src) order order_init for i, o in enumerate(order_list): order tuple_setitem(order, i, o) return a.transpose(order) return impl从源码结构可以清晰地看出其设计思路np.moveaxis在 Numba 中不是独立实现的高维搬移逻辑而是先计算一个轴置换顺序order再复用底层已经高度优化的a.transpose(order)。这既避免了重复实现内存搬移逻辑又保证了与 NumPy 语义的一致性——np.moveaxis本身在 NumPy 中的实现也是基于转置的视图操作不复制数据。类型检查方面实现严格约束了三类参数参数允许类型非法输入时的报错信息a数组types.ArrayThe first argument a must be an arraysource整数或整数序列types.Integer/types.SequenceThe second argument source must be an integer or sequence of integersdestination整数或整数序列types.Integer/types.SequenceThe third argument destination must be an integer or sequence of integers支持负数轴索引与元组形式的 source/destination与 NumPy 行为对齐。测试覆盖边界条件与异常路径测试位于 numba/tests/test_np_functions.py分为功能与异常两组功能测试test_moveaxis_basic使用np.arange(120).reshape(1, 2, 3, 4, 5)这一 5 维数组覆盖了多组 source/destination 组合for source, destination in ( (0, -1), # 负轴索引 (1, 3), # 单轴移动 ((0, 1), (-1, -2)), # 多轴 负索引 ((0, 1), (-2, -1)), # 多轴顺序交换 ((1, -3), (-2, 4)), # 混合正负索引 ): expected pyfunc(a, source, destination) got cfunc(a, source, destination) self.assertPreciseEqual(expected, got)每组结果都与纯 Python 版 NumPy 调用做assertPreciseEqual精确比对验证 nopython 编译结果与 NumPy 语义完全一致。异常测试test_moveaxis_exception则验证了四条错误路径非数组输入、非整数 source/destination 触发TypingError并断言了对应的报错文案cfunc(np.arange(4), 1, 0)触发ValueError: np.moveaxis: Argument source out of bounds(0, 1) - (1, -3)触发np.moveaxis: Argument destination out of bounds(0, 0)重复轴触发np.moveaxis: repeated axis in source argument(0, 1) - (1, -1)触发np.moveaxis: repeated axis in destination argument。这些测试一方面保证了实现的正确性另一方面也表明越界与重复轴的报错文案与 NumPy 保持一致便于开发者排错。使用示例import numpy as np from numba import njit njit def shift_axis(a): # 将第 0 轴移动到最后一维 return np.moveaxis(a, 0, -1) a np.arange(24).reshape(2, 3, 4) print(shift_axis(a).shape) # (3, 4, 2)Bug 修复详解0.64.0 共修复了五类功能性缺陷其中多数影响面较大值得逐一关注。np.all 与 np.any 的标量输入处理问题背景在 0.64.0 之前np.all和np.any在 nopython 模式下被传入标量如np.all(5)、np.any(0)时会失败。这是因为此前的 overload 实现只考虑了数组输入标量路径缺失。修复内容PR#10223、#10224以np.all为例修复后的实现在 numba/np/arraymath.py 中为标量增加了独立分支overload(np.all) overload_method(types.Array, all) def np_all(a): # for scalar if isinstance(a, (types.Number, types.Boolean)): def scalar_all(a): return bool(a) return scalar_all if isinstance(a, (NPDatetime, NPTimedelta)): def temporal_scalar_all(a): return np.int64(a) ! 0 return temporal_scalar_all # for array if isinstance(a, types.Array): def flat_all(a): for v in np.nditer(a): if not v.item(): return False return True return flat_all return Nonenp.any的修复PR#10224与之对称同样增加了标量分支将标量转换为布尔值。从源码看该 overload 同时服务于np.all函数与数组方法.all()通过overload_method注册因此这一修复对两种调用形式都生效。修复后的行为语义为标量输入np.all(x)等价于bool(x)np.any(x)同样等价于bool(x)对NPDatetime/NPTimedelta则比较其int64表示是否为 0数组输入维持原有逻辑遍历所有元素判断是否全真/存在真值。np.asfortranarray / np.ascontiguousarray 的 readonly 处理问题背景对应 issue#10357此前当输入数组是只读readonly时即使通过np.asfortranarray或np.ascontiguousarray产生了新的拷贝返回的数组仍然继承 readonly 标志。这与 NumPy 语义不符——拷贝理应产生可写的新数组。修复内容PR#10390核心修改在 numba/np/arrayobj.py 的_as_layout_array与新增的_as_layout_array_intrinsic中。布局转换的内在逻辑是0 维输入asfortranarray()返回 1 维数组shape 为(1,)输入布局与目标布局一致或 1 维且为 C/F 任一连续布局直接返回原数组借用不拷贝输入布局未知layout A编译期无法确定运行时用is_contiguous/is_fortran检查已连续则直接返回否则拷贝其余情况拷贝为指定布局的新数组。修复的关键在于拷贝路径新增的 intrinsic_as_layout_array_intrinsic在构造返回类型时显式指定ret a.copy( layoutoutput_layout.literal_value, ndimmax(a.ndim, 1), readonlyFalse) # 拷贝结果必须是可写的即凡是通过拷贝得到的新数组其readonly一律置为False而直接借用原数组的路径布局已匹配则保留原数组的属性。这样既符合 NumPy 语义拷贝产生可写数组又避免了不必要的拷贝开销。两个 overload 的完整行为np.ascontiguousarray(a)标量/布尔输入先np.array(a)再转 C 连续布局数组输入走_as_layout_array_intrinsic(a, C)np.asfortranarray(a)标量/布尔输入先np.array(a)再转 Fortran 连续布局数组输入走_as_layout_array_intrinsic(a, F)。同时_as_layout_array中明确断言返回类型布局与目标布局一致assert retty.layout output_layout保证编译期类型与运行时行为相符。s390x 上整数类型提升SystemZ ABI 兼容问题背景在 s390xIBM Z架构上pythonapi相关路径存在段错误segmentation fault。根因是 SystemZ ABI 要求整数参数在传入函数时须提升到完整的寄存器宽度而 Numba 在 CPU 与 Python API 的 lowering 层没有执行这一提升。修复内容PR#10396在 CPU 与 Python API 的 lowering 层为整数类型补充了完整的寄存器宽度提升逻辑确保在 s390x 上按 ABI 规范传递整数。这一修复对大多数 x86/ARM 用户无感知但对 IBM Z 上的部署而言是关键的正确性补丁。Python 3.11 大整数幂运算精度丢失问题背景对应 issue#9931在 Python 3.11 上nopython 模式中执行整数幂运算如x ** 2时当结果大于 2^53 会出现精度丢失。2^53 正是 IEEE 754 double 可以无损表示的最大整数说明幂运算路径中存在隐式的浮点转换。修复内容PR#10398修复后整数幂运算在结果大于 2^53 时仍保持完整整数精度。此修复针对 Python 3.11 生效修复后的行为可验证如下import numpy as np from numba import njit njit def power2(x): return x ** 2 # 2^53 之上必须保持精确整数结果 x 2**27 1 # 大于 2^53 开方后的整数 print(power2(x)) # 结果不再丢失精度 print(power2(x) (2**27 1) ** 2) # True对于依赖大整数精确运算的数值代码这一修复避免了静默的精度污染。工程与 CI 层面的变更发布说明的 PR 列表中还包含若干不直接改变用户可见功能、但对项目演进有意义的工程调整简述如下CI 迁移与清理将 osx64 相关的 Azure 流水线移除并迁移至 GitHub ActionsPR#10347删除 pre-commit 配置PR#10351新增 numba 定时测试工作流PR#10324依赖与工具链升级Python 依赖版本提升至 3.14PR#10339wheel 构建工作流改为安装预发布的 llvmlite 版本PR#10391并对 conda-libmamba-solver 添加版本约束PR#10359版本支持表更新为 0.64.0rc1 及正式版更新版本支持矩阵PR#10422、#10438并将 osx-64 加入 Tier 2 支持列表PR#10384文档修正修正 macOS 上 OpenMP 依赖说明与正文不一致的问题PR#103690.63.x 补丁回移将 0.63.0 与 0.63.1 的修复 cherry-pick 进入本版本线PR#10371、#10378。升级到 0.64.0 的行动清单结合发布说明与源码分析从 0.63.x 升级到 0.64.0 时建议按以下顺序核对NumPy 版本确认环境中的 NumPy 已升级到 2.4本版本的核心能力API 迁移全局搜索并替换np.trapz→np.trapezoid、np.in1d→np.isin标量断言如代码中大量使用np.all(...)/np.any(...)且可能传入标量0.64.0 后行为与 NumPy 对齐标量转 bool可放心移除以往的规避写法布局转换如依赖np.asfortranarray/np.ascontiguousarray的结果可写性0.64.0 的拷贝路径已保证返回可写数组平台验证若在 s390xIBM Z部署务必升级以修复 pythonapi 段错误若在 Python 3.11 上做超大整数幂运算升级后可获得完整精度新能力np.moveaxis现在可直接在njit函数中使用替代手动 transpose 的繁琐写法。关键源码与测试索引发布说明原文docs/source/release/0.64.0-notes.rstnp.moveaxisoverload 实现numba/np/arrayobj.pynp.moveaxis功能/异常测试numba/tests/test_np_functions.pynp.all标量修复实现numba/np/arraymath.pynp.ascontiguousarray/np.asfortranarray布局转换与 readonly 修复numba/np/arrayobj.pyNumPy 兼容性文档docs/source/reference/numpysupported.rst版本支持矩阵与发布流程相关docs/source/release/0.64.0-notes.rst中 PR#10422、#10438对应的更新赞分享编译器高性能计算【免费下载链接】numbaNumPy aware dynamic Python compiler using LLVM项目地址https://gitcode.com/gh_mirrors/nu/numba点击查看免费下载相关推荐Celery 2.4 版本历史详解安全修复、Broker URL 支持与关键演进Celery 2.4 版本历史详解安全修复、Broker URL 支持与关键演进 导读 本文基于当前仓库 docs/history/changelog 2.4任务调度后端消息队列RuboCop 1.8.0 版本解析三大新 Cop、asdf 版本支持与关键 Bug 修复RuboCop 1.8.0 版本解析三大新 Cop、asdf 版本支持与关键 Bug 修复 本篇指南围绕 RuboCop v1.8.0 版本发布内容展开覆盖代码质量Lint格式化静态分析开发工具NumPy 1.21.3 维护版本发布说明Python 3.10 支持与关键 Bug 修复深度解析NumPy 1.21.3 维护版本发布说明Python 3.10 支持与关键 Bug 修复深度解析 NumPy 1.21.3 是继 1.21.2 之后发布的一科学计算数据分析创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表