Round totals rather than expense by expense #88
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem statement
As raised in #85, balances get a bit weird when they are not equally divisible between all participants.
Current logic does rounding on an expense by expense basis, which ends up with some inconsistencies. I made three groups with three users each, which I then added ten $10 expenses to, and wound up with the following results:
Images
So it's not only about who pays for expenses, but also the order of the users has an impact on who pays what (poor, poor Jack…).
This seems inherently incorrect/unfair, so I set out to try to fix the calculations.
Proposed solution 1
Since there is nothing wrong with the general setup of calculating the balances, I just tried to change the rounding parts and leave the rest as is.
Do not do any rounding when calculating balances, instead only do rounding once the totals for each user has been calculated.
Issues with the solution
I noticed that sometimes the balances got offset by
0.01
(+16.67
/-16.66
), which looked ugly (and perhaps confusing). Furthermore, when all the reimbursements were done, the extra0.01
was still left as a positive balance, even though no reimbursements were listed.Proposed solution 2 (the one implemented in this PR)
Instead of using the balances as they are, use them to calculate the reimbursements just like before, but then construct something I called "public balances" from those reimbursements, making sure that the balances will always show the same amounts as the reimbursements
Issues with the solution
Another round trip over the reimbursements/balances is needed. While this is not a huge operation, it does scale with users, so very large groups needs a bit more processing.
I have a hard time seeing groups with thousands of users, but maybe they do exist.
Issues
Closes #85 when merged