3 ms·
division is always going to give something fiddly - if it realy divides and store result (integer cents) and not storing fractions. (a/3 ) * 3 + (b/3 ) * 3 + (
by svilen_dobrev 4y ago
division is always going to give something fiddly - if it realy divides and store result (integer cents) and not storing fractions.
(a/3 ) * 3 + (b/3 ) * 3 + (c/3 ) * 3 is not going to be same as a+b+c.
(the * 3 , then summing-up parts, can happen years later after the a/3 parts)
So financialy, the last thing in a sum is calculated as remainder. Not as additive. e.g. the (c/3) *3 is "calculated" as a+b+c - the-other-two.
i.e. 33+33+33... doesnt do 100. so the last 33 is actualy 100-33-33 = 34.
Which is technicaly incorrect - but .. that's life.
Now, which one to choose to be the victim.. there are variants..
- fedeb95 4y agoThis I knew as well and have used in the past. It's perfectly fine if you do calculations in only one direction, say from amounts to percentages. This algorithm guarantees you that the sum of percentages (in this case) is 1 regardless of division errors. It doesn't work if you want coherence between amounts and amounts calculated from percentages derived from those amounts, because you're cumulating errors. Edit: never mind, the code I tested it was wrong, this way works. However the advantage over just increasing precision is unclear to me (in the coherence between back and forth scenario)