4 ms·

Floats are not guaranteed to be bit-identical at compile time and run time in Rust.

• weinzierl 2y ago
  Last time I checked the float functions that have no bit-identical results (mostly transcendental functions) were missing from Rust's const fn for exactly that reason.
• kibwen 2y ago
  It's not quite as bad as it sounds, because the only difference is that the representation of NaN (the sign and the payload bits) isn't guaranteed to be stable. If you're not relying on any specific representation of NaN, then floating-point math in const fn is identical, and observed differences would be considered a soundness bug in the Rust compiler.
  • weinzierl 2y ago
    I had to look this up because it is a while that I tried to use floating point math in a const fn and it seems that the differences you described have been decided to be acceptable. Looks like floating point math in const fn is coming. Here is the respective tracking issue: https://github.com/rust-lang/rust/issues/128288 https://github.com/rust-lang/rust/issues/128288
    • kibwen 2y ago
      It's actually already here, it stabilized last year in 1.82: https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#floating-point-nan-semantics-and-const https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#float...
      • weinzierl 2y ago
        Oh, nice. Sometime I find it really hard to track the status of new Rust features. For example the tracking issue I linked is still open with "Stabilize" missing.
        • kibwen 2y ago
          That's because the linked issue is a different, but related tracking issue. The FP-in-const tracking issue was this one: https://github.com/rust-lang/rust/issues/57241 https://github.com/rust-lang/rust/issues/57241
  • throwawaymaths 2y ago
    what happens if you compile on a system that has a different precision than the system you run on? like suppose you compile on a 64 bit system targetting 32 bit embedded with an fp accelerator or a 16 bit system with softfloat?
    • kibwen 2y ago
      I'm not personally familiar with the implementation, but Rust's const fn is evaluated using an interpreter called MIRI with its own softfloat implementation, and therefore isn't limited by the precision of the host platform. The act of cross-compilation shouldn't pose a problem, and would be a soundness issue in the compiler if it did.
      • throwawaymaths 2y ago
        no the soundness of the compiler is at risk because the target has limitations, not the host.
        • kibwen 2y ago
          As long as the target is compliant with IEEE 754, which is what Rust expects, it shouldn't be an issue. The only platform that I know of that causes problems is extremely old pre-SSE 32-bit x86, where floats sometimes have 80-bit precision and which can't be worked around because of LLVM limitations which nobody's going to fix because the target is so obscure. Rust will probably just end up deprecating that target and replacing it with a softfloat equivalent.
          • throwawaymaths 2y ago
            there are multiple IEE-754 fps. 32, 64, and 80 in use. so your claim is that rust compiler knows in advance which will be used by the target and adjusts its softfloat accordingly? I'm not convinced. IIRC there are cases for SIMD where there is only a 2 ULP guarantee and some tryhard silicon gives you 1 ULP for the same opcode.
• codedokode 2y ago
  They are not guaranteed to be precise anyway.