Float precision errors

When I use noUiSlider.set to update the value to an int, I still sometimes get errors where JS creates a bad float when handing the value back to me:

Is there a way to avoid that, is there something you can fix, or do I have to live with it and always do rounding?

[leongersen]

@andrewsm80 I’m open to a PR that sets the format option internally to Math.round if the arguments to start and step are integers.

[andrewsm80]

The core problem really isn’t about formatting, the problem is rather about constraining the actual value of the slider. I really can’t think of a better API – returning non-integer values when { step: <integer>, start: <integer> } is semantically incorrect, and requiring anything additional to { step: <integer>, start: <integer> } to specify that we want only integers is redundant.

The lack of an explicit int type in the language is not an obstacle here. Number is a floating-point type (as per the language specification) capable of distinctly storing both integer and non-integer values. Simply use Number.isSafeInteger() to find out if it’s storing an integer value.

If the programmer configures the slider with { step: 1.0, start: 10.0, smoothSteps: false }, then the slider value should never be 10.00001. You could prevent that within the library internals by rounding the computed slider value when the handle is moved.

If either step or start are non-integers (or if smoothSteps is enabled), all bets are off – perfectly accurate slider movement can no longer be guaranteed. But otherise, it can and I don’t see any reason not to.

The problem is especially severe because it only happens some of the time. The programmer configures an integer-valued slider and prints the value to the screen somewhere, and it works 99% of the time. But if the range is just so then suddenly a field like “Persons attending event” becomes “9.99999999998”. How silly. Yes, it can be mitigated by requiring the programmer to manually round the value, but the programmer has to be aware of this surprising behavior. Why require that? What downside could there be to rounding the value in such cases before providing it to the users of this library?