【问题标题】:Strange issues summing ints and floats对整数和浮点数求和的奇怪问题
【发布时间】:2020-08-24 13:59:49
【问题描述】:

有人可以向我解释一下吗?

我正在编写一个 def(程序)来将文本转换为数字,并想确保它是否只是整数,表示是整数,如果是浮点数,则浮点数。如果是混合,则默认为浮动。在总和上测试它产生了一些有趣的东西。当我测试更多时,它仍然变得陌生。

如果它总是另一种方式,也许我可以解决,但据我所知,它是不一致的。我听说这是一个问题,并且有一些库可以解决所需的状态(十进制类型),但是为什么会发生这种情况呢?这种事情让我很担心。我可以做?

以下示例从“是的,这很有意义”到“嗯?”到“怎么在???”。这些发生在非常接近的数字范围内。我的意思是当它是 5.8 与 6.8 时,你会在结果中得到那个增量。重量???

TIA 提供任何见解。我敢肯定这是某个地方的旧消息 :)

所有都在提示符下运行,尽管在代码中是相同的。使用 Python 3.8.2 一些例子:

-2 + 4.5 => 2.5 “是的,这是有道理的”

-6.8 + 8 => 1.2000000000000002 “嗯?”

-2+3.8 => 1.7999999999999998“怎么在???”

-5.8+8 => 2.2

-7.8+8 => 0.20000000000000018

-8.8+8 => -0.8000000000000007

-4.8+8 => 3.2

-4-3.8+8 => 0.20000000000000018

-4+3.8 => -0.20000000000000018

-3+3.8 => 0.7999999999999998

-1+3.8 => 2.8

【问题讨论】:

标签: types floating-point int


【解决方案1】:

当−6.8 转换为 IEEE-754 64 位二进制浮点格式时,它是不可表示的,因此会生成最接近的可表示值。该值为 -6.CCCCCCCCCCCCC16。添加 8 时,结果为 1.333333333333416。以十进制表示,即 1.20000000000000017763568394002504646778106689453125。有些软件显示为 1.2000000000000002。

注意,当1.2转换成这种格式时,结果是1.333333333333316,而不是1.333333333333416。这与 -6.8+8 不同,因为对于 -6.8,舍入必须发生在 2-50 位位置,因为表示 -6.8 需要位以 22 位置,有效数中有 53 位(浮点表示形式的部分,表示数字的“小数”部分)。对于 1.2,第一位在 20 位置,舍入发生在 2-52 位置。因此,将 1.2 转换为浮点格式会产生比 −6.8+8 更接近 1.2 的结果。

在显示浮点数时,某些软件的默认格式会生成与唯一区分浮点数与其相邻可表示值所需的一样多的十进制数字。当 1.2 转换为 1.333333333333316 并格式化为十进制时,会生成“1.2”,因为它可以唯一区分 1.333333333333316。但是当1.333333333333416被格式化时,需要产生“1.2000000000000002”来与1.333333333333316区分开来。

您的其他示例类似。在像 -5.8+8 这样的情况下,四舍五入的结果恰好与直接转换 2.2 得到的结果相同,因此输出为“2.2”。在其他情况下,四舍五入的结果会略有不同,您会得到不同的输出。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-28
    • 1970-01-01
    • 2015-12-31
    • 2010-12-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多