python - 使用 int dtype 的 numpy 数组计算出错(它无法在需要时自动将 dtype 转换为 64 位)

Question

当计算的输入是具有 32 位整数数据类型的 numpy 数组，但输出包含需要 64 位表示的较大数字时，我遇到了错误的 numpy 计算问题。

这是一个最小的工作示例:

arr = np.ones(5, dtype=int) * (2**24 + 300)  # arr.dtype defaults to 'int32'

# Following comment from @hpaulj I changed the first line, which was originally:
# arr = np.zeros(5, dtype=int) 
# arr[:] = 2**24 + 300

single_value_calc = 2**8 * (2**24 + 300)
numpy_calc = 2**8 * arr

print(single_value_calc)
print(numpy_calc[0])

# RESULTS
4295044096
76800

期望的输出是 numpy 数组包含正确的值 4295044096，这需要 64 位来表示它。也就是说，我希望 numpy 数组在输出需要时自动从 int32 向上转换为 int64，而不是保持 32 位输出并在超过 2^32 的值后返回到 0。

当然，我可以通过强制使用 int64 表示来手动解决问题:

numpy_calc2 = 2**8 * arr.astype('int64')

但这对于一般代码来说是不可取的，因为在某些情况下而不是所有情况下输出只需要 64 位表示(即保存大数字)。在我的用例中，性能至关重要，因此每次都强制向上转换成本很高。

这是 numpy 数组的预期行为吗？如果是这样，请问有干净、高效的解决方案吗？

Answer 1

numpy 中的类型转换和提升相当复杂，偶尔也会令人惊讶。 This recent unofficial write-up by Sebastian Berg解释了该主题的一些细微差别(主要集中在标量和 0d 数组上)。

引用自本文档:

Python Integers and Floats

Note that python integers are handled exactly like numpy ones. They are, however, special in that they do not have a dtype associated with them explicitly. Value based logic, as described here, seems useful for python integers and floats to allow:

arr = np.arange(10, dtype=np.int8)
arr += 1
# or:
res = arr + 1
res.dtype == np.int8

which ensures that no upcast (for example with higher memory usage) occurs.

(强调我的。)

另见 Allan Haldane's gist suggesting C-style type coercion , 从上一个文档链接:

Currently, when two dtypes are involved in a binary operation numpy's principle is that "the output dtype's range covers the range of both input dtypes", and when a single dtype is involved there is never any cast.

(再次强调我的。)

所以我的理解是 numpy 标量和数组的提升规则不同，主要是因为检查数组中的每个元素以确定是否可以安全地进行转换是不可行的。再次来自以前的文档:

Scalar based rules

Unlike arrays, where inspection of all values is not feasable, for scalars (and 0-D arrays) the value is inspected.

这意味着您可以从一开始就使用 np.int64 以确保安全(如果您使用的是 linux，则 dtype=int 实际上会这样做自己)，或者在可疑操作之前检查数组的最大值，并根据具体情况确定是否必须自己提升数据类型。我知道如果您要进行大量计算，这可能不可行，但考虑到 numpy 当前的类型提升规则，我认为没有办法解决这个问题。