0

I've been having an issue with my JavaScript code where in the final verification step of a form, it sums the values to determine whether or not their total sum is equivalent to 100. Normally, it works as intended, but occasionally it will indicate that there is an issue if, for example, the values are: 9.325210871602625 and 90.67478912839736. These values' sum should be accepted, yet it is not.

As far as I can tell, the calculations that are performed to acquire these values are correct so I do not believe that they are the source of error, and frankly there is far too much code involved in calculating their values to display here anyway.

Obviously I could just loosen the requirements so that any value that falls in the range of (99.99 - 100.01) would be accepted such as:

let valuesOK = sumValues("example") > 99.99 && sumValues("example1") < 100.01;

but that doesn't seem like a proper solution.

My only theory is that because both numbers have 16 digits in the case that I provided (9.325210871602625 and 90.67478912839736), however because 9.325... has one extra decimal place than 90.674..., that that may be causing problems when adding them together. Regardless, I'm not sure how to elegantly solve that issue if my theory is indeed correct.

I'd appreciate any help or references to documentation that might make sense of my issue.

kj.arch
  • 15
  • 4
  • Why would you think the sum of 9.325210871602625 and 90.67478912839736 should be 100? As shown, one ends in 5 and the other in 6, so clearly the sum of the numbers shown would end in 1, not 0. The actual full values are 9.325210871602624962406480335630476474761962890625 and 90.6747891283973643794524832628667354583740234375, which end in 625 and 750 (accounting for the digit positions), so their sum would end in …375, which cannot be 100.0000… When you add them with the required floating-point rounding, the result is 99.9999999999999857891452847979962825775146484375. Why do you expect 100? – Eric Postpischil Jun 24 '22 at 11:02
  • @EricPostpischil I'm expecting 100 because I'm dealing with percents. In the case of the two numbers I gave as example, 9.325... has one extra decimal place, so you should not be looking at the last digit. I think this is mainly an issue with precision, because it could be a few additional decimal places would have allowed the total to be 100 as far as JS is concerned. – kj.arch Jun 24 '22 at 20:51
  • So the problem is not that 9.325210871602625 and 9.325210871602625 do not add to 100 but that you expected to get two numbers that did add to 100. That is generally not a reasonable expectation when working with floating-point numbers. Floating-point arithmetic is **designed** to approximate real-number arithmetic, so it is expected we will often get numbers that differ from what would be obtained with real-number arithmetic. You should design your code to accept that. – Eric Postpischil Jun 24 '22 at 20:54
  • @EricPostpischil Thanks for the response. I guess I should read up on floating point numbers, in that case. I'd imagine there's still a better more elegant solution than the one I've already thought of, but I'll have to figure that one out myself. – kj.arch Jun 24 '22 at 21:03

0 Answers0