原文:
numpy.org/doc/
NumPy 1.20.0 发布说明
原文:
numpy.org/doc/1.26/release/1.20.0-notes.html
这次 NumPy 发布是迄今为止最大的,共有 684 个 PRs 由 184 人贡献并已合并。有关此次发布支持的 Python 版本为 3.7-3.9,不再支持 Python 3.6。重点是
- NumPy 函数的注释。这项工作正在进行中,预计会根据用户的反馈进行改进。
- 更广泛地使用 SIMD 以增加 ufuncs 的执行速度。在不同的硬件平台上引入了将简化对现代特性的使用的通用函数的工作。此项工作正在进行中。
- 在更改 dtype 和转换实现方案方面做出了初步工作,以便提供更简单的路径来扩展 dtypes。这项工作正在进行中,但已经做得足够多以允许进行实验和反馈。
- 大量的文档改进,合并了大约 185 个 PR。这项工作正在进行中,是改进 NumPy 在线存在和对新用户有用性的较大项目的一部分。
- 进一步清理与移除 Python 2.7 相关的工作。这有助于提高代码的可读性并消除技术债务。
- 对即将推出的 Cython 3.0 的初步支持。
新函数
random.Generator 类具有一个新的 permuted
函数。
新函数与 shuffle
和 permutation
的不同之处在于,由轴索引的子数组进行了排列,而不是将轴视为其他索引的每个组合的独立 1-D 数组。例如,现在可以对 2-D 数组的行或列进行排列。
(gh-15121)
sliding_window_view
为 numpy 数组提供了滑动窗口视图。
numpy.lib.stride_tricks.sliding_window_view
构建了 numpy 数组的视图,提供了对数组的滑动或移动窗口访问。这允许简单地实现某些算法,例如运行均值。
(gh-17394)
numpy.broadcast_shapes
是一种新的面向用户的函数。
broadcast_shapes
从对给定形状元组进行广播获取生成的形状。
>>> np.broadcast_shapes((1, 2), (3, 1))
(3, 2)
>>> np.broadcast_shapes(2, (3, 1))
(3, 2)
>>> np.broadcast_shapes((6, 7), (5, 6, 1), (7,), (5, 1, 7))
(5, 6, 7)
(gh-17535)
弃用
已弃用使用内置类型的别名,如 np.int
。
长期以来,np.int
一直是内置 int
的别名。这一直是新手困惑的原因,在主要是出于历史原因。
这些别名已经被弃用。下表显示了被弃用别名的完整列表,以及它们的确切含义。用第一列中的项目替换为第二列的内容将完全相同,并且可以消除弃用警告。
第三列列出了偶尔更好的替代 NumPy 名称。另请参阅数据类型以获取更多详细信息。
弃用的名称 | 相同于 | NumPy 标量类型名称 |
---|---|---|
numpy.bool | bool | numpy.bool_ |
numpy.int | int | numpy.int_ (默认), numpy.int64, 或 numpy.int32 |
numpy.float | float | numpy.float64, numpy.float_, numpy.double (等效) |
numpy.complex | complex | numpy.complex128, numpy.complex_, numpy.cdouble (等效) |
numpy.object | object | numpy.object_ |
numpy.str | str | numpy.str_ |
numpy.long | int | numpy.int_ (C long), numpy.longlong (最大的整数类型) |
numpy.unicode | str | numpy.unicode_ |
为了为绝大多数情况提供明确的指导,对于类型 bool
, object
, str
(以及 unicode
),使用普通版本会更简短、清晰,通常是很好的替代方式。对于 float
和 complex
,如果您希望更明确地表示精度,可以使用 float64
和 complex128
。
对于 np.int
,直接用 np.int_
或 int
替换也很好,并且不会改变行为,但精度仍然取决于计算机和操作系统。如果您想要更明确地审查并调查当前使用情况,您有以下替代方案:
- 用
np.int64
或np.int32
来精确指定精度。这确保了结果不会取决于计算机或操作系统。 -
np.int_
或int
(默认),但请注意这取决于计算机和操作系统。 - C 类型:
np.cint
(int),np.int_
(long),np.longlong
。 -
np.intp
在 32 位机器上为 32 位,在 64 位机器上为 64 位。这可能是最好的索引使用类型。
当与np.dtype(...)
或dtype=...
一起使用时,将其更改为上述所提及的 NumPy 名称对输出没有影响。如果用作标量使用:
np.float(123)
改变它可能会微妙地改变结果。在这种情况下,通常更喜欢 Python 版本的float(123)
或int(12.)
,尽管 NumPy 版本可能对于与 NumPy 数组的一致性而言可能更有用(例如,对于诸如零除法之类的事情,NumPy 会有不同的行为)。
(gh-14882)
向带有非可选形状参数的函数传递shape=None
是被弃用的
以前,这是传递shape=()
的别名。这是由 C API 中的PyArray_IntpConverter发出的弃用警告。如果您的 API 意图支持传递None
,那么您应该在调用转换器之前检查None
,以便能够区分None
和()
。
(gh-15886)
即使索引结果为空,也会报告索引错误
今后,当整数数组索引包含超出边界值时,NumPy 将引发 IndexError,即使未索引的维度长度为 0。这将会发出 DeprecationWarning。当数组之前为空,或者涉及一个空切片时,就会发生这种情况:
代码语言:javascript复制arr1 = np.zeros((5, 0))
arr1[[20]]
arr2 = np.zeros((5, 5))
arr2[[20], :0]
以前,非空索引[20]
未经检查正确性。现在将会检查并引发弃用警告,并将其转变为错误。这也适用于赋值。
(gh-15900)
对于mode
和searchside
不精确匹配是被弃用的
以前,对mode
和searchside
的不精确和不区分大小写的匹配是有效输入,并且现在会发出 DeprecationWarning。例如,以下是现在已弃用并将发出 DeprecationWarning 的一些示例用法:
import numpy as np
arr = np.array([[3, 6, 6], [4, 5, 1]])
# mode: inexact match
np.ravel_multi_index(arr, (7, 6), mode="clap") # should be "clip"
# searchside: inexact match
np.searchsorted(arr[0], 4, side='random') # should be "right"
(gh-16056)
numpy.dual已弃用
模块numpy.dual已被弃用。不应再从numpy.dual导入函数,而应该直接从 NumPy 或 SciPy 导入函数。
(gh-16156)
outer
和ufunc.outer
对矩阵是被弃用的
np.matrix
在outer
或通用 ufunc outer 调用(例如numpy.add.outer
)中的使用。以前,矩阵在此处被转换为数组。今后将不再这样做,需要手动将其转换为数组。
(gh-16232)
更多数字风格类型被弃用
剩余的数字风格类型代码Bytes0
、Str0
、Uint32
、Uint64
和Datetime64
都已被弃用。应该改用小写变体。对于字节和字符串,"S"
和"U"
也是可选的替代方案。
(gh-16554)
ndindex
的ndincr
方法已被弃用
从 NumPy 1.8 开始,文档已警告不要使用此功能。应该使用next(it)
代替it.ndincr()
。
(gh-17233)
未定义__len__
和__getitem__
的 ArrayLike 对象
定义__array__
、__array_interface__
或__array_struct__
协议之一但不是序列(通常定义为有__len__
和__getitem__
的对象)的对象,在将来进行数组强制转换时将会有不同的行为。
当嵌套在序列中,例如np.array([array_like])
,这些内容将被处理为单个 Python 对象而不是数组。将来它们将与以下内容行为一致:
np.array([np.array(array_like)])
如果np.array(array_like)
不是 0 维的,这种变更只会对此警告产生影响。解决此警告可能取决于对象:
- 一些数组样式可能会期望新的行为,而用户可以忽略警告。对象可以选择公开序列协议以选择新行为。
- 例如,
shapely
将允许使用line.coords
而不是np.asarray(line)
进行类似数组的转换。用户可以绕过警告,或者在新约定可用时使用它。
不幸的是,只能通过调用np.array(array_like)
来使用新行为。
如果希望确保旧行为保持不变,请首先创建一个对象数组,然后显式地填充它,例如:
代码语言:javascript复制arr = np.empty(3, dtype=object)
arr[:] = [array_like1, array_like2, array_like3]
这样可以确保 NumPy 知道不要将其视为数组,而是将其视为对象。
(gh-17973)
未来变化
数组不能使用子数组类型
使用np.array(arr, dtype)
和arr.astype(dtype)
进行数组创建和转换将在dtype
为诸如np.dtype("(2)i,")
的子数组 dtype 时使用不同的逻辑。
对于这样的dtype
,以下行为是正确的:
res = np.array(arr, dtype)
res.dtype is not dtype
res.dtype is dtype.base
res.shape == arr.shape dtype.shape
但res
使用以下逻辑填充:
res = np.empty(arr.shape dtype.shape, dtype=dtype.base)
res[...] = arr
这将使用不正确的广播(通常会导致错误)。将来,这将分别转换每个元素,导致与以下结果相同:
代码语言:javascript复制res = np.array(arr, dtype=np.dtype(["f", dtype]))["f"]
这通常可以用于选择新行为。
此更改不会影响np.array(list, dtype="(2)i,")
,除非list
本身包含至少一个数组。特别是,对于元组列表,行为不变。
(gh-17596)
已过期的停用内容
- 数值样式类型代码
np.dtype("Complex64")
(大写拼写)已过期。"Complex64"
对应于"complex128"
,而"Complex32"
对应于"complex64"
。 -
np.sctypeNA
和np.typeNA
的停用期已过。它们已从公共 API 中删除。请使用np.typeDict
代替。 (gh-16554) -
np.ctypeslib.ctypes_load_library
的 14 年停用期已过。请使用load_library
,它与原功能完全相同。 (gh-17116)
移除财务功能
符合 NEP 32 的规定,NumPy 1.20 将删除财务函数。被删除的函数有fv
、ipmt
、irr
、mirr
、nper
、npv
、pmt
、ppmt
、pv
和rate
。这些函数在numpy_financial库中可用。
(gh-17067)
兼容性说明
isinstance(dtype, np.dtype)
而不是type(dtype) is not np.dtype
NumPy 的数据类型现在不再是np.dtype
的直接实例。可能使用了type(dtype) is np.dtype
的代码将始终返回False
,必须更新为使用正确的版本isinstance(dtype, np.dtype)
。
此更改还会影响兼容性方面的宏PyArray_DescrCheck
,如果针对的是早于 1.16.6 版的 NumPy 进行编译。如果代码使用了该宏,并希望针对旧版本的 NumPy 进行编译,必须替换该宏(也见 C API changes 部分)。
在axis=None
情况下 concatenate 中的 same kind 转换
当以axis=None
调用concatenate
时,被展平的数组会使用unsafe
进行转换。任何其他轴选择都会使用“same kind”。这种不同的默认值已经被弃用,将使用“same kind”转换。新的casting
关键字参数可用于保留旧的行为。
(gh-16134)
当 NumPy 标量分配给数组时会发生强制转换
在创建或分配数组时,在所有相关情况下,NumPy 标量现在将被与 NumPy 数组完全相同地进行强制转换。特别是这将改变一些以前会引发错误的情况的行为:
代码语言:javascript复制np.array([np.float64(np.nan)], dtype=np.int64)
将会成功,并返回一个未定义的结果(通常是可能的最小整数)。这也会影响分配:
代码语言:javascript复制arr[0] = np.float64(np.nan)
此时,NumPy 保留以下内容的行为:
代码语言:javascript复制np.array(np.float64(np.nan), dtype=np.int64)
以上更改不会影响 Python 标量:
代码语言:javascript复制np.array([float("NaN")], dtype=np.int64)
保持不变(np.nan
是 Python 的float
,而不是 NumPy 的)。与有符号整数不同,无符号整数不保留这种特殊情况,因为它们一直更像是强制转换。以下代码不再引发错误:
np.array([np.float64(np.nan)], dtype=np.uint64)
为避免向后兼容性问题,此时从datetime64
标量分配给长度过短的字符串仍然受支持。这意味着np.asarray(np.datetime64("2020-10-10"), dtype="S5")
现在可以成功,而之前不行。从长远来看,这可能会被弃用,或者不安全的强制转换可能被普遍允许,以使数组和标量的分配行为一致。
在混合字符串和其他类型时,数组的强制转换发生了变化
当字符串和其他类型混合时,例如:
代码语言:javascript复制np.array(["string", np.float64(3.)], dtype="S")
结果将发生变化,这可能导致在某些情况下具有更长字符串的字符串数据类型。特别是,如果未提供dtype="S"
,任何数值都将导致字符串足够长以容纳所有可能的数值(例如,“S32”用于浮点数)。请注意,当将非字符串转换为字符串时,应始终提供dtype="S"
。
如果提供了 dtype="S"
,结果将与以前大体相同,但是 NumPy 标量类型(不是像 1.0
这样的 Python 浮点数)仍将强制执行统一的字符串长度:
np.array([np.float64(3.)], dtype="S") # gives "S32"
np.array([3.0], dtype="S") # gives "S3"
以前的第一个版本给出与第二个版本相同的结果。
数组强制转换重构
数组强制转换已重构。一般情况下,这不应影响用户。在极为罕见的角落情况下,其中类数组对象是嵌套的:
代码语言:javascript复制np.array([array_like1])
现在将更一致地处理:
代码语言:javascript复制np.array([np.array(array_like1)])
这可能会微妙地改变一些定义不良的类数组对象的输出。其中一个例子是不是也是匹配形状的序列的类数组对象。在 NumPy 1.20 中,当类数组对象不是序列时将给出警告(但行为保持不变,请参阅弃用)。如果类数组对象也是序列(定义了 __getitem__
和 __len__
),NumPy 现在将仅使用由 __array__
,__array_interface__
或 __array_struct__
给出的结果。当(嵌套的)序列描述不同的形状时,这将导致差异。
(gh-16200)
写入numpy.broadcast_arrays
的结果将导出只读缓冲区
在 NumPy 1.17 中 numpy.broadcast_arrays
开始在写入结果数组时发出警告。在通过缓冲器接口使用数组时(例如 memoryview(arr)
),将跳过此警告。现在对于返回只读缓冲器的两个协议 __array_interface__
和 __array_struct__
也将发生相同的情况,而不是发出警告。
(gh-16350)
数字样式的类型名称已从类型字典中移除
为了与 np.dtype("Complex64")
和其他数字样式(大写)类型的弃用保持同步。这些已从 np.sctypeDict
和 np.typeDict
中移除。您应该改用小写版本。请注意,"Complex64"
对应于"complex128"
,"Complex32"
对应于"complex64"
。NumPy 样式(新版本)表示完整大小而不是实部/虚部的大小。
(gh-16554)
operator.concat
函数现在对数组参数引发 TypeError
异常
先前的行为是退回到加法并加上这两个数组,这被认为是连接函数的意外行为。
(gh-16570)
nickname
属性已从 ABCPolyBase 中移除
抽象属性 nickname
已从 ABCPolyBase
中移除,因为它已不再在派生的便利类中使用。这可能会影响从 ABCPolyBase
派生类并覆盖表示和显示方法的用户,例如 __str__
,__repr__
,_repr_latex
等。
(gh-16589)
float->timedelta
和uint64->timedelta
提升将引发一个 TypeError
浮点数和时间增长一致地引发 TypeError。现在np.promote_types("float32", "m8")
与np.promote_types("m8", "float32")
一致,并且都会引发一个 TypeError。以前,np.promote_types("float32", "m8")
返回"m8"
被认为是一个错误。
Uint64 和时间增长现在一致地引发 TypeError。现在np.promote_types("uint64", "m8")
与np.promote_types("m8", "uint64")
一致,并且都会引发一个 TypeError。以前,np.promote_types("uint64", "m8")
返回"m8"
被认为是一个错误。
(gh-16592)
numpy.genfromtxt
现在可以正确地解包结构化数组
以前,当使用unpack=True
并且将结构化数据类型传递给dtype
参数(或者传递dtype=None
并且推断出结构化数据类型)时,numpy.genfromtxt
会解包失败。例如:
>>> data = StringIO("21 58.0n35 72.0")
>>> np.genfromtxt(data, dtype=None, unpack=True)
array([(21, 58.), (35, 72.)], dtype=[('f0', '<i8'), ('f1', '<f8')])
结构化数组现在将正确地解包为一个数组列表,每个列一个:
代码语言:javascript复制>>> np.genfromtxt(data, dtype=None, unpack=True)
[array([21, 35]), array([58., 72.])]
(gh-16650)
mgrid
、r_
等现在对于非默认精度输入始终返回正确的输出
以前,np.mgrid[np.float32(0.1):np.float32(0.35):np.float32(0.1),]
和np.r_[0:10:np.complex64(3j)]
无法返回有意义的输出。这个 bug 可能会影响到mgrid
、ogrid
、r_
、以及c_
的输入,当使用的 dtype 不是默认的float64
和complex128
以及等效的 Python 类型时。这些方法已经被修复,以正确处理不同的精度。
(gh-16815)
具有不匹配形状的布尔数组索引现在会正确地给出IndexError
以前,如果布尔数组索引与被索引数组的大小匹配但形状不匹配,则在某些情况下会被错误地允许。在其他情况下,它会出错,但错误会不正确地是关于广播的ValueError
,而不是正确的IndexError
。
例如,以下内容以前会错误地给出ValueError: operands could not be broadcast together with shapes (2,2) (1,4)
:
np.empty((2, 2))[np.array([[True, False, False, False]])]
以前,以下内容会错误地返回array([], dtype=float64)
:
np.empty((2, 2))[np.array([[False, False, False, False]])]
现在都可以正确地给出IndexError: boolean index did not match indexed array along dimension 0; dimension is 2 but corresponding boolean dimension is 1
。
(gh-17010)
强制转换错误中断迭代
在迭代时进行值转换,错误可能会比以前导致迭代提前停止。在任何情况下,失败的类型转换操作总是返回未定义的部分结果。现在可能更加未定义和部分。对于使用NpyIter
C-API 的用户,这样的类型转换错误现在会导致*iternext()*函数返回 0,因此中止迭代。目前,没有 API 直接检测这样的错误。需要检查PyErr_Occurred()
,这可能在与NpyIter_Reset
结合时有问题。这些问题一直存在,但如果用户需要,可以添加新的 API。
(gh-17029)
f2py 生成的代码可能返回 unicode 而不是字节字符串
之前由 f2py 生成的代码返回的一些字节字符串现在可能是 unicode 字符串。这是由正在进行的 Python2 到 Python3 清理导致的。
(gh-17068)
__array_interface__["data"]
元组的第一个元素必须是整数
这已经是多年的文档接口,但仍然有代码会接受指针地址的字节字符串表示。该代码已被移除,传递地址作为字节字符串现在会引发错误。
(gh-17241)
poly1d
遵循所有零参数的 dtype
之前,使用所有零系数构造poly1d
的实例会将系数转换为np.float64
。这会影响内部构造poly1d
实例的方法的输出 dtype,比如np.polymul
。
(gh-17577)
swig 的 numpy.i 文件现在只支持 Python 3。
Python 2.7 的 C-API 函数已经更新为只支持 Python 3。需要旧版本的用户应该从旧版本的 NumPy 获取。
(gh-17580)
np.array
的空 dtype 检测
在使用np.array(..., dtype="V")
、arr.astype("V")
等调用时,除非所有元素的 void 长度相同,否则将正确引发 TypeError。一个例子是:
np.array([b"1", b"12"], dtype="V")
之前返回的数组的 dtype 是"V2"
,不能准确表示b"1"
。
(gh-17706)
C API 的变化
PyArray_DescrCheck
宏已被修改
PyArray_DescrCheck
宏自 NumPy 1.16.6 以来已经更新为:
#define PyArray_DescrCheck(op) PyObject_TypeCheck(op, &PyArrayDescr_Type)
从 NumPy 1.20 开始,针对先前版本编译的代码将与 NumPy 1.20 不兼容。修复的方法是要么针对 1.16.6 进行编译(如果您希望支持的最旧版本为 NumPy 1.16),要么通过将其替换为新定义来手动内联宏:
代码语言:javascript复制PyObject_TypeCheck(op, &PyArrayDescr_Type)
与所有 NumPy 版本兼容。
np.ndarray
和np.void_
的大小变化
PyArrayObject
和PyVoidScalarObject
结构的大小已经改变。已删除以下头文件定义:
#define NPY_SIZEOF_PYARRAYOBJECT (sizeof(PyArrayObject_fields))
因为大小不应被视为编译时常量:对于 NumPy 的不同运行时版本,它会改变。
最可能相关的用途是用 C 编写的潜在子类,它们将需要重新编译并应该进行更新。请参阅PyArrayObject
的文档以获取更多详细信息,并如果受到此更改的影响,请联系 NumPy 开发人员。
NumPy 将尝试给出优雅的错误,但一个期望固定结构大小的程序可能会有未定义的行为并可能崩溃。
(gh-16938)
新特性
numpy.all
和numpy.any
函数的where
关键参数
where
关键参数被添加,允许在布尔评估all
和any
时只考虑数组中指定的元素或子轴。这个新关键字可通过numpy
的all
和any
函数直接使用或在numpy.ndarray
的方法中使用。
任意可广播的布尔数组或标量都可以设置为where
。如果用户未设置where
,默认为True
,以评估数组中的所有元素的函数。示例在函数的文档中给出。
numpy
函数mean
、std
、var
的where
关键参数
添加where
关键参数,允许将mean
、std
和var
的计算范围限制为仅一部分元素。可直接通过numpy
使用,也可在numpy.ndarray
的方法中使用。
任意可广播的布尔数组或标量都可以设置为where
。如果用户未设置where
,默认为True
,以评估数组中的所有元素的函数。示例在函数的文档中给出。
(gh-15852)
norm=backward
、forward
关键选项用于numpy.fft
函数
关键参数选项norm=backward
被添加作为None
的别名,并作为默认选项;使用它会使直接转换不经缩放,而逆转换经缩放乘以1/n
。
使用新的关键参数选项norm=forward
会使直接转换经缩放乘以1/n
,逆转换不经缩放(即与默认选项norm=backward
完全相反)。
(gh-16476)
NumPy 现在已经有了类型
对 NumPy 的大部分部分添加了类型注释。还有一个新的numpy.typing
模块,其中包含了对最终用户有用的类型。目前可用的类型有
-
ArrayLike
:可转换为数组的对象 -
DtypeLike
:可转换为 dtype 的对象
(gh-16515)
numpy.typing
在运行时可访问
现在numpy.typing
中的类型可以在运行时导入。以下代码现在可以使用:
from numpy.typing import ArrayLike
x: ArrayLike = [1, 2, 3, 4]
(gh-16558)
f2py 生成的模块现在有新的 __f2py_numpy_version__
属性。
因为 f2py 与 NumPy 一起发布,__f2py_numpy_version__
提供了跟踪使用的 f2py 版本生成模块的方法。
(gh-16594)
可以通过 runtests.py 运行 mypy
测试
当前运行 mypy 配置了 NumPy 存根需要以下两者之一:
- 安装 NumPy
- 将源目录添加到 MYPYPATH 并链接到
mypy.ini
这两个选项都有点不方便,因此添加一个 --mypy
选项来运行测试,它会帮助为你设置一切。这在将来对于任何类型代码生成也将非常有用,因为它会确保在类型检查之前构建项目。
(gh-17123)
对用户定义的 BLAS/LAPACK 探测顺序进行否定
distutils
在确定 BLAS/LAPACK 库时允许否定库。这可以用于在库解析阶段移除元素,即禁止使用 NetLIB 库,可以这样做:
NPY_BLAS_ORDER='^blas' NPY_LAPACK_ORDER='^lapack' python setup.py build
那将使用任何加速库。
(gh-17219)
允许将优化参数传递给 asv 构建
现在,当使用 --bench-compare
参数时,可以将 -j
、 --cpu-baseline
、 --cpu-dispatch
和 --disable-optimization
标志传递给 ASV 构建。
(gh-17284)
NVIDIA HPC SDK nvfortran 编译器现已得到支持
已添加对 nvfortran 编译器的支持,该编译器是 pgfortran 的一种版本。
(gh-17344)
cov
和 corrcoef
的 dtype
选项
dtype
选项现在适用于 numpy.cov
和 numpy.corrcoef
。它指定返回结果应具有的数据类型。默认情况下,这些函数仍然返回一个 numpy.float64
结果。
(gh-17456)
改进
对于多项式的改进的字符串表示(__str__
)
numpy.polynomial
中所有六种多项式类型的字符串表示(__str__
)已更新,更改为提供多项式的数学表达式,而不是系数的数组。有两种包范围的多项式表达格式可用——一种使用上标和下标的 Unicode 字符,另一种仅使用 ASCII 字符。
(gh-15666)
将 Accelerate 库移除作为可选的 LAPACK 库
苹果不再支持 Accelerate 。移除它。
(gh-15759)
包含多行对象的对象数组具有更可读的repr
如果对象数组的元素包含包含有换行符的 repr
,那么被折行的行将按列对齐。特别地,这改善了嵌套数组的 repr
:
>>> np.array([np.eye(2), np.eye(3)], dtype=object)
array([array([[1., 0.],
[0., 1.]]),
array([[1., 0., 0.],
[0., 1., 0.],
[0., 0., 1.]])], dtype=object)
(gh-15997)
Concatenate 支持提供输出的数据类型
在 concatenate
中增加了对提供输出 dtype
和 casting
的支持,使用关键字参数。 dtype
参数不能与 out
参数一起提供。
(gh-16134)
f2py 回调函数线程安全
f2py 中的回调函数现在是线程安全的。
(gh-16519)
numpy.core.records.fromfile
现在支持类文件对象
numpy.rec.fromfile
现在可以使用类文件对象,例如 io.BytesIO
(gh-16675)
AIX 上的 distutils 增加了 RPATH 支持
这使得可以在 AIX 上构建 SciPy。
(gh-16710)
使用由命令行参数指定的 f90 编译器
对于 Fortran Portland Group Compiler,numpy.distutils.fcompiler
中选择的编译器命令已更改。这仅影响链接命令。这迫使使用命令行选项提供的可执行文件(如果有的话),而不是 pgfortran 可执行文件。如果命令行选项没有提供可执行文件,默认为 pgf90 可执行文件,根据 PGI 文档,它是 pgfortran 的别名。
(gh-16730)
为 Cython 3.0 及更高版本添加了 NumPy 声明
Cython 3.0 的 pxd 声明得到改进,避免使用了已弃用的 NumPy C-API 特性。使用 Cython 3.0 构建的扩展模块,使用 NumPy 的话现在可以设置 C 宏 NPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION
,以避免 C 编译器对弃用 API 使用的警告。
(gh-16986)
使窗口函数完全对称
确保 NumPy 提供的窗口函数是对称的。 以前由于数值精度的原因,对称性存在小偏差,现在通过更好地安排计算来避免。
(gh-17195)
性能改进和更改
启用多平台 SIMD 编译器优化
一系列的 NumPy 基础设施改进,为 NEP-38鋪平了道路,可以概括如下:
- 新的构建参数
-
--cpu-baseline
用于指定所需的最小优化集,默认值为min
,提供的是可以安全运行在广泛用户平台上的最小 CPU 功能。 -
--cpu-dispatch
用于指定附加优化的调度集,默认值为max -xop -fma4
,启用除 AMD 传统特性外的所有 CPU 特性。 -
--disable-optimization
明确禁用所有新的改进,它还添加了名为NPY_DISABLE_OPTIMIZATION
的新的C编译器#定义,可以用作任何 SIMD 代码的保护。
-
- 高级 CPU 调度程序
基于 Python/Numpy distutils 的灵活的跨架构 CPU 调度程序,支持所有常见的编译器和广泛的 CPU 特性。
新的调度程序需要特殊的文件扩展名
*.dispatch.c
标记可调度的C源文件。这些源文件可以编译多次,每个编译过程表示特定的 CPU 特性,并提供影响代码路径的不同#定义和标志。 - 新自动生成的 C 标头
core/src/common/_cpu_dispatch.h
此标头由 distutils 模块ccompiler_opt
生成,并包含所有通过命令参数‘–cpu-baseline’和‘–cpu-dispatch’配置的指令集的#定义和标头。 - 新的 C 标头
core/src/common/npy_cpu_dispatch.h
此标头包含了整个 CPU 调度过程所需的所有实用程序,它还可以被看作是将新的基础设施工作与 NumPy CPU 运行时检测连接起来的桥梁。 - 向 NumPy umath 模块(Python 级别)添加新属性
-
__cpu_baseline__
是一个列表,包含了编译器和平台支持的必需优化的最小集合,根据命令参数‘–cpu-baseline’指定的值。 -
__cpu_dispatch__
是一个列表,包含了编译器和平台支持的根据命令参数‘–cpu-dispatch’指定值的附加优化的调度集。
-
- 在 PytestTester 运行期间打印支持的 CPU 特性
(gh-13516)
变化
更改了divmod(1., 0.)
和相关函数的行为
这些变化还确保了不同的编译器版本在这些操作中对 nan 或 inf 使用具有相同的行为。这之前是依赖于编译器的,现在我们强制无效和除 0 标志,使结果在不同编译器下相同。例如,gcc-5、gcc-8 或 gcc-9 现在都产生相同的行为。变化如下:
新行为摘要
操作符 | 旧警告 | 新警告 | 旧结果 | 新结果 | 适用于 MacOS |
---|---|---|---|---|---|
np.divmod(1.0, 0.0) | 无效 | 无效和除 0 | nan, nan | inf, nan | 是 |
np.fmod(1.0, 0.0) | 无效 | 无效 | nan | nan | 否?是 |
np.floor_divide(1.0, 0.0) | 无效 | 除 0 | nan | inf | 是 |
np.remainder(1.0, 0.0) | 无效 | 无效 | nan | nan | 是 |
(gh-16161)
np.linspace
在整数上现在使用 floor
在使用int
类型的时候,以前 float 值会被向零舍入。现在使用numpy.floor
来代替,它向下取整。这会改变负值的结果。例如,以前会得到以下结果:
>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -2, -1, -1, 0, 0, 0, 1])
现在结果是:
代码语言:javascript复制>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -3, -2, -2, -1, -1, 0, 1])
以前的结果仍然可以得到:
代码语言:javascript复制>>> np.linspace(-3, 1, 8).astype(int)
array([-3, -2, -1, -1, 0, 0, 0, 1])
(gh-16841)
新函数
random.Generator 类新增了一个permuted
函数。
这个新函数与shuffle
和permutation
不同之处在于,由轴索引的子数组被排列,而不是将轴视为每个其他索引组合的独立 1-D 数组。例如,现在可以对 2-D 数组的行或列进行排列。
(gh-15121)
sliding_window_view
为 numpy 数组提供了一个滑动窗口视图
numpy.lib.stride_tricks.sliding_window_view
构建了 numpy 数组上的视图,提供了对数组的滑动或移动窗口访问。这允许简单实现某些算法,例如运行均值。
(gh-17394)
numpy.broadcast_shapes
是一个新的面向用户的函数。
broadcast_shapes
从广播给定的形状元组的结果形状。
>>> np.broadcast_shapes((1, 2), (3, 1))
(3, 2)
>>> np.broadcast_shapes(2, (3, 1))
(3, 2)
>>> np.broadcast_shapes((6, 7), (5, 6, 1), (7,), (5, 1, 7))
(5, 6, 7)
(gh-17535)
random.Generator 类新增了一个permuted
函数。
这个新函数与shuffle
和permutation
不同之处在于,由轴索引的子数组被排列,而不是将轴视为每个其他索引组合的独立 1-D 数组。例如,现在可以对 2-D 数组的行或列进行排列。
(gh-15121)
sliding_window_view
为 numpy 数组提供了一个滑动窗口视图
numpy.lib.stride_tricks.sliding_window_view
构建了 numpy 数组上的视图,提供了对数组的滑动或移动窗口访问。这允许简单实现某些算法,例如运行均值。
(gh-17394)
numpy.broadcast_shapes
是一个新的面向用户的函数。
broadcast_shapes
从对抗给定的形状元组中广播得到结果形状。
>>> np.broadcast_shapes((1, 2), (3, 1))
(3, 2)
>>> np.broadcast_shapes(2, (3, 1))
(3, 2)
>>> np.broadcast_shapes((6, 7), (5, 6, 1), (7,), (5, 1, 7))
(5, 6, 7)
(gh-17535)
弃用
使用np.int
之类的内置类型别名已被弃用
长期以来,np.int
一直是内置int
的别名。这常常让新手感到困惑,主要是出于历史原因。
这些别名已经被弃用。下表显示了所有已弃用别名的完整列表,以及它们的确切含义。将第一列中的项目替换为第二列的内容将产生相同效果,并消除弃用警告。
第三列列出了有时可能更优选的替代 NumPy 名称。另请参阅数据类型以获取更多详细信息。
弃用名称 | 相同于 | NumPy 标量类型名称 |
---|---|---|
numpy.bool | bool | numpy.bool_ |
numpy.int | int | numpy.int_ (默认),numpy.int64或numpy.int32 |
numpy.float | float | numpy.float64, numpy.float_, numpy.double (equivalent) |
numpy.complex | complex | numpy.complex128, numpy.complex_, numpy.cdouble (equivalent) |
numpy.object | object | numpy.object_ |
numpy.str | str | numpy.str_ |
numpy.long | int | numpy.int_ (C long), numpy.longlong (largest integer type) |
numpy.unicode | str | numpy.unicode_ |
对于绝大多数情况,对于bool
,object
,str
(和unicode
)类型,使用普通版本更短、更清晰,并且通常是一个良好的替代方案。对于float
和complex
,如果您希望更明确地表示精度,可以使用float64
和complex128
。
对于np.int
,直接使用np.int_
或int
作为替代都是可以的,不会改变行为,但精度会继续依赖于计算机和操作系统。如果您想更具体地检查当前使用情况,可以选择以下替代方案:
-
np.int64
或np.int32
以精确指定精度。这确保了结果不能依赖于计算机或操作系统。 -
np.int_
或int
(默认值),但要注意,这取决于计算机和操作系统。 - C 类型:
np.cint
(int),np.int_
(long),np.longlong
。 -
np.intp
在 32 位机器上为 32 位,在 64 位机器上为 64 位。这可能是用于索引的最佳类型。
当与np.dtype(...)
或dtype=...
一起使用时,将其更改为上述 NumPy 名称不会对输出产生影响。如果用作标量:
np.float(123)
更改它可能会微妙地改变结果。在这种情况下,通常首选 Python 版本float(123)
或int(12.)
,尽管 NumPy 版本可能对于与 NumPy 数组保持一致性(例如,对于像除以零这样的事情,NumPy 的行为与之不同)可能是有用的。
(gh-14882)
向函数传递具有非可选形状参数的shape=None
是不被支持的
以前,这是传递shape=()
的别名。这种弃用是由 C API 中的PyArray_IntpConverter生成的。如果您的 API 旨在支持传递None
,那么在调用转换器之前,您应该先检查None
,以便能够区分None
和()
。
(gh-15886)
即使索引结果为空,索引错误也将被报告
将来,当整数数组索引包含超出边界值时,NumPy 将引发 IndexError,即使非索引维数的长度为 0。现在将发出 DeprecationWarning。此情况可能发生在数组先前为空时,或涉及空切片时:
代码语言:javascript复制arr1 = np.zeros((5, 0))
arr1[[20]]
arr2 = np.zeros((5, 5))
arr2[[20], :0]
以前,非空索引[20]
未被检查正确性。现在将被检查,导致弃用警告,这将转换为错误。这也适用于赋值。
(gh-15900)
mode
和searchside
的不精确匹配被弃用
以前,mode
和searchside
的不精确和不区分大小写的匹配是有效的输入,现在将产生 DeprecationWarning。例如,以下是现在已弃用并将产生 DeprecationWarning 的一些示例用法:
import numpy as np
arr = np.array([[3, 6, 6], [4, 5, 1]])
# mode: inexact match
np.ravel_multi_index(arr, (7, 6), mode="clap") # should be "clip"
# searchside: inexact match
np.searchsorted(arr[0], 4, side='random') # should be "right"
(gh-16056)
numpy.dual的弃用
模块numpy.dual已被弃用。不要从numpy.dual导入函数,而应直接从 NumPy 或 SciPy 导入函数。
(gh-16156)
outer
和ufunc.outer
弃用了矩阵
np.matrix
与outer
或通用的 ufunc outer 调用(如numpy.add.outer
)一起使用。以前,在这里将矩阵转换为数组。将来不会再这样做,需要手动将矩阵转换为数组。
(gh-16232)
进一步弃用数字式样式类型
剩余的数字样式类型代码Bytes0
、Str0
、Uint32
、Uint64
和Datetime64
已经被弃用。应该改为使用小写变体。对于字节和字符串,"S"
和"U"
是进一步的替代方案。
(gh-16554)
ndindex
的ndincr
方法已被弃用
从 NumPy 1.8 起,文档已警告不要使用此函数。使用next(it)
代替it.ndincr()
。
(gh-17233)
不定义__len__
和__getitem__
的 ArrayLike 对象
定义了__array__
、__array_interface__
或__array_struct__
协议之一但不是序列(通常通过__len__
和__getitem__
定义)的对象在未来进行数组强制转换时会表现不同。
当嵌套在序列中时,例如np.array([array_like])
,它们被处理为单个 Python 对象而不是数组。将来它们将表现相同于:
np.array([np.array(array_like)])
这种变化只在np.array(array_like)
不为 0-D 时才会产生影响。对此警告的解决方案可能取决于对象:
- 一些类数组可能期望新行为,用户可以忽略警告。对象可以选择将序列协议公开以选择接受新行为。
- 例如,
shapely
将允许使用line.coords
而不是np.asarray(line)
来转换为类似数组的对象。用户可以解决警告,或者在新约定可用时使用新约定。
不幸的是,只有调用np.array(array_like)
才能实现新行为。
如果您希望确保旧行为保持不变,请创建一个对象数组,然后显式填充它,例如:
代码语言:javascript复制arr = np.empty(3, dtype=object)
arr[:] = [array_like1, array_like2, array_like3]
这将确保 NumPy 知道不进入类数组并将其用作对象。
(gh-17973)
使用np.int
等内置类型的别名是不推荐的
长期以来,np.int
一直是内置int
的别名。这反复是新手困惑的原因,主要是出于历史原因。
这些别名已经被弃用。下表显示了已弃用的别名的完整列表,以及它们的确切含义。使用第一栏中的项目的第二栏中的内容将会产生相同的效果并消除弃用警告。
第三栏列出了可能偶尔更优的替代 NumPy 名称。另请参阅数据类型以获取更多细节。
弃用名称 | 等同于 | NumPy 标量类型名称 |
---|---|---|
numpy.bool | bool | numpy.bool_ |
numpy.int | int | numpy.int_(默认)、numpy.int64或numpy.int32 |
numpy.float | float | numpy.float64, numpy.float_, numpy.double (equivalent) |
numpy.complex | complex | numpy.complex128, numpy.complex_, numpy.cdouble (equivalent) |
numpy.object | object | numpy.object_ |
numpy.str | str | numpy.str_ |
numpy.long | int | numpy.int_ (C long), numpy.longlong (largest integer type) |
numpy.unicode | str | numpy.unicode_ |
对于绝大多数情况提供清晰的指导,对于类型bool
、object
、str
(和unicode
),使用简单版本更短、更清晰,通常是一个很好的替换。对于float
和complex
,如果您希望更明确地表达精度,可以使用float64
和complex128
。
对于np.int
,直接替换为np.int_
或int
也可以,不会改变行为,但精度仍然会取决于计算机和操作系统。如果您想更明确地查看当前使用情况,您有以下替代方案:
-
np.int64
或np.int32
来精确指定精度。这样可以确保结果不会依赖于计算机或操作系统。 -
np.int_
或int
(默认值),但请注意这取决于计算机和操作系统。 - C 类型:
np.cint
(int),np.int_
(long),np.longlong
。 -
np.intp
在 32 位机器上为 32 位,在 64 位机器上为 64 位。这可能是用于索引的最佳类型。
当与np.dtype(...)
或dtype=...
一起使用时,将其更改为上述提到的 NumPy 名称对输出没有影响。如果作为标量使用:
np.float(123)
改变它可能会微妙地改变结果。在这种情况下,Python 版本float(123)
或int(12.)
通常更可取,尽管 NumPy 版本可能在与 NumPy 数组的一致性方面很有用(例如,对于诸如除零之类的操作,NumPy 的行为有所不同)。
(gh-14882)
将shape=None
传递给具有非可选 shape 参数的函数已被弃用
之前,这是传递 shape=()
的别名。 这种弃用是由 C API 中的 PyArray_IntpConverter 发出的。 如果你的 API 打算支持传递 None
,则应在调用转换器之前检查 None
,以区分 None
和 ()
。
(gh-15886)
即使索引结果为空,也将报告索引错误
未来,当整数数组索引包含超出范围值时,NumPy 将引发 IndexError,即使非索引维度的长度为 0。 现在将会发出弃用警告。 当数组之前为空或涉及空切片时可能会发生这种情况:
代码语言:javascript复制arr1 = np.zeros((5, 0))
arr1[[20]]
arr2 = np.zeros((5, 5))
arr2[[20], :0]
以前不会检查非空索引 [20]
的正确性。 现在将进行检查,从而引发弃用警告,并将其转换为错误。 对赋值也适用。
(gh-15900)
mode
和 searchside
的不精确匹配已被弃用
对于 mode
和 searchside
的不精确和不区分大小写的匹配以前是有效的,现在将会产生弃用警告。 例如,以下是一些现已被弃用并将产生弃用警告的示例用法:
import numpy as np
arr = np.array([[3, 6, 6], [4, 5, 1]])
# mode: inexact match
np.ravel_multi_index(arr, (7, 6), mode="clap") # should be "clip"
# searchside: inexact match
np.searchsorted(arr[0], 4, side='random') # should be "right"
(gh-16056)
弃用了 numpy.dual
模块 numpy.dual 已弃用。 应该直接从 NumPy 或 SciPy 中导入函数,而不是从 numpy.dual 中导入。
(gh-16156)
outer
和 ufunc.outer
已弃用与矩阵相关的功能
np.matrix
与 outer
或 numpy.add.outer
等通用 ufunc 外部调用一起使用。 以前,这里的矩阵会被转换为数组。 未来将不再执行此操作,需要手动将矩阵转换为数组。
(gh-16232)
进一步弃用了数值风格类型
剩余的数值类型代码 Bytes0
、Str0
、Uint32
、Uint64
和 Datetime64
已弃用。 应改为使用小写变体。 对于字节和字符串,"S"
和 "U"
还是另选项。
(gh-16554)
ndindex
的 ndincr
方法已弃用
从 NumPy 1.8 开始,文档已经警告不要使用该函数。 对于 it.ndincr()
,应改为使用 next(it)
。
(gh-17233)
未定义 __len__
和 __getitem__
的 ArrayLike 对象
定义其中一个协议 __array__
、__array_interface__
或 __array_struct__
,但不是序列(通常通过具有 __len__
和 __getitem__
来定义)的对象,在数组强制转换期间将来会表现出不同的行为。
当嵌套在序列内部,比如 np.array([array_like])
,它们之前被处理为单个 Python 对象,而不是数组。 将来它们将表现为与以下完全相同的方式:
np.array([np.array(array_like)])
这个改变只会在np.array(array_like)
不是 0 维数组时发生作用。这个警告的解决方案可能取决于对象:
- 一些类似数组的对象可能期望新的行为,用户可以忽略警告。对象可以选择暴露序列协议以选择新的行为。
- 例如,
shapely
将允许使用line.coords
而不是np.asarray(line)
将其转换为类似数组的对象。用户可能会规避警告,或在可用时使用新约定。
不幸的是,只能通过调用np.array(array_like)
来使用新的行为。
如果您希望确保旧的行为保持不变,请创建一个对象数组,然后显式填充它,例如:
代码语言:javascript复制arr = np.empty(3, dtype=object)
arr[:] = [array_like1, array_like2, array_like3]
这将确保 NumPy 知道不要进入数组样式,而是将其作为对象使用。
(gh-17973)
未来的改变
数组不能使用子数组dtype
数组创建和转换将使用不同的逻辑,当dtype
是一个子数组dtype
时,如np.dtype("(2)i,")
。
对于这样的dtype
,以下行为是正确的:
res = np.array(arr, dtype)
res.dtype is not dtype
res.dtype is dtype.base
res.shape == arr.shape dtype.shape
但res
是依据以下逻辑填充的:
res = np.empty(arr.shape dtype.shape, dtype=dtype.base)
res[...] = arr
使用不正确的广播(并且通常会导致错误)。 以后,这将逐个元素转换,结果与以下相同:
代码语言:javascript复制res = np.array(arr, dtype=np.dtype(["f", dtype]))["f"]
正常情况下,可以用来选择新行为。
这个改变不会影响np.array(list, dtype="(2)i,")
,除非list
本身至少包含一个数组。特别地,对于元组列表,行为没有改变。
(gh-17596)
数组不能使用子数组dtype
数组创建和转换将使用不同的逻辑,当dtype
是一个子数组dtype
时,如np.dtype("(2)i,")
。
对于这样的dtype
,以下行为是正确的:
res = np.array(arr, dtype)
res.dtype is not dtype
res.dtype is dtype.base
res.shape == arr.shape dtype.shape
但res
是依据以下逻辑填充的:
res = np.empty(arr.shape dtype.shape, dtype=dtype.base)
res[...] = arr
使用不正确的广播(并且通常会导致错误)。 以后,这将逐个元素转换,结果与以下相同:
代码语言:javascript复制res = np.array(arr, dtype=np.dtype(["f", dtype]))["f"]
正常情况下,可以用来选择新行为。
这个改变不会影响np.array(list, dtype="(2)i,")
,除非list
本身至少包含一个数组。特别地,对于元组列表,行为没有改变。
(gh-17596)
过期的废弃
- 数字样式类型码
np.dtype("Complex64")
(使用大写拼写)的废弃期已过。"Complex64"
对应于"complex128"
,"Complex32"
对应于"complex64"
。 -
np.sctypeNA
和np.typeNA
的废弃期已过。二者已从公共 API 中删除。请改用np.typeDict
。 (gh-16554) -
np.ctypeslib.ctypes_load_library
的 14 年弃用期已到期。改用load_library
,它们是一样的。 (gh-17116)
金融函数已移除
根据 NEP 32 的规定,NumPy 1.20 版已删除了金融函数。已删除的函数包括fv
、ipmt
、irr
、mirr
、nper
、npv
、pmt
、ppmt
、pv
和rate
。这些函数可以在numpy_financial库中找到。
(gh-17067)
金融函数已移除
根据 NEP 32 的规定,NumPy 1.20 版已删除了金融函数。已删除的函数包括fv
、ipmt
、irr
、mirr
、nper
、npv
、pmt
、ppmt
、pv
和rate
。这些函数可以在numpy_financial库中找到。
(gh-17067)
兼容性说明
isinstance(dtype, np.dtype)
而不是type(dtype) is not np.dtype
NumPy dtypes 不再是np.dtype
的直接实例。可能使用了type(dtype) is np.dtype
的代码将始终返回False
,必须更新为使用正确的版本isinstance(dtype, np.dtype)
。
这个改变还影响了 C 端的宏PyArray_DescrCheck
,如果编译的 NumPy 版本旧于 1.16.6.如果代码使用此宏并希望编译为旧版本的 NumPy,必须替换该宏(另请参见 C API changes 部分)。
在与axis=None
连接时相同类型转换
当调用concatenate
时,如果带有axis=None
,则扁平数组将使用unsafe
进行类型转换。任何其他轴选择都使用“相同类型”。已弃用该不同的默认行为,将改为使用“相同类型”的类型转换。新的casting
关键字参数可用于保留旧的行为。
(gh-16134)
将 NumPy 标量添加到数组时进行类型转换
在创建或分配数组时,在所有相关情况下,NumPy 标量现在将被等同地转换为 NumPy 数组。特别是这会改变以前在某些情况下引发错误的行为:
代码语言:javascript复制np.array([np.float64(np.nan)], dtype=np.int64)
将会成功,并返回一个未定义的结果(通常是可能的最小整数)。这也影响了赋值:
代码语言:javascript复制arr[0] = np.float64(np.nan)
目前,NumPy 保留了以下行为:
代码语言:javascript复制np.array(np.float64(np.nan), dtype=np.int64)
以上更改不影响 Python 标量:
代码语言:javascript复制np.array([float("NaN")], dtype=np.int64)
不受影响(np.nan
是 Python 的float
,不是 NumPy 的)。与有符号整数不同,无符号整数不保留这种特殊情况,因为它们总是更像强制转换。以下代码不再引发错误:
np.array([np.float64(np.nan)], dtype=np.uint64)
为避免向后兼容性问题,此时仍支持从datetime64
标量到太短的字符串的赋值。这意味着现在可以成功执行np.asarray(np.datetime64("2020-10-10"), dtype="S5")
,而之前会失败。从长远来看,这可能会被弃用,或者允许不安全转换以使数组和标量的赋值行为保持一致。
当字符串和其他类型混合使用时,数组强制转换发生变化
当字符串和其他类型混合使用时,例如:
代码语言:javascript复制np.array(["string", np.float64(3.)], dtype="S")
结果将会改变,这可能会导致某些情况下字符串 dtype 的字符串更长。特别是,如果未提供dtype="S"
,任何数值都将导致一个足够长以容纳所有可能数值的字符串结果(例如,对于浮点数是“S32”)。请注意,当将非字符串转换为字符串时,应始终提供dtype="S"
。
如果提供了dtype="S"
,则结果将在很大程度上与以前相同,但 NumPy 标量(而不是 Python 浮点数,如1.0
)仍将强制统一字符串长度:
np.array([np.float64(3.)], dtype="S") # gives "S32"
np.array([3.0], dtype="S") # gives "S3"
以前的第一个版本产生了与第二个相同的结果。
数组转换重组
数组转换已经重组。一般情况下,这不应影响用户。在极为罕见的角落案例中,类数组对象被嵌套:
代码语言:javascript复制np.array([array_like1])
事情现在将更一致:
代码语言:javascript复制np.array([np.array(array_like1)])
这可能会微妙地改变某些糟糕定义的类数组的输出。其中一个例子是不匹配形状的类数组对象。在 NumPy 1.20 中,当一个类数组对象不是一个序列时会发出警告(但行为保持不变,请参阅弃用)。如果一个类数组对象也是一个序列(定义了__getitem__
和__len__
),NumPy 现在只会使用__array__
、__array_interface__
或__array_struct__
给出的结果。当(嵌套的)序列描述不同形状时,这将导致差异。
(gh-16200)
写入numpy.broadcast_arrays
的结果将导出只读缓冲区
在 NumPy 1.17 中,numpy.broadcast_arrays
在写入生成的数组时开始发出警告。当通过缓冲区接口使用数组时(例如memoryview(arr)
),此警告被跳过。现在,当两个协议__array_interface__
和__array_struct__
返回只读缓冲区时,将发生相同的情况,而不是发出警告。
(gh-16350)
数字风格的类型名称已从类型字典中移除
为了与对 np.dtype("Complex64")
和其他数值型(大写)类型的停用保持同步,这些类型已从 np.sctypeDict
和 np.typeDict
中移除。你应该使用小写版本。注意,"Complex64"
对应 "complex128"
,"Complex32"
对应 "complex64"
。numpy 风格(新)版本表示完整大小而不是实部/虚部的大小。
(gh-16554)
operator.concat
函数现在为数组参数引发 TypeError
以前的行为是退回到加法,并添加这两个数组,这被认为是一个不符合预期的行为对于一个连接函数。
(gh-16570)
nickname
属性从 ABCPolyBase 中移除
抽象属性 nickname
从 ABCPolyBase
中移除,因为在派生的方便类中不再使用。这可能会影响那些从 ABCPolyBase
派生类并覆盖了表示和显示方法的用户,例如 __str__
,__repr__
,_repr_latex
,等等。
(gh-16589)
float->timedelta
和 uint64->timedelta
增强现在会引发 TypeError
浮点数和时间增强现在一致地引发 TypeError。np.promote_types("float32", "m8")
现在与 np.promote_types("m8", "float32")
一致,并且都会引发 TypeError。以前,np.promote_types("float32", "m8")
返回 "m8"
,被认为是一个错误。
Uint64 和时间增强现在一致地引发 TypeError。np.promote_types("uint64", "m8")
现在与 np.promote_types("m8", "uint64")
一致,并且都会引发 TypeError。以前,np.promote_types("uint64", "m8")
返回 "m8"
,被认为是一个错误。
(gh-16592)
numpy.genfromtxt
现在正确地解包结构化数组
以前,numpy.genfromtxt
在使用unpack=True
并且在dtype
参数传递了结构化数据类型(或者推断了结构化数据类型为空)时无法正确解包。例如:
>>> data = StringIO("21 58.0n35 72.0")
>>> np.genfromtxt(data, dtype=None, unpack=True)
array([(21, 58.), (35, 72.)], dtype=[('f0', '<i8'), ('f1', '<f8')])
现在结构化数组将正确解包为数组列表,每个列一个:
代码语言:javascript复制>>> np.genfromtxt(data, dtype=None, unpack=True)
[array([21, 35]), array([58., 72.])]
(gh-16650)
mgrid
,r_
等对于非默认精度输入一致地返回正确的输出
以前,np.mgrid[np.float32(0.1):np.float32(0.35):np.float32(0.1),]
和np.r_[0:10:np.complex64(3j)]
无法返回有意义的输出。 此错误可能影响到当使用默认的float64
和complex128
以及等效的 Python 类型以外的 dtype 时,mgrid
,ogrid
,r_
和c_
。 这些方法已修复以正确处理不同的精度。
(gh-16815)
具有不匹配形状的布尔数组索引现在会正确返回IndexError
以前,如果布尔数组索引与索引数组的大小匹配但形状不匹配,则在某些情况下会出现错误。 在其他情况下,它会出现一个错误,但错误消息不是IndexError
而是有关广播的ValueError
。
例如,以下不正确地给出了ValueError: operands could not be broadcast together with shapes (2,2) (1,4)
:
np.empty((2, 2))[np.array([[True, False, False, False]])]
以下不正确地返回了array([], dtype=float64)
:
np.empty((2, 2))[np.array([[False, False, False, False]])]
现在都正确返回IndexError: boolean index did not match indexed array along dimension 0; dimension is 2 but corresponding boolean dimension is 1
。
(gh-17010)
转换错误中断迭代
当转换值时进行迭代,错误可能比以前更早地停止迭代。 在任何情况下,失败的转换操作总是返回未定义的部分结果。 对于使用NpyIter
C-API 的用户,这样的转换错误现在将导致*iternext()*函数返回 0,从而中断迭代。 目前,没有 API 直接检测此类错误。 必须检查PyErr_Occurred()
,这可能与NpyIter_Reset
结合使用会有问题。 这些问题一直存在,但如果用户需要,可以添加新的 API。
(gh-17029)
f2py 生成的代码可能返回 Unicode 而不是字节字符串
先前由 f2py 生成的代码返回的一些字节字符串现在可能是 Unicode 字符串。 这是由不断进行的 Python2 -> Python3 清理造成的。
(gh-17068)
__array_interface__["data"]
元组的第一个元素必须是整数
多年来,这一直是记录的接口,但仍然有代码会接受指针地址的字节字符串表示。 该代码已被移除,现在传递字节字符串作为地址将引发错误。
(gh-17241)
poly1d 尊重所有零参数的 dtype
以前,使用全零系数构造poly1d
的实例会将系数转换为np.float64
。这会影响内部构造poly1d
实例的方法的输出 dtype,比如np.polymul
。
(gh-17577)
swig 的 numpy.i 文件仅适用于 Python 3。
Python 2.7 C-API 函数的使用已更新为仅适用于 Python 3。需要旧版本的用户应该从旧版本的 NumPy 获取它。
(gh-17580)
在np.array
中发现虚 dtype
在使用np.array(..., dtype="V")
、arr.astype("V")
和类似方法时,现在将正确引发 TypeError,除非所有元素具有相同的虚长度。示例如下:
np.array([b"1", b"12"], dtype="V")
以前,返回的数组的 dtype 为"V2"
, 无法真实地表示b"1"
。
(gh-17706)
isinstance(dtype, np.dtype)
而不是type(dtype) is not np.dtype
NumPy dtypes 不再是np.dtype
的直接实例。可能使用了type(dtype) is np.dtype
的代码将始终返回False
,并且必须更新为使用正确的版本isinstance(dtype, np.dtype)
。
这个更改还影响了对 C 端宏PyArray_DescrCheck
的编译,如果编译的 NumPy 版本旧于 1.16.6. 如果代码使用了此宏,并希望针对旧版本的 NumPy 进行编译,它必须替换该宏(另见 C API changes 部分)。
与axis=None
连接时相同类型的转换
当用axis=None
调用concatenate
时,扁平化的数组将使用unsafe
进行类型转换。任何其他轴选择都使用“same kind”。不建议使用不同的默认设置,而是使用“same kind”转换。可以使用新的casting
关键字参数来保留旧的行为。
(gh-16134)
将赋给数组时,NumPy 标量将被转换
在创建或赋值数组时,在所有相关的情况下,NumPy 标量现在会被转换为 NumPy 数组。特别是这改变了以前引发错误的一些情况的行为:
代码语言:javascript复制np.array([np.float64(np.nan)], dtype=np.int64)
将成功并返回一个未定义的结果(通常是可能的最小整数)。这也影响了赋值:
代码语言:javascript复制arr[0] = np.float64(np.nan)
目前,NumPy 保留了以下行为:
代码语言:javascript复制np.array(np.float64(np.nan), dtype=np.int64)
上述更改不影响 Python 标量:
代码语言:javascript复制np.array([float("NaN")], dtype=np.int64)
保持不变(np.nan
是 Python 的float
,而不是 NumPy 的)。与有符号整数不同,无符号整数不保留此特殊情况,因为它们一直更像转换。以下代码不再引发错误:
np.array([np.float64(np.nan)], dtype=np.uint64)
为了避免向后兼容性问题,目前从datetime64
标量赋值给长度过短的字符串仍然是可行的。这意味着np.asarray(np.datetime64("2020-10-10"), dtype="S5")
现在能成功,而以前是失败的。从长远来看,这可能会被弃用,或者允许不安全的转换以使数组和标量的赋值行为一致。
当混合字符串和其他类型时,数组强制转换更改
当字符串和其他类型混合时,例如:
代码语言:javascript复制np.array(["string", np.float64(3.)], dtype="S")
结果将会改变,这可能会导致某些情况下长字符串的字符串数据类型。特别是,如果没有提供dtype="S"
,任何数值都将导致足够长的字符串结果,以容纳所有可能的数值(比如对于浮点数是“S32”)。请注意,当将非字符串转换为字符串时,应始终提供dtype="S"
。
如果提供了 dtype="S"
,结果将在很大程度上与以前相同,但 NumPy 标量(不是 Python 的浮点数,比如1.0
),仍将强制执行统一的字符串长度:
np.array([np.float64(3.)], dtype="S") # gives "S32"
np.array([3.0], dtype="S") # gives "S3"
以前的第一个版本给出了与第二个相同的结果。
数组强制转换重构
数组强制转换已经重新构建。一般情况下,这不应该影响用户。在极为罕见的角落情况中,数组样式被嵌套:
代码语言:javascript复制np.array([array_like1])
现在的情况将更加一致:
代码语言:javascript复制np.array([np.array(array_like1)])
这可能会微妙地改变一些糟糕定义的数组样式的输出。其中一个例子是不是序列的数组样式对象。在 NumPy 1.20 中,当一个类似数组的对象不是序列时会发出警告(但是行为保持不变,参见弃用)。如果一个类似数组的对象也是序列(定义了 __getitem__
和 __len__
),NumPy 现在将只使用__array__
、__array_interface__
或__array_struct__
给出的结果。当(嵌套的)序列描述不同的形状时,这将导致不同的结果。
(gh-16200)
对于 numpy.broadcast_arrays
的结果进行写入将导致只读缓冲区的导出。
在 NumPy 1.17 中,numpy.broadcast_arrays
在写入结果数组时开始发出警告。当通过缓冲区接口使用数组时(例如 memoryview(arr)
),该警告被跳过。现在两个协议__array_interface__
和__array_struct__
返回只读缓冲区而不是发出警告。
(gh-16350)
数值样式的类型名称已从类型字典中删除。
为了与np.dtype("Complex64")
和其他数字风格(大写)类型的弃用保持同步,这些类型已从np.sctypeDict
和np.typeDict
中移除。您应该改用小写版本。请注意,"Complex64"
对应于"complex128"
, "Complex32"
对应于"complex64"
。numpy 风格(新版本)的类型代表的是完整大小,而不是实部/虚部的大小。
(gh-16554)
operator.concat
函数现在对数组参数会引发 TypeError
之前的行为是退回到加法并添加两个数组,这被认为是一个连接函数的意外行为。
(gh-16570)
从 ABCPolyBase 中删除了nickname
属性
抽象属性nickname
已从ABCPolyBase
中移除,因为它在派生的便利类中不再使用。这可能会影响那些从ABCPolyBase
派生类并重写表示和显示方法(例如__str__
,__repr__
,_repr_latex
等)的用户。
(gh-16589)
float->timedelta
和uint64->timedelta
的提升都会引发 TypeError
浮点数和时间间隔一致提升会引发 TypeError。np.promote_types("float32", "m8")
现在和以前一样都会触发一个 TypeError。之前,np.promote_types("float32", "m8")
返回"m8"
被认为是一个 bug。
Uint64 和时间间隔的提升一致会引发 TypeError。np.promote_types("uint64", "m8")
现在和以前一样都会触发一个 TypeError。之前,np.promote_types("uint64", "m8")
返回"m8"
被认为是一个 bug。
(gh-16592)
numpy.genfromtxt
现在正确地解包结构化数组
之前,当以unpack=True
调用numpy.genfromtxt
,并且将结构化数据类型传递给dtype
参数(或者传递dtype=None
并且推断出结构化数据类型)时,numpy.genfromtxt
会失败解包。例如:
>>> data = StringIO("21 58.0n35 72.0")
>>> np.genfromtxt(data, dtype=None, unpack=True)
array([(21, 58.), (35, 72.)], dtype=[('f0', '<i8'), ('f1', '<f8')])
结构化数组现在会正确地解包为一个数组列表,每列一个数组:
代码语言:javascript复制>>> np.genfromtxt(data, dtype=None, unpack=True)
[array([21, 35]), array([58., 72.])]
(gh-16650)
mgrid
,r_
等对于非默认精度输入一直返回正确的输出
以前,np.mgrid[np.float32(0.1):np.float32(0.35):np.float32(0.1),]
和 np.r_[0:10:np.complex64(3j)]
未能返回有意义的输出。这个错误可能会影响 mgrid
, ogrid
, r_
, 和 c_
在使用除默认的 float64
和 complex128
和对应的 Python 类型以外的精度输入时。方法已被修复以正确处理不同的精度。
(gh-16815)
具有不匹配形状的布尔数组索引现在会适当返回 IndexError
以前,如果布尔数组索引与索引数组的大小匹配但不能匹配形状,则在某些情况下会被错误地允许。在其他情况下,它会产生一个错误,但该错误是关于广播而不是正确的 IndexError
的错误 ValueError
。
例如,以下会不正确地返回 ValueError: operands could not be broadcast together with shapes (2,2) (1,4)
:
np.empty((2, 2))[np.array([[True, False, False, False]])]
以下会返回 array([], dtype=float64)
,之前是不正确的:
np.empty((2, 2))[np.array([[False, False, False, False]])]
现在都会适当返回 IndexError:布尔索引与维度 0 沿着相应的布尔维度是 1 的索引数组不匹配
(gh-17010)
抛出错误中断迭代
在进行值转换时进行迭代时,错误可能比以前更早地停止迭代。无论如何,失败的转换操作总是返回未定义的部分结果。现在这些可能会更加不确定和不完整。对于使用 NpyIter
C-API 的用户,这样的转换错误现在会导致 iternext() 函数返回 0,从而中止迭代。当前没有 API 直接检测此类错误。必须检查 PyErr_Occurred()
,这可能与 NpyIter_Reset
结合使用时会有问题。这些问题一直存在,但如果用户需要的话,可以添加新的 API。
(gh-17029)
f2py 生成的代码可能以 unicode 字符串而不是字节字符串返回
以前由 f2py 生成的代码返回的一些字节字符串现在可能是 Unicode 字符串。这是由于不断进行的 Python2 -> Python3 清理造成的。
(gh-17068)
__array_interface__["data"]
元组的第一个元素必须是整数
这已经是多年来的文档接口,但仍有代码会接受指针地址的字节字符串表示。现在已经删除了这些代码,以字节字符串传递地址现在会引发错误。
(gh-17241)
poly1d 会尊重全零参数的 dtype
以前,构造一个具有全零系数的 poly1d
实例将会将系数转换为 np.float64
。这将影响内部构造 poly1d
实例的方法的输出 dtype,例如 np.polymul
。
(gh-17577)
swig 的 numpy.i 文件仅适用于 Python 3。
Python 2.7 C-API 函数的使用已经更新为仅适用于 Python 3。需要旧版本的用户应该从旧版本的 NumPy 中获取它。
(gh-17580)
np.array
中的 void dtype 发现
在使用 np.array(..., dtype="V")
、arr.astype("V")
等调用中,除非所有元素具有相同的 void 长度,否则将会正确地引发 TypeError。例如:
np.array([b"1", b"12"], dtype="V")
以前返回的数组具有 dtype "V2"
,无法忠实地表示 b"1"
。
(gh-17706)
C API 更改
PyArray_DescrCheck
宏已经修改
自 NumPy 1.16.6 起,PyArray_DescrCheck
宏已经更新为:
#define PyArray_DescrCheck(op) PyObject_TypeCheck(op, &PyArrayDescr_Type)
从 NumPy 1.20 开始,针对较早版本编译的代码将与 NumPy 1.20 不兼容。修复方法为要么针对 1.16.6 编译(如果你希望支持的最旧版本为 NumPy 1.16),要么手动内联宏,并将其替换为新定义:
代码语言:javascript复制PyObject_TypeCheck(op, &PyArrayDescr_Type)
这样就与所有 NumPy 版本兼容。
np.ndarray
和 np.void_
的大小已经改变
PyArrayObject
和 PyVoidScalarObject
结构的大小已经改变。以下头文件定义已被移除:
#define NPY_SIZEOF_PYARRAYOBJECT (sizeof(PyArrayObject_fields))
由于大小不能被视为编译时常量:它将会因 NumPy 的不同运行时版本而发生变化。
最有可能相关的用法是在 C 中编写的潜在子类,必须重新编译并更新。有关详细信息,请参阅 PyArrayObject
的文档,并且如果你受到这项更改的影响,则请联系 NumPy 开发人员。
NumPy 将尝试给出一个优雅的错误,但是一个期望固定结构大小的程序可能会有未定义的行为,并且很可能会崩溃。
(gh-16938)
PyArray_DescrCheck
宏已经修改
自 NumPy 1.16.6 起,PyArray_DescrCheck
宏已经更新为:
#define PyArray_DescrCheck(op) PyObject_TypeCheck(op, &PyArrayDescr_Type)
从 NumPy 1.20 开始,针对较早版本编译的代码将与 NumPy 1.20 不兼容。修复方法为要么针对 1.16.6 编译(如果你希望支持的最旧版本为 NumPy 1.16),要么手动内联宏,并将其替换为新定义:
代码语言:javascript复制PyObject_TypeCheck(op, &PyArrayDescr_Type)
这样就与所有 NumPy 版本兼容。
np.ndarray
和 np.void_
的大小已经改变
PyArrayObject
和 PyVoidScalarObject
结构的大小已经改变。以下头文件定义已被移除:
#define NPY_SIZEOF_PYARRAYOBJECT (sizeof(PyArrayObject_fields))
由于大小不能被视为编译时常量:它将会因 NumPy 的不同运行时版本而发生变化。
最可能涉及的是以 C 编写的潜在子类,它们将需要重新编译并应进行更新。有关更多详细信息,请参阅 PyArrayObject
的文档,并在受此更改影响时与 NumPy 开发人员联系。
NumPy 将尝试给出一个优雅的错误,但是一个期望固定结构大小的程序可能会有未定义的行为,并可能崩溃。
(gh-16938)
新功能
where
关键字参数适用于 numpy.all
和 numpy.any
函数。
添加了关键字参数 where
,允许仅在 all
和 any
的布尔求值中考虑指定的元素或子轴。这个新关键字可在 numpy
直接使用或在 numpy.ndarray
的方法中使用。
任何可广播布尔数组或标量都可以设置为 where
。如果用户未设置 where
,它默认为 True
,用于对数组中的所有元素进行函数求值。示例可在函数的文档中找到。
where
关键字参数适用于 numpy
函数 mean
、std
、var
。
添加了关键字参数 where
,允许仅在计算 mean
、std
和 var
时限制作用范围至部分元素。它可以通过 numpy
直接使用,也可在 numpy.ndarray
的方法中使用。
任何可广播布尔数组或标量都可以设置为 where
。如果用户未设置 where
,它默认为 True
,用于对数组中的所有元素进行函数求值。示例可在函数的文档中找到。
(gh-15852)
norm=backward
、forward
关键字选项适用于 numpy.fft
函数。
添加了关键字参数选项 norm=backward
,它作为 None
的别名,并且充当默认选项;使用它会使直接变换不缩放,而逆变换缩放 1/n
。
使用新的关键字参数选项 norm=forward
会使直接变换缩放 1/n
,逆变换不缩放(即与默认选项 norm=backward
完全相反)。
(gh-16476)
NumPy 现在具有类型。
为 NumPy 的大部分内容添加了类型注解。还有一个新的 numpy.typing
模块,其中包含对终端用户有用的类型。目前可用的类型有
-
ArrayLike
:适用于可转换为数组的对象。 -
DtypeLike
:适用于可转换为 dtype 的对象。
(gh-16515)
在运行时可以访问 numpy.typing
。
现在可以在运行时导入 numpy.typing
中的类型。类似下面的代码现在可以正常工作:
from numpy.typing import ArrayLike
x: ArrayLike = [1, 2, 3, 4]
(gh-16558)
对于由 f2py 生成的模块,新增了 __f2py_numpy_version__
属性。
由于 f2py 与 NumPy 一起发布,__f2py_numpy_version__
提供了追踪用于生成模块的 f2py 版本的方法。
(gh-16594)
通过 runtests.py 可以运行mypy
测试。
目前,配置 NumPy 存根运行 mypy 需要:
- 安装 NumPy
- 将源目录添加到 MYPYPATH 并链接到
mypy.ini
这两个选项都有点不方便,因此在 runtests 中添加一个--mypy
选项,可处理设置。这也对任何类型代码生成会很有用,因为它将确保在类型检查之前构建项目。
(gh-17123)
用户定义的 BLAS/LAPACK 检测顺序的否定
distutils
允许在确定 BLAS/LAPACK 库时否定库。这可用于从库解析阶段中删除项目,例如,可以这样禁止 NetLIB 库:
NPY_BLAS_ORDER='^blas' NPY_LAPACK_ORDER='^lapack' python setup.py build
这将使用任何加速库。
(gh-17219)
允许将优化参数传递给 asv build
现在,在使用--bench-compare
参数时,可以向 ASV 构建传递-j
、--cpu-baseline
、--cpu-dispatch
和--disable-optimization
标志。
(gh-17284)
现在支持 NVIDIA HPC SDK nvfortran 编译器
支持 nvfortran 编译器,添加了 pgfortran 的版本。
(gh-17344)
为cov
和corrcoef
的dtype
选项
现在为numpy.cov
和numpy.corrcoef
提供了dtype
选项。该选项指定返回结果的数据类型。默认情况下,这些函数仍然返回一个numpy.float64
结果。
(gh-17456)
numpy.all
和numpy.any
函数的where
关键字参数
关键字参数where
被添加,允许在布尔运算中的all
和any
中仅考虑数组中的指定元素或子轴。这个新关键字可以通过numpy
的all
和any
函数直接使用,也可以在numpy.ndarray
的方法中使用。
任何可广播的布尔数组或标量都可以被设置为where
。如果用户未设置where
,那么默认为True
,以评估数组中的所有元素的函数。文档中提供了示例。
numpy
函数mean
、std
、var
的where
关键字参数
关键字参数where
被添加,允许将mean
、std
和var
的计算范围限制在元素的子集中。这个关键字既可以通过numpy
直接使用,也可以在numpy.ndarray
的方法中使用。
任何可广播的布尔数组或标量都可以设置为 where
。 如果用户没有设置 where
,则默认为 True
,以评估数组中所有元素的函数。 在函数的文档中给出了示例。
(gh-15852)
norm=backward
,forward
关键字选项用于 numpy.fft
函数
关键字参数选项 norm=backward
被添加为 None
的别名,并作为默认选项;使用它会直接将变换不缩放,反变换缩放为 1/n
。
使用新的关键字参数选项 norm=forward
会使直接变换缩放为 1/n
,而反变换不缩放(即与默认选项 norm=backward
完全相反)。
(gh-16476)
NumPy 现在是有类型的
对 NumPy 的大部分部分添加了类型注释。 还有一个新的 numpy.typing
模块,其中包含对最终用户有用的类型。 目前可用的类型是
-
ArrayLike
:对于可以强制转换为数组的对象 -
DtypeLike
:对于可以强制转换为 dtype 的对象
(gh-16515)
numpy.typing
可以在运行时访问
现在可以在运行时导入 numpy.typing
中的类型。 像下面的代码现在可以工作:
from numpy.typing import ArrayLike
x: ArrayLike = [1, 2, 3, 4]
(gh-16558)
f2py 生成模块的新 __f2py_numpy_version__
属性。
因为 f2py 与 NumPy 一起发布,__f2py_numpy_version__
提供了一种跟踪 f2py 用于生成模块的版本的方式。
(gh-16594)
可以通过 runtests.py 运行 mypy
测试
当前运行带有 NumPy 存根配置的 mypy 需要:
- 安装 NumPy
- 将源目录添加到 MYPYPATH 并链接到
mypy.ini
两个选项都有点不方便,因此添加一个 --mypy
选项来运行测试,该选项可以处理设置。 这对于将来的任何类型代码生成也很有用,因为它将确保在类型检查之前构建项目。
(gh-17123)
用户定义的 BLAS/LAPACK 检测顺序的否定
distutils
允许在确定 BLAS/LAPACK 库时否定库。 这可以用于从库解析阶段中删除一个项目,即不允许使用 NetLIB 库可以这样做:
NPY_BLAS_ORDER='^blas' NPY_LAPACK_ORDER='^lapack' python setup.py build
这将使用任何加速库之一。
(gh-17219)
允许将优化参数传递给 asv build
当使用 --bench-compare
参数时,现在可以向 ASV 构建传递 -j
,--cpu-baseline
,--cpu-dispatch
和 --disable-optimization
标志。
(gh-17284)
现在支持 NVIDIA HPC SDK nvfortran 编译器
支持 nvfortran 编译器,这是 pgfortran 的一个版本,已经添加。
(gh-17344)
cov
和 corrcoef
的 dtype
选项
numpy.cov
和 numpy.corrcoef
现在支持 dtype
选项。它指定返回结果应具有的数据类型。默认情况下,这些函数仍返回一个 numpy.float64
结果。
(gh-17456)
改进
提高多项式的字符串表示(__str__
)
所有六种多项式类型在 numpy.polynomial
中的字符串表示(__str__
)已更新为以数学表达式而不是系数数组来表示多项式。多项式表达式的包内格式可用 - 一种使用上下标的 Unicode 字符,另一种仅使用 ASCII 字符。
(gh-15666)
删除 Accelerate 库作为 LAPACK 库的候选项
Apple 不再支持 Accelerate。移除它。
(gh-15759)
包含多行对象的对象数组具有更可读的 repr
如果对象数组的元素包含换行符的 repr
,则包装的行将按列对齐。特别是,这改善了嵌套数组的 repr
:
>>> np.array([np.eye(2), np.eye(3)], dtype=object)
array([array([[1., 0.],
[0., 1.]]),
array([[1., 0., 0.],
[0., 1., 0.],
[0., 0., 1.]])], dtype=object)
(gh-15997)
concatenate 支持提供输出 dtype
在 concatenate
中添加了通过关键字参数提供输出 dtype
和 casting
的支持。dtype
参数不能与 out
参数同时提供。
(gh-16134)
f2py 回调函数是线程安全的
f2py 中的回调函数现在是线程安全的。
(gh-16519)
numpy.core.records.fromfile
现在支持文件类对象。
numpy.rec.fromfile
现在可以使用文件类对象,例如 io.BytesIO
(gh-16675)
在 AIX 上添加了 distutils 的 RPATH 支持
这使得 SciPy 可以在 AIX 上构建。
(gh-16710)
使用命令行参数指定的 f90 编译器
Fortran Portland Group 编译器的编译器命令选择在 numpy.distutils.fcompiler
中已更改。这仅影响链接命令。这会强制使用命令行选项提供的可执行文件(如果提供的话),而不是 pgfortran 可执行文件。如果没有将可执行文件提供给命令行选项,则默认使用 pgf90 可执行文件,根据 PGI 文档,它是 pgfortran 的别名。
(gh-16730)
为 Cython 3.0 及更高版本添加了 NumPy 声明
Cython 3.0 的 pxd 声明得到改进,避免使用废弃的 NumPy C-API 功能。使用 Cython 3.0 构建的扩展模块现在可以设置 C 宏 NPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION
,以避免使用废弃的 API 而引起 C 编译器警告。
(gh-16986)
使窗口函数完全对称
确保 NumPy 提供的窗口函数是对称的。以前由于数值精度而出现对称性偏差,现在通过更好的计算排列避免了这种情况。
(gh-17195)
为多项式(__str__
)改进字符串表示
numpy.polynomial
中的全部六种多项式类型的字符串表示(__str__
)已更新,以给出多项式作为数学表达式,而不是系数数组。有两种全局格式可用于多项式表达式 - 一种使用上标和下标的 Unicode 字符,另一种仅使用 ASCII 字符。
(gh-15666)
移除 Accelerate 库作为 LAPACK 库的候选项
Apple 不再支持 Accelerate。移除它。
(gh-15759)
包含多行对象的对象数组具有更可读的repr
如果对象数组的元素具有包含换行符的 repr
,那么包装的行将按列对齐。显著地,这会改善嵌套数组的repr
。
>>> np.array([np.eye(2), np.eye(3)], dtype=object)
array([array([[1., 0.],
[0., 1.]]),
array([[1., 0., 0.],
[0., 1., 0.],
[0., 0., 1.]])], dtype=object)
(gh-15997)
concatenate 支持提供输出 dtype
在concatenate
中添加了支持,以使用关键字参数提供输出 dtype
和 casting
。dtype
参数不能与out
同时提供。
(gh-16134)
线程安全的 f2py 回调函数
f2py 中的回调函数现在是线程安全的
(gh-16519)
numpy.core.records.fromfile
现在支持类文件对象
numpy.rec.fromfile
现在可以使用类文件的对象,例如io.BytesIO
(gh-16675)
在 AIX 上添加了对 distutils 的 RPATH 支持
这允许在 AIX 上构建 SciPy。
(gh-16710)
使用由命令行参数指定的 f90 编译器
更改 Fortran Portland Group Compiler 的编译器命令选择在numpy.distutils.fcompiler
中。这仅影响链接命令。这强制使用由命令行选项提供的可执行文件(如果提供)而不是 pgfortran 可执行文件。如果未向命令行选项提供可执行文件,则默认为 pgf90 可执行文件,这是根据 PGI 文档的别名。
(gh-16730)
为 Cython 3.0 及更高版本增加 NumPy 声明
对 Cython 3.0 的 pxd 声明进行了改进,以避免使用已弃用的 NumPy C-API 功能。使用 Cython 3.0 构建的扩展模块现在可以设置 C 宏NPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION
,以避免有关已弃用 API 使用的 C 编译器警告。
(gh-16986)
使窗口函数完全对称
确保 NumPy 提供的窗口函数是对称的。以前由于数值精度而导致对称性的小偏差现在通过更好地安排计算而得以避免。
(gh-17195)
性能改进和更改
启用多平台 SIMD 编译器优化
为 NumPy 基础设施进行一系列改进,以为NEP-38铺平道路,摘要如下:
- 新建构建参数
-
--cpu-baseline
用于指定所需优化的最小集,默认值为min
,提供了可以安全运行在广泛用户平台上的最少 CPU 特性。 -
--cpu-dispatch
用于指定额外优化的分配集,默认值为max -xop -fma4
,它启用了除 AMD 传统特性外的所有 CPU 特性。 -
--disable-optimization
以明确禁用整个新的改进,它还添加了一个名为NPY_DISABLE_OPTIMIZATION
的新C编译器#定义,可以用作任何 SIMD 代码的守卫。
-
- 高级 CPU 分发器
基于 Python/Numpy distutils 架构的灵活跨架构 CPU 调度程序,支持所有常见编译器和广泛的 CPU 特性。
新的调度程序需要特殊的文件扩展名
*.dispatch.c
来标记可调度的C源。这些源代码有能力多次编译,这样每个编译过程都代表一定的 CPU 特性,并提供影响代码路径的不同#定义和标志。 - 新生成的自动生成的 C 头文件
core/src/common/_cpu_dispatch.h
该头文件是由 distutils 模块ccompiler_opt
生成的,并包含所有通过命令参数‘–cpu-baseline’和‘–cpu-dispatch’配置的指令集的 #definitions 和 headers。 - 新的 C 头文件
core/src/common/npy_cpu_dispatch.h
该头文件包含了整个 CPU 调度过程所需的所有实用工具,它还可以被视为将新基础设施工作与 NumPy CPU 运行时检测连接起来的桥梁。 - 添加新属性到 NumPy umath 模块(Python 级别)
-
__cpu_baseline__
这是一个列表,包含了编译器和平台根据指定的值对命令参数‘–cpu-baseline’支持的最小一组所需优化。 -
__cpu_dispatch__
这是一个列表,包含了编译器和平台根据指定的值对命令参数‘–cpu-dispatch’支持的分派的一组额外优化。
-
- 在 PytestTester 运行时打印支持的 CPU 功能
(gh-13516)
启用多平台 SIMD 编译器优化
一系列针对 NumPy 基础设施的改进,为 NEP-38 铺平道路,总结如下:
- 新的构建参数
-
--cpu-baseline
用于指定所需优化的最小集合,默认值为min
,可安全运行在广泛用户平台上的最低 CPU 功能。 -
--cpu-dispatch
用于指定分派的一组额外优化,其默认值为max -xop -fma4
,这使得除 AMD 传统功能之外的所有 CPU 功能均可使用。 -
--disable-optimization
明确禁用所有新的改进,它还添加了一个名为NPY_DISABLE_OPTIMIZATION
的新 C 编译器 #definition,这可以作为任何 SIMD 代码的守卫。
-
- 高级 CPU 调度程序
基于 Python/Numpy distutils 构建的灵活的跨体系结构 CPU 调度程序,支持所有常见编译器,具有广泛的 CPU 功能。
新的调度程序需要特定的文件扩展名
*.dispatch.c
来标记可调度的 C 源文件。这些源文件有能力被多次编译,以便每次编译过程代表某些 CPU 功能,并提供影响代码路径的不同 #definitions 和 flags。 - 新的自动生成的 C 头文件
core/src/common/_cpu_dispatch.h
该头文件是由 distutils 模块ccompiler_opt
生成的,并包含所有通过命令参数‘–cpu-baseline’和‘–cpu-dispatch’配置的指令集的 #definitions 和 headers。 - 新的 C 头文件
core/src/common/npy_cpu_dispatch.h
该头文件包含了整个 CPU 调度过程所需的所有实用工具,它还可以被视为将新基础设施工作与 NumPy CPU 运行时检测连接起来的桥梁。 - 添加新属性到 NumPy umath 模块(Python 级别)
-
__cpu_baseline__
列出了由命令参数‘–cpu-baseline’中指定的最小值来支持编译器和平台的所需优化的最小集。 -
__cpu_dispatch__
列出了由命令参数‘–cpu-dispatch’中指定的所支持的编译器和平台的附加优化的调度集。
-
- 运行 PytestTester 时打印支持的 CPU 功能
(gh-13516)
变更
更改 divmod(1., 0.)
及相关函数的行为
更改还确保了不同的编译器版本对这些操作中的 nan 或 inf 使用具有相同的行为。这以前取决于编译器,现在我们强制无效和除以零标志,使结果在不同编译器上相同。例如,gcc-5、gcc-8 或 gcc-9 现在会得到相同的行为。更改如下表所示:
新行为总结
运算符 | 旧警告 | 新警告 | 旧结果 | 新结果 | 在 MacOS 上有效 |
---|---|---|---|---|---|
np.divmod(1.0, 0.0) | 无效 | 无效 and 除以零 | nan、nan | inf、nan | 是 |
np.fmod(1.0, 0.0) | 无效 | 无效 | nan | nan | 不? 是 |
np.floor_divide(1.0, 0.0) | 无效 | 除以零 | nan | inf | 是 |
np.remainder(1.0, 0.0) | 无效 | 无效 | nan | nan | 是 |
(gh-16161)
np.linspace
在整数上现在使用 floor
当在 numpy.linspace
中使用 int
数据类型时,以前的浮点值会向零舍入。现在改为使用 numpy.floor
,它向 -inf
舍入。这会改变负数的结果。例如,以前的结果如下:
>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -2, -1, -1, 0, 0, 0, 1])
现在的结果是:
代码语言:javascript复制>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -3, -2, -2, -1, -1, 0, 1])
以前的结果仍然可以得到:
代码语言:javascript复制>>> np.linspace(-3, 1, 8).astype(int)
array([-3, -2, -1, -1, 0, 0, 0, 1])
(gh-16841)
更改 divmod(1., 0.)
及相关函数的行为
更改还确保了不同的编译器版本对这些操作中的 nan 或 inf 使用具有相同的行为。这以前取决于编译器,现在我们强制无效和除以零标志,使结果在不同编译器上相同。例如,gcc-5、gcc-8 或 gcc-9 现在会得到相同的行为。更改如下表所示:
新行为总结
运算符 | 旧警告 | 新警告 | 旧结果 | 新结果 | 在 MacOS 上有效 |
---|---|---|---|---|---|
np.divmod(1.0, 0.0) | 无效 | 无效 and 除以零 | nan、nan | inf、nan | 是 |
np.fmod(1.0, 0.0) | 无效 | 无效 | nan | nan | 不? 是 |
np.floor_divide(1.0, 0.0) | 无效 | 除以零 | nan | inf | 是 |
np.remainder(1.0, 0.0) | 无效 | 无效 | nan | nan | 是 |
(gh-16161)
np.linspace
在整数上现在使用 floor
当在numpy.linspace
中使用int
数据类型时,之前的浮点值会向零舍入。现在改为使用numpy.floor
,它会向-inf
舍入。这对负值的结果产生了变化。例如,之前的结果是:
>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -2, -1, -1, 0, 0, 0, 1])
现在结果变为:
代码语言:javascript复制>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -3, -2, -2, -1, -1, 0, 1])
仍然可以使用以下方法获得以前的结果:
代码语言:javascript复制>>> np.linspace(-3, 1, 8).astype(int)
array([-3, -2, -1, -1, 0, 0, 0, 1])
(gh-16841)