用双精度数替换所有整数有哪些缺点？

Question

即使在索引到数组时，一致使用浮点类型来表示整数有哪些潜在的缺点？假设一个面向性能的 C 库的上下文。可以在 64 位整数和 64 位浮点数之间进行选择。

我对做这样的事情感到不舒服，因为doubles 不是用于索引的，并且使用工具来完成其设计目的之外的事情通常会带来风险。但我想了解是否有合理的理由避免这样做。

为了解决显而易见的问题：

• 当然，某些强制转换可能需要double与[ ]运算符一起使用。
• 当然，IEEE 754double无法表示与 64 位整数类型一样多的不同整数，但在可预见的将来，53 位可能足以用于索引数组。

---

事实上，浮点类型的这种用法在野外随处可见。例如，R 没有 64 位整数，并且通过使用doubles 进行索引来支持大型数组。在编写必须与 R 互操作的代码时，必须考虑是否也这样做。

Answer 1

1. 性能：在许多 CPU 架构上，浮点运算比整数运算慢。现代硬件上的浮点与整数计算但这在很大程度上取决于操作类型和所讨论的 CPU。如果代码没有被大量使用（分析为 Hot）或者它对于应用程序来说“足够好”，那么这可能并不重要。
2. 表示：浮点数通常以 2 为基数表示，并非所有（可精确表示的 10 基数）数字都可以准确表示。什么时候适合使用浮点精度数据类型？这对算术有影响，并可能产生意想不到的结果。娱乐时间
3. 比较：由于表示困难，一些 linter 和库不允许浮点之间的相等检查。SonarSource Java 规则 xUnit Assert 库（注意缺少 Equals(double double)）这是为了减少错误的可能性，但可能会影响您将双精度数用作整数。
4. 最小惊讶原则：在通常需要整数的地方使用浮点数会导致需要付出更多的努力来理解代码，这反过来又使维护和更改变得更加困难。
5. 对整数本机语言的支持较差：在使用整数作为主要类型的语言（例如 C）中，使用浮点代替整数会导致与语言的其余部分以及可能的许多库的“摩擦”增加。本质上，在您的示例中，您正在用 R 的互操作来交换与 C 的“互操作”。

为了与（几乎任何语言，甚至库）进行互操作，我建议创建一个互操作层或组件来处理它可以解决的所有问题，并记录它不能解决的问题，本质上抽象了（部分）互操作。