Fix Slider snapping precision issue (#8819)

[sachPundir]

Fixes #8819

Description

This PR fixes floating-point precision issues in Slider snapping when TickFrequency is used.

Due to double precision limitations, calculations such as:

19 * 0.1 → 1.9000000000000001

can produce small rounding errors that affect snapping behavior.

This change ensures the final snapped value is rounded to a stable precision to avoid floating-point artifacts while preserving existing Slider logic.

Rounding is applied only to the final snapped value and does not modify Minimum, Maximum, or TickFrequency. This ensures that real precision coming from Min/Max offsets is preserved.

For example:

Minimum = 0.5001
TickFrequency = 0.1

continues to correctly produce values like 1.9001.

The intent is to remove IEEE floating-point noise, not to change logical tick precision.

Customer Impact

Improves numerical stability of Slider snapping when fractional TickFrequency values are used, resulting in more predictable snapped values.

Regression

No — this addresses a long-standing floating-point precision behavior rather than a recently introduced regression.

Testing

• Reproduced the issue using a minimal WPF sample with fractional TickFrequency values (e.g., 0.1, 0.112).
• Confirmed incorrect snapping behavior prior to the fix due to floating-point precision artifacts.
• Verified corrected snapping behavior after the change across multiple ranges and tick frequencies.
• Tested slider movement in both increasing and decreasing directions.
• Tested with non-zero Minimum values to ensure correct offset handling.
• Tested with non-zero Minimum values to ensure correct offset handling.
• Validated behavior using values with multiple decimal places in a sample application to ensure stable snapping results.
• Tested values close to Minimum and Maximum limits.
• Ran the full WPF unit test suite locally — all tests pass.
• Confirmed no behavioral changes for integer TickFrequency scenarios.

Risk

Low.

The change only affects the final snapped value calculation and does not alter core Slider logic or public APIs.

Microsoft Reviewers: Open in CodeFlow

[miloush]

I don't think that's a correct approach, it will use wrong values if the tick frequency has higher precision, and the rounding number seems arbitrary.

[sachPundir]

@miloush, Thanks for the clarification — you're right that snapping must remain strictly “closest tick” and not bias toward the next one.

My intent was only to remove IEEE noise when the computed value is already on a tick (e.g., 1.9000000000000001).

I agree arbitrary rounding could affect higher-precision TickFrequency.

I’ll explore a solution based on tick-index rounding or DoubleUtil.AreClose so logical tick precision is preserved.

[sachPundir]

Thanks for the feedback — that makes sense.

I’ll add unit tests to cover snapping behavior and edge cases so we can validate the expected behavior more precisely before finalizing the fix.

[sachPundir]

I ran additional edge-case tests beyond the original unit tests to validate the behavior across different tick magnitudes.

Observations:

✅ The change improves decimal-grid snapping for common cases (e.g., 0.1, 0.0001) by eliminating visible floating-point artifacts such as 1.9000000000000001.
✅ Standard scenarios (integer ticks, fractional ticks, negative ranges, boundary cases) continue to behave correctly.
❌ However, the normalization step introduces precision loss for very small tick frequencies (e.g., 1e-12), where valid snapped values can collapse to 0 due to rounding.

Example:

• TickFrequency = 1e-12
• Expected: 4e-12
• Actual (with normalization): 0

Because of this regression, the current approach is not safe for all tick magnitudes. I am refining the solution to preserve small-tick precision while still addressing decimal-grid floating artifacts.

I’ll follow up with an updated approach shortly.

[sachPundir]

@dotnet-policy-service agree

[sachPundir]

I’ve updated the snapping reconstruction step to use decimal arithmetic when rebuilding the snapped tick value.

The rounding of the tick index remains unchanged. Previously, reconstructing the snapped value using double multiplication (e.g. 19 * 0.1) could introduce binary floating-point representation artifacts such as 1.9000000000000001.

This change keeps the existing snapping logic intact and replaces only the reconstruction step with decimal arithmetic. This eliminates representation noise for common base-10 tick frequencies (0.1, 0.01, 0.0001, etc.) while preserving full precision for high-precision tick frequencies (e.g. 1e-12).

A double-based fallback is retained for values outside the decimal range to avoid overflow.

Existing snapping behavior is unchanged apart from stabilizing the reconstructed value.

[sachPundir]

@dipeshmsft @miloush This PR fixes the slider snapping precision issue caused by floating point rounding when calculating tick values.

I verified the behavior using a Slider with TickFrequency and confirmed the corrected snapping logic resolves the precision problem.

Could you please review it when you have time? Happy to update the PR if any changes or additional tests are required.