Python numpy中的连续整数之和不正确

Python numpy中的连续整数之和不正确,python,python-3.x,numpy,sum,Python,Python 3.x,Numpy,Sum,使用以下公式对第一个100000000正整数求和: import numpy as np np.arange(1,100000001).sum() 我返回:987459712,它与N=100000000的公式:N(N+1)/2不匹配。即,公式返回500000050000000 在发布之前,我写了以下内容,返回True: np.arange(1,65536).sum() == ((65535+1) * 65535)/2 然而,数字65536似乎是一个关键点,因为 np.arange(1,655

使用以下公式对第一个
100000000
正整数求和:

import numpy as np
np.arange(1,100000001).sum()
我返回:
987459712
,它与
N=100000000
的公式:
N(N+1)/2
不匹配。即,公式返回
500000050000000

在发布之前,我写了以下内容,返回
True

np.arange(1,65536).sum() == ((65535+1) * 65535)/2
然而,数字
65536
似乎是一个关键点,因为

np.arange(1,65537).sum() == ((65536+1) * 65536)/2
返回
False

对于大于
65536
的整数,代码返回
False
,而低于此阈值的整数返回
True


有人能解释一下我在计算总数时做错了什么,或者代码是怎么回事吗

似乎
numpy
有时很难猜测正确的数据类型

在我的系统上,Win 10 64位、Python 3.4.4、numpy 1.13.1:

>>  np.arange(1, 100000001).sum()
987459712
>>  np.arange(1, 100000001).dtype
dtype('int32')
但是,如果我们“帮助”
numpy
它会得到正确的结果:

>> np.arange(1, 100000001, dtype=np.int64).sum()
500000005000000

错误的结果显然是由于32位整数溢出。

这并不是说
numpy
很难猜测,只是类型与C long类型相同:

int
:默认整数类型(与C long相同;通常为int64或int32)

对于windows系统,long是32位的,即使在64位构建上也是如此(更多信息请参见),因此默认情况下使用的是,
int32

正如DeepSpace所建议的,将
dtype
设置为
int64
可以实现这一目的。这可以通过
arange
sum
方法完成


此外,你还写道:

在发布之前,我写了以下内容,返回
True

np.arange(1,65536).sum() == ((65535+1) * 65535)/2
np.arange(165536).sum()==((65535+1)*65535)/2

然而,数字65536似乎是一个关键点,因为

np.arange(165537.sum()=((65536+1)*65536)/2

返回
False

这是因为第二个和超过了int32的最大值,而第一个和没有:

>> np.arange(1,65536).sum() < np.iinfo(np.int32).max
True    
>>> np.arange(1,65537).sum() < np.iinfo(np.int32).max
False
np.arange(165536).sum()>>np.arange(165537).sum() 当然,由于Python3的任意精度
int
s,Python计算是正确的



这就是为什么我们中的许多人无法繁殖。在大多数unix上,64位机器的默认int大小是
int64
(因为
C
的长度是64位),因此这些int的总和等于预期值。

这感觉像是特定于实现的行为。您使用的Python是什么版本和实现?我可以在64位机器上使用CPython 3.6.3正确计算预期结果。但通常int最多可以容纳65536个字符。在那之后,你有了一个溢出,你得到了不一致。为了澄清,我在使用numpy版本1.12.1,我也在使用numpy版本1.12.1。python版本是3.6.1,
50000005000000
看起来很奇怪。奇怪的是,我得到了相同的结果,但如果我尝试其他不同于
10000001
的数字,我会得到很好的结果。无论如何,在这种情况下,我会使用
uint64
而不是
int64
@IgnacioVergaraKausel。你能解释一下uint64的偏好吗?既然你没有使用负数部分,那么使用无符号类型会给你更多的空间和“安全性”,以防止溢出分配的空间。那么为什么
np.arange(110000000001,dtype=np.int32).sum()
是否给出正确的64位结果?(至少在我的机器上是这样的:macOS、Python 3.6、NumPy 1.13.3)@MarkDickinson该方法使用默认的int大小,即
int64
。显然,根据链接的模型,带有
cygwin
的窗口也应该使用
int64