f64 operation gives different results depending on environments

Question

The code below gives different result depending on environments:

fn main() {
    let n: usize = 5489031744;
    let n_cbrt: usize = (n as f64).cbrt().floor() as usize;
    println!("{}", n_cbrt);
}

Rust Playground and my Linux server (Ryzen) gives

1763

though M1 Macbook Air gives

1764

Mathematically, 1764.pow(3) exactly equals 5489031744 so the latter result is correct. But, anyway, the problem is the inconsistency rather than mathematical correctness.

Is this inconsistency a bug? If not, does this mean we cannot write a cross-platform application whose behavior is fully predictable and consistent in Rust?

By the way, the C++ program below gives 1764 in both my Linux server (Ryzen) and M1 Macbook Air (and in an online compiler).

#include <iostream>
#include <cmath>

int main() {
    std::cout << cbrt(5489031744) << "\n";
}

Very strange as it seems Rust's cbrt() calls C++'s cbrt() directly (source):

pub fn cbrt(self) -> f64 {
    unsafe { cmath::cbrt(self) }
}

Summary:

Environment	Rust	C++
Linux (Ryzen)	1763	1764 (clang++, g++)
macOS (M1)	1764	1764 (clang++, g++)
Rust Playground	1763
C++ online compiler		1764 (g++)
FreeBSD (Intel)	1764	1764 (clang++, g++)

Answer 1

It is a floating point issue, calculation using floating point are not 100% percise, and so some inconsistency arise resulting in either x.00000000001 or x.99999999999.

In your case the issue was probably the following:

(n as f64).cbrt() resulted in 1763.999999999999999999999999999999

but adding .floor() exacerbated the problem, a quick fix would be to use .round() instead

If you require .floor() for some specific logic, you can use a decimal library such as https://docs.rs/rust_decimal/latest/rust_decimal/struct.Decimal.html which will probably hurt performance

Another hack than can be used if you use .floor() right after it is to add an epsilon (0.00000000001).

fn main() {
   let n: usize = 5489031744;
   let n_cbrt: usize = ((n as f64).cbrt() + 0.0000000001).floor() as usize;
   println!("{}", n_cbrt);
}

Answer 2

It looks like this is a difference between gcc and clang (/ libm): https://godbolt.org/z/oEPfaYP5W

Converting your program to C with a large-ish amount of precision:

#include <stdio.h>
#include <math.h>

int main() {
    printf("%.15f", cbrt(5489031744));
}

Compiling with GCC:

1764.000000000000000

with clang:

1763.999999999999773

I would assume it's a factor of cbrt being implemented slightly differently between the two libc/libm(ath), which leads to very slightly different results (by less than 1.3e-16).

But because you then proceed to floor() the result rather than just round it, this slight difference leads to a massive divergence in the final result, because you massively expand slight instabilities in the floating-point computation.

edit: looking at the assemblies, it seems like GCC just compiles the cube root at compile time:

.LC1:
        .string "%.15f"
main:
        sub     rsp, 8
        movsd   xmm0, QWORD PTR .LC0[rip]
        mov     edi, OFFSET FLAT:.LC1
        mov     eax, 1
        call    printf
        mov     eax, 0
        add     rsp, 8
        ret
.LC0:
        .long   0
        .long   1083936768

while clang actually calls the CBRT intrinsic:

.LCPI0_0:
        .quad   0x41f472bfa4000000              # double 5489031744
main:                                   # @main
        push    rax
        movsd   xmm0, qword ptr [rip + .LCPI0_0] # xmm0 = mem[0],zero
        call    cbrt@PLT
        lea     rdi, [rip + .L.str]
        mov     al, 1
        call    printf@PLT
        xor     eax, eax
        pop     rcx
        ret
.L.str:
        .asciz  "%.15f"

Looking at other compilers, icc returns 1764.000000000000000 while tcc -lm returns 1763.999999999999773