`bevy_core_widgets` slider precision rounding issues

[janis-bhm]

Bevy version and features

eed2e0ebe

[Optional] Relevant system information

rustc 1.91.0-nightly (523d3999d 2025-08-30)
6.12.44 x86_64 12th Gen Intel i5-12600K

What went wrong

negative exponents in SliderPrecision result in inaccurate numbers (e.g. 3999.999998 instead of 4000).
This can be fixed by multiplying by the reciprocal instead of dividing by the factor again, but then the same issue appears for positive exponents (e.g. 5.319999996 instead of 5.32).

    fn round(&self, value: f32) -> f32 {
        let factor = ops::powf(10.0_f32, self.0 as f32);
        let rounded = (value * factor).round();
        if self.0.is_positive() {
            rounded / factor
        } else {
            let recip = ops::powf(10.0_f32, -self.0 as f32);
            rounded * recip
        }
    }

this results in the right apparent numbers for both positive and negative exponents, but I'm not sure if this is in any way dependent on my machine/rustc/libm.

[alice-i-cecile]

We have deterministic math functions in https://github.com/bevyengine/bevy/blob/main/crates/bevy_math/src/ops.rs: use those when implementing this :) Other than that, I really like this fix and think it's worth doing.

[janis-bhm]

Well, now I can no longer reproduce this and am getting the expected result :<
maybe it makes sense to replace the .round() call with ops::round(_) but I think it makes more sense to fix this if it can be reproduced..

[torsteingrindvik]

One kinda related thing to this- why don't we just let users state instead of "round to nearest order of magnitude" just "round to nearest number"?

I might not want to round to 1/100, 1/10, 1, 10, 100 etc. but 10, 20, 30 or 25, 50, 75, etc.
Seems strangely restrictive