Decimal formatting for some floating point numbers does not round-to-even

[gregates]

I have discovered a class of f64 for which format!("{}", f) rounds ties up to 3, rather than down to 2 as expected. Formatting those same numbers with fixed precision correctly rounds ties to even.

Here is some code that demonstrates the discrepancy:

fn main() {
    let fs: [f64; 15] = [
        112171935477118.12,
        181681934355391.62,
        -581170764721946.2,
        131673329546813.62,
        711901304153173.2,
        91266877191838.12,
        18406814307348.312,
        -620793498637746.2,
        -889345962364809.2,
        -664193405104534.2,
        -157386457699813.12,
        566922914748074.2,
        223437609802779.12,
        945017102864441.2,
        32461450983719.062,
    ];

    for f in fs {
        let no_precision = format!("{}", f);
        let mut split = no_precision.split('.');
        let _int = split.next();
        let frac = split.next().unwrap();
        let precision = frac.len();
        println!("{} != {:.2$}", f, f, precision);
    }

This program prints:

112171935477118.13 != 112171935477118.12
181681934355391.63 != 181681934355391.62
-581170764721946.3 != -581170764721946.2
131673329546813.63 != 131673329546813.62
711901304153173.3 != 711901304153173.2
91266877191838.13 != 91266877191838.12
18406814307348.313 != 18406814307348.312
-620793498637746.3 != -620793498637746.2
-889345962364809.3 != -889345962364809.2
-664193405104534.3 != -664193405104534.2
-157386457699813.13 != -157386457699813.12
566922914748074.3 != 566922914748074.2
223437609802779.13 != 223437609802779.12
945017102864441.3 != 945017102864441.2
32461450983719.063 != 32461450983719.062

Meta

rustc --version --verbose:

rustc 1.83.0-nightly (2bd1e894e 2024-09-26)
binary: rustc
commit-hash: 2bd1e894efde3b6be857ad345914a3b1cea51def
commit-date: 2024-09-26
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0

[hanna-kruppe]

Note that none of these decimal literals can be represented exactly in binary floating point. For example, the first one is rounded to 112171935477118.125 by the Rust compiler while parsing the source code. I assume you know that, since you mention rounding of ties, but it's good to spell this out.

When not explicitly specifying a precision, the primary correctness criterion for converting a binary floating point number to a decimal string is correct round-tripping. That is, the resulting string, converted back to binary floating point (correctly rounded with ties-to-even) reproduces the original number exactly. That's the case here: for each number, both decimal representations you can get are parsed the same: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=13ac414748d69d025352031689dd18b8

I don't know if the standard library promises ties-to-even for all float formatting -- the behavior is woefully under-documented. Getting two different outputs with the same number of decimal digits certainly looks odd, but formatting with a given precision and without one have different meaning and use different code paths internally. So it's entirely plausible that they could round differently. It would be nice to be consistent but it's possible this conflicts with other goals (e.g., performance or code size). The comments in the implementation only talk about wanting to pick the decimal representation that's closest to the original value, with some unspecified tie-breaking mechanism, but without specifying that mechanism or even stating whether both code paths use the same one.

[gregates]

The docs for std::fmt do specify

When truncating these values, Rust uses round half-to-even, which is the default rounding mode in IEEE 754.

Now, that's only for fixed-precision formatting, but the rationale that it's default rounding mode in IEEE 754 would seem to apply as well when no precision is specified, given that f64 is intended to implement IEEE 754-2008.

In any case, granting that one could argue this isn't strictly a bug because no rounding mechanism has been specified, it nevertheless seems to me that, when precision is given so as to produce the same number of digits, it would be a nice property to have that format!("{}", f) and format!("{:.1$}", f, precision) produce the same result. It's surprising that it doesn't always.

[hanna-kruppe]

Note that the different behavior can affect much more than just the last digit. With large integers, the current behavior of the "shortest" formatting can skip many, many superfluous digits (only adding zeros): https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9dc582374bf7ca00eccd131530664320

While this is even more surprising, it also illustrates that it can make a big performance difference. Making formatting slower to avoid correct-but-surprising results is a trade off. It might be a better trade off but that’s not obvious to me.

[gregates]

That's fair -- I don't expect them to match when the exponent is greater than the number of significant digits. A more precise way to put the desirable property would be "Fixed precision format and shortest format should match when they both terminate at a significant decimal digit".

[hanna-kruppe]

You mean when both have a fractional part? While that restriction may alleviate performance concerns (not a given! I don’t know the algorithms well enough to speculate) it also seems pretty artificial to me. Rounding to the nearest integer, or to the nearest multiple of 10^n, is also rounding. Scientific notation (which also accepts a precision) can move the decimal place in question across a decimal point. Indeed the current implementation generates decimal digits and a power of ten scaling factor first and decides how to print those afterwards. So I don’t see how you can make a principled distinction.

[hanna-kruppe]

And it’s not like the “shortest” output for floats that are whole numbers is less controversial or surprising, see #63171

[gregates]

I'm not quite following. What I mean is:

I understand that what the shortest algorithm and the fixed-precision algorithm print varies after all the significant decimal digits represented by the bits have been printed -- roughly, after f64::DIGITS, but sometimes 1 or 2 more -- and in those cases I don't expect them to match.

But when the number of digits printed is small enough that the two algorithms haven't diverged in that way, they sometimes don't match because they use a different tie-breaking rule for rounding when the remaining (non-significant) digits, if printed, would be 500000000.... In those cases, it seems like they should match.

I think that's a reasonable distinction to make.

[hanna-kruppe]

Putting it like that makes more sense to me, thanks for clarifying. However, I don’t know how to make that idea precise (without involving counterfactuals) and I don’t know what it would imply for the algorithms.