fix rounding issue with exponents in fmt

[mj10021]

fixes issue #115737 , where the decimal places are rounded incorrectly when formatting scientific notation

[rustbot]

r? @cuviper

(rustbot has picked a reviewer for you, use r? to override)

[cuviper]

Aren't we supposed to be rounding ties toward even? So this would be "1.98e3", and many others would round down too.

[mj10021]

Is round to even spec'd in a doc? I was trying to keep the same behavior as before using https://doc.rust-lang.org/std/fmt/#precision as a reference for desired behavior based on the discussion here: https://users.rust-lang.org/t/scientific-notation-decimal-places/99682/5

[cuviper]

Sort of -- it's specified for operations on the f32 page, and the f64 page just references that.

When the number resulting from a primitive operation (addition, subtraction, multiplication, or division) on this type is not exactly representable as f32, it is rounded according to the roundTiesToEven direction defined in IEEE 754-2008.

We do seem to do this for fractional formatting as well:

fn main() {
    println!("{:.2e}", 1.625);
    println!("{:.2e}", 16.25);
    println!("{:.2e}", 162.5);
    println!("{:.2e}", 1625);
    println!("{:.2e}", 16250);
}

Note that my choice of input values are represented precisely at all levels, so there's no ambiguity that these should be ties. The first three do round down to even, but the last two are rounding up.

1.62e0
1.62e1
1.62e2
1.63e3
1.63e4

(although I tested that on the playground, not your code.)

[mj10021]

Ah, I see what you're saying. Since the bug submitted was the number of digits expressed, would it be ok for me to take out the assert!s that enforce the non round-to-even behavior and then work on the rounding in a follow up PR?

[cuviper]

If you're willing to work on both, I'd rather do it all at once so they can land in the same release, and we only have to explain changes once. :)

[mj10021]

gotcha 🙂 i think what I just pushed rounds to evens on a tie correctly now

[cuviper]

You don't need to isolate the last digit to know that it's odd.

Suggested change

	let last_digit_odd = (n % 10) % 2 != 0;
	let last_digit_odd = n % 2 != 0;

[cuviper]

Hmm, doesn't this only tell you that you overflowed the least significant digit? e.g. maybe n=129 rolled up to 130, but that doesn't need any adjustment. For a new power of 10, like n=99 to 100, maybe something like n.log10() > (n - 1).log10() would work?

[cuviper]

Sorry I keep noticing things, but I think we're almost there...

The check for even here is missing whether we removed any additional non-zero digits earlier. e.g., for {:.1e} I expect:

• 124999 => 1.2e5 (rounded down)
• 125000 => 1.2e5 (tie rounded down to even)
• 125001 => 1.3e5 (rounded up)
  • This one gets treated like a tie right now and prints 1.2e5
• 134999 1.3e5 (rounded down)
• 135000 1.4e5 (tie rounded up to even)
• 135001 1.4e5 (rounded up)

I think subtracted_precision > 1 would account for the extra non-zero digits? Please do add these values as tests.

[cuviper]

The more I look at this giant list of tests, the less I'm sure of its value. There are certainly some edge cases in here that we want to keep, but many are duplicating the exact same conditions. This makes it hard to see whether we actually have a test corresponding to the different pieces of the implementation.

For example, is there a test that exercises the power-of-10 overflow that we checked last time? I'm not sure.

Can we narrow it down to fewer targeted tests around different boundary conditions?

[cuviper]

Another possibility could be an exhaustive test comparing to the independent floating point implementation. Like, check all i16 values compared to the same f32 value, formatted to a few different levels of precision.

[cuviper]

    for i in i16::MIN..=i16::MAX {
        for p in 0..=5 {
            assert_eq!(
                format!("{i:.p$e}"),
                format!("{:.p$e}", f32::from(i)),
                "integer {i} at precision {p}"
            );
        }
    }

[cuviper]

LGTM, thanks!

@bors r+
@rustbot label +relnotes

[bors]

📌 Commit 3f0908f has been approved by cuviper

It is now in the queue for this repository.

[bors]

⌛ Testing commit 3f0908f with merge b917524...

[bors]

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing b917524 to master...

[rust-timer]

Finished benchmarking commit (b917524): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.8%, 0.8%]	1
Regressions ❌ (secondary)	3.2%	[0.8%, 6.0%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.0%, -2.0%]	1
All ❌✅ (primary)	0.8%	[0.8%, 0.8%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	-0.7%	[-0.7%, -0.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 674.708s -> 674.219s (-0.07%)
Artifact size: 311.11 MiB -> 311.04 MiB (-0.02%)