5

So I have a Javascript script which adds small fractions together in a loop and its possible that it will add 0.2 to 0.1. Then that value is fed to another function but the issue is I need 0.3 to be fed exactly and not 0.30000000000000004.

What is the simplest way to ensure the number is corrected and exact. Note that its possible to get 0.25+0.125 etc being added to simply rounding to 1 decimal won't fix the issue.

It is also possible to have 0.2 + 0.10000000000000004 being added although this is very, very unlikely!

Vinnie Gold
  • 53
  • 1
  • 8
  • 1
    0.25+0.125 is an unusual, and simple, case. Both values and their sum are exactly representable, so there is no rounding error. That is not the case for 0.3. The closest you can get is 0.299999999999999988897769753748434595763683319091796875. Is that close enough? – Patricia Shanahan Apr 08 '15 at 02:46
  • 1
    This isn't a solution but the dumber your math, the more accurate – Downgoat Apr 08 '15 at 02:47
  • 2
    How are your small numbers being made? you might be better multiplying everything by `1000` – Paul S. Apr 08 '15 at 02:48
  • you can use (parseFloat('0.1') + parseFloat('0.1')).toFixed(2); if you want n number of digits after decimal, add n to to fixed – suman Apr 08 '15 at 02:52
  • 1
    there is a similar question [here](http://stackoverflow.com/questions/1458633/how-to-deal-with-floating-point-number-precision-in-javascript), also check your [BigNumber](https://github.com/MikeMcl/bignumber.js/) – Downgoat Apr 08 '15 at 02:53
  • possible duplicate of [Is floating point math broken?](http://stackoverflow.com/questions/588004/is-floating-point-math-broken) – tmyklebu Apr 08 '15 at 03:20

1 Answers1

1

There is no simple method of avoiding rounding errors in general-purpose floating-point arithmetic. The number 0.3 does not have an exact binary floating-point representation.

I would suggest reading What Every Computer Scientist Should Know About Floating-Point Arithmetic to familiarize yourself with the trade-offs inherent to floating-point representation of numbers.

To actually solve your issue, you should ask yourself a few questions:

  • How strict is your requirement for precision? Why is 0.30000000000000004 outside your margin for error? Is it acceptable to round your results?
  • Is there any way you could represent your numbers and perform most of your arithmetic with integers? E.g. if you know that you'll only encounter rational numbers, they can be represented using an integer quotient and an integer denominator. From there, you can attempt to defer casting to float for as long as possible to prevent cumulative rounding errors.
  • If you cannot perform your calculations on integers, is there an alternate datatype you can use, such as BigDecimal?

Ultimately, when it comes to issues with floating-point precision, you'll often have to tailor the solution to the requirements posed by your specific issue.

George Bahij
  • 597
  • 2
  • 9