Implement ties-to-even for Big[U]Int::to_{f32,f64}

[dramforever]

This makes the rounding consistent with primitive types, which, per IEEE-754, uses nearest-ties-to-even rounding.

See: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a6ab9b18a4982f881cd594061f096f8c

#[test]
fn test() {
    use num::{BigInt, ToPrimitive};
    let a: i128 = (1 << 120) + (1 << (120 - 53));
    let b: i128 = 1 << (120 - 60);
    assert_ne!(a as f64, (a + 1) as f64);
    assert_eq!((a + b) as f64, (a + 1) as f64);

    assert_eq!(BigInt::from(a).to_f64().unwrap(), a as f64);
    
    // This works because the b is among the high 64 bits
    assert_eq!(BigInt::from(a + b).to_f64().unwrap(), (a + b) as f64);

    // This fails because 1 is just thrown away
    assert_eq!(BigInt::from(a + 1).to_f64().unwrap(), (a + 1) as f64);
}

[dramforever]

I'm not quite sure how to characterize this.

• Is this a bug? It's certainly pretty surprising.
• Should I add this to the changelog? Is this a breaking change?

[cuviper]

In general, the goal is to match the behavior of primitive types, at least so far as that behavior does not depend on limited bit width. So yes, having an example of different i128 behavior makes this look like a bug we should fix.

Breaking changes are fuzzy when it comes to behavior -- I think this is a justified change, but yes we should mention it in release notes. There's semi-related precedent in how Rust 1.67 fixed rounding in rust-lang/rust#102935.

[cuviper]

Thanks! I just rebased this without changes to get CI running.

bors r+

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• Format
• No Std
• Test (1.31.0)
• Test (1.34.0)
• Test (1.36.0)
• Test (1.40.0)
• Test (1.46.0)
• Test (beta)
• Test (i686)
• Test (nightly)
• Test (stable)