这里发生了什么？
>>> a = np.int8(1)
>>> a%2
1
>>> a = np.uint8(1)
>>> a%2
1
>>> a = np.int32(1)
>>> a%2
1
>>> a = np.uint32(1)
>>> a%2
1
>>> a = np.int64(1)
>>> a%2
1
>>> a = np.uint64(1)
>>> a%2
'1.0'
我们突然得到一个似乎是一个包含浮子的字符串! 1.0
>>> a = np.uint64(1)
>>> type(a%2)
<type 'numpy.float64'>
......虽然事实证明它只是一个漂浮物.
这背后的哲学是什么？
我知道numpy想要更严格的类型和打字规则之类的东西,以便比基本的python更有效,但在这种情况下,向用户返回一个非常意外的结果(可能会破坏他们的程序)的缺点似乎远远超过在沿着这条湿滑路径徘徊之前,仅仅检查模数符号的成本略有增加.
处理uint64价值观并不是很少见.例如,如果您将图像加载到numpy int数组中然后对其求和,则可以使用uint64(s).另一方面,用负数来修改任何东西是非常罕见的(除了看看会发生什么之外,我从来没有做过),因为你通常会修改你可以计算的东西,比如索引,以及不同的语言/标准/库每个人都可以对结果应该有自己的想法.
所有这些放在一起让我感到困惑.
我们突然得到一个看起来像是包含浮点数 1.0 的字符串！？
这仍然是一个 float64 - 由于numpy 1.14.3 中的错误（在 1.15.0-dev 中已修复），它看起来很奇怪。
您通常会认为只有两种方法可以转换为字符串 - __repr__( tp_repr) 和__str__( tp_str)。
原来在python 2中，多了一个 - tp_print。仅当直接输出到控制台或解释器时才会调用此函数。
事实证明，我们只对解释器实施了这个错误。在测试套件中测试解释器行为非常棘手！
尽管事实证明它只是一个浮动。
这是某种设计使然 -2被推断为np.int64(2)和 强制{int64, uint64} -> float64（不导致截断）。这方面存在很多问题，但解决起来很棘手。