Improve handling of decimal min/max inputs and fractional step values

[HUSSTECH]

Changes to handle non-integer numbers. Some of the Math.* functions produce Numeric outputs that can vary slightly (due to floating point inaccuracies), such that some of the equality and inequality tests in the library will return a fail value, and valid updates are blocked.

fixes #104

• Introduction of clamp method into the step calculation function so that slider values are always within a valid range
• test case "decimal min/max values that round up allow slider movement from end limits" added

fixes #23

• when calculating the new step difference via the length function, round to the precision of the supplied step value. This stops floating point inaccuracies from preventing valid updates
• test case "fractional steps reach the end of the range" added

[LuciRebecca]

We've run into the same thing here - any news on if/when this will be merged in?

[HUSSTECH]

Unfortunately I've had no word back from the lead maintainer. First time checking back to this PR in while after getting an alert from your comment @LuciRebecca. Looks like there was a new version pushed in Jan this year, but not including this change.

I'm currently running this PR code version in production as a package from my own repo, which with yarn is quite painless to do thankfully. But I'm also waiting for the day I may be able to go back to the npm package! 🙂

[tsi]

4 years later.
Getting similar issues of skipped updates, probably due to floating point inaccuracies.
Seems like this is still an issue...