为什么Python中的sys.maxint <(sys.maxint - 100 + 0.01)?

sat*_*oru 7 python floating-point

为什么Python中的sys.maxint <(sys.maxint - 100 + 0.01)?

Bjö*_*lex 12

这可能是由于非常大的浮点值的精度损失.(0.01将右侧的转换添加到浮动).

编辑:我试图想出这里发生的事情的确切解释,但无济于事.所以我发布了一个关于它的问题.

  • @Satoru Logic:他的意思是失败,而不是松散.这11位不能"设置"任何东西,它们不存在.您有64名精确乘客可以安装在大约53辆精确乘客的公共汽车上.11名乘客错过了.浮点数(仍然是64位总线)中的那些11位位置用于指数和符号位.请注意,浮点数中的前导精度位根据定义为1,因此不需要座位. (4认同)

Ste*_*non 3

在具有 64 位长整型的系统上,sys.maxint是:

// decimal                  hexadecimal
   9223372036854775807      0x7fffffffffffffff
Run Code Online (Sandbox Code Playgroud)

也是如此sys.maxint - 100

   9223372036854775707      0x7fffffffffffff9b
Run Code Online (Sandbox Code Playgroud)

加法0.01会强制该值在加法之前舍入为双精度浮点数。可以用双精度表示的两个最接近的值是:

   9223372036854774784      0x7ffffffffffffc00
   9223372036854775808      0x8000000000000000
Run Code Online (Sandbox Code Playgroud)

因为sys.maxint - 100更接近第二个(较大的)值,所以向上舍入。添加0.01给出:

   9223372036854775808.01   0x8000000000000000.028f5c28f5c...
Run Code Online (Sandbox Code Playgroud)

它不能用双精度表示,因此再次四舍五入为:

   9223372036854775808      0x8000000000000000
Run Code Online (Sandbox Code Playgroud)

所以 的值实际上sys.maxint - 100 + 0.01 大于的值sys.maxint。然而,在许多现代语言中,整数和浮点数之间的比较会强制在比较发生之前将整数值转换为浮点数;如果是 python 中的情况,sys.maxint将四舍五入为相同的值,并且它们比较相等。Python中似乎不是这样的。我不熟悉 python 数字的细节,但这是该语言的一个有趣的好奇心。