如果我们有一个numpy数组，并希望沿一个轴执行操作，为什么axis=1相当于在行上工作，{{1}相当于处理列？
从下面的示例中可以看出，创建axis=0数组需要通过kwarg numpy指定维度：
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适用于1d数组，正如人们所期望的那样。
axis=0我希望这是默认值，因为1d数组只能在一个方向上实际求和。 感谢评论中的输入。我认为关于斯蒂芬表现的答案是正确的。在numpy产生这个小怪癖成为常态。
答案 0 :(得分：1)
数组索引是numpy中混淆的常见原因。在numpy docs。
混乱的根源：
首先要了解的是 对于索引二维数组有两种相互矛盾的约定。 矩阵表示法使用第一个索引来指示正在选择哪一行 第二个索引，用于指示选择哪个列。这与之相反 几何导向的图像约定，人们通常认为 第一个索引表示x位置（即列），第二个索引表示y 位置（即行）。仅这一点就是混乱的根源; 面向矩阵的用户和面向图像的用户期望有两种不同的东西 关于索引。
答案：
与numpy中的其他许多内容一样，问题的答案是因为：性能：
如果这是真的，为什么不选择 与您最期望的匹配的索引顺序？特别是，为什么不定义 行排序图像使用图像约定？ （有时会提到这一点 作为Fortran会议与C大会，因此＆＃39; C＆＃39;和＆＃39; FORTRAN＆＃39; numpy中数组排序的顺序选项。）这样做的缺点是 潜在的绩效惩罚。按顺序访问数据很常见， 隐式地在数组操作中或通过循环遍历的行显式地 图片。完成后，将以非最佳顺序访问数据。
答案 1 :(得分：1)
你在争论numpy的axis论证＆＃34;减少＆＃34;操作，即减少维数的操作 - 通常是一个操作不合逻辑。你的论点是给定一个2d数组＆＃34;幸存＆＃34;尺寸不是指定的尺寸。很明显，你正在使用跨越这一短语。
请允许我证明这种批评是站不住脚的。更一致的概念是将沿轴相加并指定不是幸存的轴，而是指定由reduce操作消耗的轴。
看到这个想3d或100d。如果平均一堆图像，则会得到一个平均图像，因此您将沿着平均平均堆积轴进行平均处理。根据你的逻辑 - 你根据幸存的轴x和y来指定这个过程 - 这显然是错误的，想想100d - 你必须枚举99个幸存的轴来描述沿着a的单个减少单轴。
如果您对数学感到满意，您也可以轻松地说服自己，整合或求和变量是之后消失的变量。矩阵乘法：求和维度是在结果AB = C中不具有特征的维度 - > c_jl = sum_k = 1 ^ n a_jk b_kl
类似地将形状（M，N）视为行数，列数在2d中起作用，但不在其他地方。在3d中，它将成为xy平面数，xz平面数，yz平面数，100d数x1-x2-x3 -...- x99-超平面，数量-of-x0-x2-x3 -...- x99-hyperplanes，...更好地考虑（M，N）作为列长，行长。
我可以继续这样下去，但如果现在你不相信那么我就不知道什么可以说服你。