Rust: 添加对十六进制浮点文字的支持

我已经解决了这个问题，并得出结论，不幸的是，这又使问题 #1306 复活了。 当前的词法分析器因此禁止.之后的任何字母字符。 我们可以在找到模式0x<digits>.时有选择地允许它们，但它似乎太不一致，如果我们想消除不一致，可能需要无限前瞻。

我建议在点之后需要一个数字或 0x 或 0b。 这避免了冲突，并且（奇怪的是）让您可以根据需要切换基数中间文字。 它只是比 C99 让你写的东西丑一点。

@graydon或者我们可以在点后只要求零。 （例如0x1fffffffffffff.0p+972_f64而不是0x1.fffffffffffffp+1023_f64 ）

我不相信这是向后不兼容的，重新命名的。

接受功能完成里程碑

从 2013 年 7 月 15 日开始访问进行分类。 我们真的在这里确定了语法吗？ 对于新的贡献者来说，这似乎是一项很好的简单任务 _if_ 我们可以为他们提供明确的语法规范； 但如果语法仍处于设计阶段，那么这种说法就不那么正确了。

我认为我们还没有完全确定语法，但我应该指出有必要避免与后缀冲突（其中一些以 f 开头，一个十六进制数字），所以我认为如果我们这样做，它应该只适用于指定尾数，并且仅当与完整指数（十进制）结合使用时。

这还有待实施。

不是 1.0

十六进制浮点数在 C 数学库中非常流行。 我也很想在 Rust 中使用它们。

我看到十六进制浮点数已在 rust 中作为扩展实现，然后移动到一个单独的板条箱，现在它位于rust-deprecated并且无法使用 nightly rust 进行编译。

这个功能的未来是什么？

也对这个感兴趣。 我希望为游戏实现一个可重玩的物理系统，这需要跨计算机的一致结果。 十六进制浮点文字将允许我在测试和常量中编写位精确的浮点值。

至少，声明为什么不推荐使用此功能将不胜感激，因为该线程是我为“rust hex float literal”获得的第一个结果。

目前的情况有点棘手。 程序宏现在正在进行改造 (#38356)，因此在发生这种情况时保持hexfloat最新至少是浪费时间。 但不知道后面会发生什么故事。

如果我的理解是正确的，那么在 C/C++ 中存在十六进制浮点数，因为不能保证十进制浮点数正确舍入 [1]。 然而，在 Rust 中，在 #27307 之后---我怀疑这不一定是故意的！---几乎所有的十进制浮点数（#31407 描述了几乎不相关的边缘情况）应该四舍五入到最接近的，所以你可以只给 rustc适当的小数位数（例如 30），将得到正确的四舍五入数字。 目前，这将是一个“实用”的答案。

我仍然认为十六进制浮点数相关的一件事是从 C/C++ 的转换。 你不会想自己将所有的十六进制浮点数转换为十进制 :) 我最近写了一个实验性的程序宏，它就是这样做的，将十六进制浮点数转换为十进制浮点数（rustc 可以理解），但一直不愿意发布一个，因为到目前为止，现状实际上并没有得到保证——在我看来，这纯粹是运气。 如果有一种方法可以仅从 constexprs 构造一个具有精确位模式的浮点数，我会调整它。

[1] 例如，ISO C99 只要求十进制浮点数应转换为 ±1.5 ulps 内的可表示数（“结果要么是最接近的可表示值，要么是与最近的可表示值紧邻的较大或较小的可表示值” ）。

@lifthrasiir ，迟早我想通过正确地将 C hex 浮点数转换为 Rust 来修复https://github.com/jameysharp/corrode/issues/73 ，所以我想更好地理解你的评论。 我还没有对浮点问题进行足够的阅读来理解这里涉及的内容。

你是说，模 Rust 编译器错误，每个十六进制浮点文字都可以转换为十进制浮点文字，Rust 编译器将转换为相同的位模式？ 如果是这样，我很乐意让 Corrode 进行这种转换。 您能否推荐我应该阅读的参考文献，以了解正确执行该转换的算法？ （指向您的程序宏的指针会很棒，但理想情况下，我也想引用一篇论文或书籍。）

也就是说，我收集的十六进制浮点数的精确十进制版本可能需要更多的数字（对吗？），所以也许十六进制浮点数版本更容易阅读和理解，至少对于那些足够关心数字精度的人来说是这样的. 如果十六进制浮点数是这些数字的人类首选形式，我认为 Rust 应该支持它们。 因此，IMO，使用过十六进制浮点数的人的更多反馈在这里会有所帮助。

你是说，模 Rust 编译器错误，每个十六进制浮点文字都可以转换为十进制浮点文字，Rust 编译器将转换为相同的位模式？

我的信念是肯定的。

您能否推荐我应该阅读的参考文献，以了解正确执行该转换的算法？

你不必实现它，因为当前的 Rust 编译器和标准库实现了所有必要的算法（这是更难的算法：-）。 如果您确实需要参考，请参阅以下内容：

• 从二进制到十进制的转换（“flt2dec”，#24612）是 [Dragon4] 和 [Grisu3] 的混合体。

  • [Dragon4]：Burger, RG 和 Dybvig, RK 1996。快速准确地打印浮点数。 SIGPLAN 不是。 31, 5（1996 年 5 月），108-116。
  • [Grisu3]：弗洛里安·洛伊奇。 2010. 使用整数快速准确地打印浮点数。 SIGPLAN 不是。 45, 6（2010 年 6 月），233-243。

• 从十进制到二进制的转换（“dec2flt”，#27307）是 [Clinger] 描述的几种算法。 （我还没有自己实现它们，所以我对它们的了解是有限的。）

  • [克林格]：威廉·D·克林格。 1990. 如何准确读取浮点数。 SIGPLAN 不是。 25、6（1990 年 6 月），92-101。

作为记录，我的实现是lifthrasiir/hexf （现在发布，还没有在 crates.io 中）。 随意拿起。

也就是说，我收集的十六进制浮点数的精确十进制版本可能需要更多的数字（对吗？），[...] 如果十六进制浮点数是这些数字的人类首选形式，我认为 Rust 应该支持它们. [...]

不完全是，例如， 0x1.999999999999bp-4 = 0.10000000000000002 。 我对 Rust 是否应该支持十六进制浮点数没有意见。

我现在已经正式将hexf发布到@jameysharp ，我认为您可以在工作中使用 hexf-parse 吗？ （没有下划线的语法应该与C99 hexadecimal-floating-constant non-terminal sans optional floating-suffix几乎相同。）

编辑：啊我错过了一个案例。 0x1p1应该是有效的，但 hexf 不能识别它； 不过，这可能很容易解释。

我也有类似的用例； 我希望能够从编译器生成 Rust 代码，而不会损失浮点文字的精度。