div_euclid use incorrect roundings

[Neutron3529]

I tried this code:

#![feature(f16, f128)]
fn main() {
    let a = 1.2f16;
    let b = 1.1f32;
    let c = 1.1f64;
    let d = 1.1f128;
    println!(
        "{} {} {} {}",
        (12f16).div_euclid(a) as f64,
        (11f32).div_euclid(b),
        (11f64).div_euclid(c),
        (11f128).div_euclid(d) as f64
    );
    println!(
        "{} {} {} {}",
        (12f16).rem_euclid(a) as f64,
        (11f32).rem_euclid(b),
        (11f64).rem_euclid(c),
        (11f128).rem_euclid(d) as f64
    );
}

I expected to see this happen:

All the 4 rem_euclid calls suggests .div_euclid should return 9 rather than 10.

Instead, this happened:

All the 4 .div_euclid calls yield 10.

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (7db7489f9 2024-11-25)
binary: rustc
commit-hash: 7db7489f9bc274cb60c4956bfa56de0185eb1b9b
commit-date: 2024-11-25
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.4

Remark

I suspect the div_euclid for float type is buggy. For example, with (even correct) roundings, it is quite common that self < self.div_euclid(small_number) * small_number with rounding errors (which might not be expected.)

#![feature(float_next_up_down)]
assert_eq!(1f64, 1f64.next_down().div_euclid(1e-16) * 1e-16);
// pass, but this is not expected since the result 1f64 greater than the input `1f64.next_down()`

Maybe we should mark div_euclid/rem_euclid as at least unsafe, and perhaps we should also provide things like divmod which yields consist results so that self.divmod(thing).0 * thing + self.divmod(thing).1 == self always hold.

Tracking:

• Tracking Issue for f16 and f128 float types #116909

[theemathas]

Duplicate of #107904