Float precision errors
See original GitHub issueWhen 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?
Issue Analytics
- State:
- Created 10 months ago
- Comments:9 (4 by maintainers)
Top Results From Across the Web
Floating-point error mitigation - Wikipedia
Floating -point error mitigation is the minimization of errors caused by the fact that real numbers cannot, in general, be accurately represented in...
Read more >Is floating point math broken? - Stack Overflow
The main cause of the error in floating point division is the division algorithms used to calculate the quotient. Most computer systems calculate...
Read more >What Every Computer Scientist Should Know About Floating ...
Another way to measure the difference between a floating-point number and the real number it is approximating is relative error, which is simply...
Read more >15. Floating Point Arithmetic: Issues and Limitations — Python ...
Representation error refers to the fact that some (most, actually) decimal fractions cannot be represented exactly as binary (base 2) fractions.
Read more >Floating point error in Python - GeeksforGeeks
It's a problem caused when the internal representation of floating-point numbers, which uses a fixed number of binary digits to represent a ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@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.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 useNumber.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
orstart
are non-integers (or ifsmoothSteps
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?