关于轴的 Numpy 索引逻辑

Question

当我们有一个numpy 数组，并且想要沿一个轴执行操作时，为什么axis=1 相当于跨行 工作，而axis=0 相当于向下工作列？

如下例所示，创建numpy 数组需要通过 kwarg size 指定维度：

np.random.randint: (low, high=None, size=None, dtype='l')

这是一个元组，例如（形式：size=(number_of_rows, number_of_columns)

>>> import numpy as np

>>> a = np.random.randint(0, 20, (3, 4))

>>> a
array([[16,  7,  4,  7],
       [ 4, 10,  8,  5],
       [ 7,  1, 15,  7]])

>>> np.sum(a, axis=0)
array([27, 18, 27, 19])

>>> np.sum(a, axis=1)
array([34, 27, 30])

>>> a.shape[0]
3

>>> a.shape[1]
4

行的求和是通过设置axis=1来执行的，我期望axis=0。

这样做有充分的理由吗？每次使用它都会让我感到困惑，直到我习惯了它。为什么它与（在我看来！）索引数组的标准方式相矛盾，就像代码中带有 shape 属性的示例一样？

更新

这里还有一些（令人困惑的？）代码，表明axis=0 适用于一维数组，正如人们所预料的那样。

>>> b
array([1, 2, 3, 2, 3, 4])

>>> np.sum(b, axis=0)
15

>>> np.sum(b, axis=1)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
    np.sum(b, axis=1)
  File "/usr/local/lib/python3.6/site-packages/numpy/core/fromnumeric.py", line 1814, in sum
    out=out, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/numpy/core/_methods.py", line 32, in _sum
    return umr_sum(a, axis, dtype, out, keepdims)
ValueError: 'axis' entry is out of bounds

我希望这是默认设置，因为一维数组实际上只能在一个方向上求和。 感谢您在 cmets 中的输入。我认为斯蒂芬关于表现的答案是正确的。是在 numpy 中产生这个小怪癖，成为常态。

Answer 1

您认为 numpy“减少”操作的 axis 参数，即减少维数的操作 - 通常是一维操作是不合逻辑的。您的论点是，给定一个二维数组，“幸存”维度不是指定的维度。很明显，您正在使用短语 summing across。

请允许我证明这种批评是站不住脚的。更一致的概念是沿一个轴求和，而不是指定幸存的轴，而是由reduce操作消耗的轴。

要看到这个，想想 3d 或 100d。如果您平均一堆图像，您会得到一个平均图像，因此您正在平均 沿 在此过程中消耗的堆叠轴。根据您的逻辑-您将根据幸存的轴 x 和 y 指定此过程-这显然是被误导的，想想 100d-您必须枚举 99 个幸存轴来描述沿单个轴的单个减少。

如果您对数学感到满意，您也可以轻松地说服自己，积分或求和变量是后来消失的变量。矩阵乘法：求和维度是结果中没有特征的那个 AB = C -> c_jl = sum_k=1^n a_jk b_kl

类似地将形状 (M, N) 视为行数，列数在 2d 中有效，但在其他任何地方都没有。在 3d 中它将变成 number-of-x-y-planes, number-of-x-z-planes, number-of-y-z-planes, 在 100d number-of-x1-x2-x3-...-x99-hyperplanes, number -of-x0-x2-x3-...-x99-hyperplanes, ... 更好地将 (M, N) 视为列长度、行长度。

我可以继续这样下去，但如果到现在你还不相信，那么我看不出有什么能说服你。

Answer 2

数组索引是numpy 中常见的混淆来源。在numpy docs 中有关于这个话题的精彩讨论。

混乱的根源：

首先要了解的是 索引二维数组有两个相互冲突的约定。 矩阵表示法使用第一个索引来指示正在选择的行和 第二个索引来指示选择了哪一列。这是对面的 人们通常认为的图像的几何导向约定 第一个索引表示 x 位置（即列），第二个索引表示 y 位置（即行）。仅这一点就是很多混乱的根源。 面向矩阵的用户和面向图像的用户期望两种不同的东西 关于索引。

答案：

就像 numpy 中的许多其他内容一样，问题的答案是因为：性能：

如果这是真的，为什么不选择 最符合您期望的索引顺序？特别是，为什么不定义 按行排序的图像使用图像约定？ （这有时被称为 作为 Fortran 约定与 C 约定，因此是“C”和“FORTRAN” numpy 中数组排序的顺序选项。）这样做的缺点是 潜在的性能惩罚。顺序访问数据很常见， 在数组操作中隐式或通过循环遍历 图片。完成后，将以非最佳顺序访问数据。