Don't show unexpected decimals for range slider value

[dimwight]

Fixes #6424

Why is this the best possible solution? Were any other approaches considered?

Code improvement seems to fix issue; see Design detail below.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Issue behaviour has disappeared; passes new and all existing tests.

Do we need any specific form for testing your changes? If so, please attach one.

6424.xml.txt demonstrates issue and fix.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

Design detail

In RangeDecimalWidget, setUpActualValueLabel checks the slider stepSize and if less than 1 applies BigDecimal.setScale to actualValue; parameter newScale is set to 3 to allow a one-eighth step ie 0.125.

In RangeDecimalWidgetTest, setup enables trapping the issue by setting getRangeStep to return 0.1, which doesn't affect any of the existing tests.

New changingSliderValueToAnIntermediate_setsTheValueCorrectly is modelled on changingSliderValueToAnyOtherThanTheMinOne_setsTheValueCorrectly. By calling new clickOnFractionalValue in SliderExt it sets a value that traps the issue.

[lognaturel]

Thanks for looking at this! It'd be helpful to make sure we know the root cause so we can identify the best fix. More inline.

[lognaturel]

There's nothing special about a step size less than 1 as far as I can tell! Floating point precision issues can happen with any step sizes that involve decimal values. I don't know how likely this is but it would be possible to have a step size of 1.3, for example.

Have you been able to determine the underlying issue? I originally thought it was an arithmetic issue but looking at the example on the forum, I'm not sure about that anymore. Is it possible that we are calling BigDecimal(double) somewhere? If so, that could be the issue and we might need to call BigDecimal(string) instead. See https://stackoverflow.com/questions/46828044/bigdecimal-not-giving-exact-output-in-java

I think that's the most likely culprit and that it can be fixed upstream of this method. If you determine that it is in fact an arithmetic issue, then the setScale approach may be appropriate. I think we'd want to use the scale of the stepsize instead of hardcoding it to 3, though.

[dimwight]

Thanks for alerting me to the root cause of the issue being the BigDecimal created in RangeWidgetUtils by getActualValue, which is currently called from both RangeDecimalWidget and RangeIntegerWidget.

Since the code of these classes is more or less identical, it can be pushed up into superclass RangeBaseWidget with a constructor parameter to switch the detail differences.

This enables getActualValue just to pass through the float received from the slider, and setUpActualValueLabel can then be adjusted to suit.