为什么 Kotlin 认为负零小于正零答案

【问题标题】：Why Kotlin considers negative zero less than positive zero为什么 Kotlin 认为负零小于正零
【发布时间】：2018-02-04 15:08:14
【问题描述】：

刚开始学习Kotlin，在basic types的文档中遇到了一个奇怪的句子：

-0.0 被认为小于 0.0

我知道它们的值在反码中不会相同，但我不知道如何在代码中使用它。

【问题讨论】：

【解决方案1】：

不遵循 IEEE 754 标准的已擦除浮点比较的主要目的是，当您在集合中使用浮点数并作为排序键时，您不希望根据标准相互混合。例如，您不想在映射中混合使用 -0.0 和 0.0 作为键（您可能希望这些键有两个不同的值）。

同样，尽管标准规定 NaN != NaN，但您希望地图将 NaN 与其自身匹配。

而且，当您对一组项目进行排序时，您希望 NaN 与其他数字正确排序，即使标准说它与其他元素无法比较（此处遵循标准甚至可能会破坏排序算法）。

请注意，这些规则仅适用于静态不知道对象属于浮点类型的情况，这实际上与通用用例和集合相匹配。相反，数学用例通常直接对数字类型进行操作（不会将它们擦除为Any 或类型参数），因此会应用 IEEE 754 规则。

【讨论】：

【解决方案2】：

我也找到了那句话，很令人费解。它实际上与零有两种表示的事实几乎没有关系，因为（可能会认为）理论上这应该隐藏在实现中，使得 -0.0 == +0.0 为真（可能不是 ===），同样 - 0.0

然而，声明 -0

我相信 Kotlin 的人会彻底考虑到这一点（

当然，程序员在浮点上使用相等时必须格外小心，但直到现在我一直认为“if (!!x) return 1.0/x”之类的东西或多或少是安全的（考虑到 IEEE 对舍入、溢出等）。也许这在 Kotlin 文档的其他地方有讨论；我仍然对这个功能感到有些不安。

【讨论】：

【解决方案3】：

我完全不明白上面的第一个答案，虽然我承认我是 Kotlin 的新手。

我不知道“擦除的浮点比较”是什么意思，但我假设它意味着 -0.0 != +0.0 的决定。我将其视为实施决策，而不是删除。

我也完全不明白最后一段是什么意思。根据类型是否可静态确定来更改类型的相等语义是荒谬的。我猜不出 Kotlin 设计师的想法，但不可能是这样的；我只是完全不明白那段中发生了什么。

此外，违反 IEEE 数字以允许浮动映射键，或提供额外的标记或标志或键值，是一种奇怪的优先级倒置。这就是 NaN 的用途。对如此广泛使用的标准的异常违反需要非凡的动力，而上面的第一个答案似乎错过了那条船。

如果您需要玩这种奇怪的游戏，最好使用底层的 32 位、64 位或 128 位位串作为键。在进行实时数值处理的 45 年中，我什至从未想过用浮点数索引地图，尽管我实际上可以想象它（但没有改变标准以适应这种混乱）。

也许我出去吃午饭了，但这里的某个地方似乎存在严重的脱节。

【讨论】：

不能将此“评论”添加到您的其他答案中吗？
是的，应该是这样。我仍然是协议的菜鸟，我不太了解该网站。这是我第一次将 Stack Overflow 用于任何重要的事情，我深表歉意。
天啊，这是我第四次尝试添加此评论。显然，按 Enter 会忽略我的大部分输入并提交其中的一小部分。另外，这是最后一次我的整个评论不知何故被删除了。显然有一些键（靠近空格键）我误击中止了我当前的答案并删除了之前输入的部分评论。我找到了非常酷的编辑链接，但由于某种原因，我对早期版本的整个尝试在完全删除之前都失去了该功能。我相信我最终会弄清楚我需要什么。