python 2.7中&和^的奇怪行为答案

【问题标题】：strange behavior of & and ^ in python 2.7python 2.7中&和^的奇怪行为
【发布时间】：2017-08-14 21:49:12
【问题描述】：

这是我的代码，想知道为什么两种情况下的结果不同？实际上我希望第一行输出-1，因为位 AND 0xffffffff 不会改变任何东西。我希望第二行输出 1，因为位 XOR 0xffffffff 表示位 NOT（在 Python 中是 ~，并且添加另一个 1 应该得到 -1 的二进制补码值，即 1）

print -1 & 0xffffffff # output 4294967295
print -1 ^ 0xffffffff + 1 # output -4294967297

【问题讨论】：

Python 整数运算不是 32 位的；它是无限位的。（它在物理上不会存储无限数量的位，但它的行为就像它一样。）
@user2357112，我知道它像 Java 大整数一样是无限的，但是在我的第一种情况下它的值是 4294967295，在我的第二种情况下是 -4294967297？
您的推理是假设 32 位。为什么您认为“位 AND 0xffffffff 不会改变任何东西”？为什么你认为“bit XOR 0xffffffff 表示 bit NOT”？
（如果你在 Java 中测试并得到 -1 和 1，你很可能搞砸了 ^ 和 + 的优先级以及 0xffffffff BigInteger 的初始化。具有正确的优先级并避免在 0xffffffff 上溢出，Java gives the same output.)

标签： python python-2.7 twos-complement

【解决方案1】：

Python 以任意精度实现整数。在执行按位运算时，正数被视为具有无限的高阶 0 位序列，而负数则被视为具有无限的高阶 1 位序列。特别是，数字-1 就像1 的无限序列。

所以对于第一个计算我们有

    ...11111111111111111111111111111111111111111111111111111111
  & ...00000000000000000000000011111111111111111111111111111111
  = ...00000000000000000000000011111111111111111111111111111111

因为这在高位有0，所以这是一个肯定的结果。

第二个计算是：

    ...11111111111111111111111111111111111111111111111111111111
  ^ ...00000000000000000000000100000000000000000000000000000000 (this is 0xffffffff + 1 = 0x100000000)
  = ...11111111111111111111111011111111111111111111111111111111

由于这在高位有1，所以这是一个否定的结果。

【讨论】：

这还不能完全解释结果。请注意 Python 中的 + binds stronger than ^，因此第二个示例简化为 -1 ^ 0x100000000。
谢谢，错过了+1。我已经更新了答案以表明这一点。
@dhke 还更正了低位数字的数量。
32 位在需要输入时真的很多。
感谢 Barmar 的帮助，将您的回复标记为答案。