Algorithm to share/settle expenses among a group - algorithm
I am looking forward for an algorithm for the below problem.
Problem: There will be a set of people who owe each other some money or none. Now, I need an algorithm (the best and neat) to settle expense among this group.
Person AmtSpent
------ ---------
A 400
B 1000
C 100
Total 1500
Now, expense per person is 1500/3 = 500. Meaning B to give A 100. B to give C 400. I know, I can start with the least spent amount and work forward.
Can some one point me the best one if you have.
To sum up,
Find the total expense, and expense per head.
Find the amount each owe or outstanding (-ve denote outstanding).
Start with the least +ve amount. Allocate it to the -ve amount.
Keep repeating step 3, until you run out of -ve amount.
s. Move to next bigger +ve number. Keep repeating 3 & 4 until there are +ve numbers.
Or is there any better way to do?
The best way to get back to zero state (minimum number of transactions) was covered in this question here.
I have created an Android app which solves this problem. You can input expenses during the trip, it even recommends you "who should pay next". At the end it calculates "who should send how much to whom". My algorithm calculates minimum required number of transactions and you can setup "transaction tolerance" which can reduce transactions even further (you don't care about $1 transactions) Try it out, it's called Settle Up:
https://market.android.com/details?id=cz.destil.settleup
Description of my algorithm:
I have basic algorithm which solves the problem with n-1 transactions, but it's not optimal. It works like this: From payments, I compute balance for each member. Balance is what he paid minus what he should pay. I sort members according to balance increasingly. Then I always take the poorest and richest and transaction is made. At least one of them ends up with zero balance and is excluded from further calculations. With this, number of transactions cannot be worse than n-1. It also minimizes amount of money in transactions. But it's not optimal, because it doesn't detect subgroups which can settle up internally.
Finding subgroups which can settle up internally is hard. I solve it by generating all combinations of members and checking if sum of balances in subgroup equals zero. I start with 2-pairs, then 3-pairs ... (n-1)pairs. Implementations of combination generators are available. When I find a subgroup, I calculate transactions in the subgroup using basic algorithm described above. For every found subgroup, one transaction is spared.
The solution is optimal, but complexity increases to O(n!). This looks terrible but the trick is there will be just small number of members in reality. I have tested it on Nexus One (1 Ghz procesor) and the results are: until 10 members: <100 ms, 15 members: 1 s, 18 members: 8 s, 20 members: 55 s. So until 18 members the execution time is fine. Workaround for >15 members can be to use just the basic algorithm (it's fast and correct, but not optimal).
Source code:
Source code is available inside a report about algorithm written in Czech. Source code is at the end and it's in English:
https://web.archive.org/web/20190214205754/http://www.settleup.info/files/master-thesis-david-vavra.pdf
You have described it already. Sum all the expenses (1500 in your case), divide by number of people sharing the expense (500). For each individual, deduct the contributions that person made from the individual share (for person A, deduct 400 from 500). The result is the net that person "owes" to the central pool. If the number is negative for any person, the central pool "owes" the person.
Because you have already described the solution, I don't know what you are asking.
Maybe you are trying to resolve the problem without the central pool, the "bank"?
I also don't know what you mean by "start with the least spent amount and work forward."
Javascript solution to the accepted algorithm:
const payments = {
John: 400,
Jane: 1000,
Bob: 100,
Dave: 900,
};
function splitPayments(payments) {
const people = Object.keys(payments);
const valuesPaid = Object.values(payments);
const sum = valuesPaid.reduce((acc, curr) => curr + acc);
const mean = sum / people.length;
const sortedPeople = people.sort((personA, personB) => payments[personA] - payments[personB]);
const sortedValuesPaid = sortedPeople.map((person) => payments[person] - mean);
let i = 0;
let j = sortedPeople.length - 1;
let debt;
while (i < j) {
debt = Math.min(-(sortedValuesPaid[i]), sortedValuesPaid[j]);
sortedValuesPaid[i] += debt;
sortedValuesPaid[j] -= debt;
console.log(`${sortedPeople[i]} owes ${sortedPeople[j]} $${debt}`);
if (sortedValuesPaid[i] === 0) {
i++;
}
if (sortedValuesPaid[j] === 0) {
j--;
}
}
}
splitPayments(payments);
/*
C owes B $400
C owes D $100
A owes D $200
*/
I have recently written a blog post describing an approach to solve the settlement of expenses between members of a group where potentially everybody owes everybody else, such that the number of payments needed to settle the debts is the least possible. It uses a linear programming formulation. I also show an example using a tiny R package that implements the solution.
I had to do this after a trip with my friends, here's a python3 version:
import numpy as np
import pandas as pd
# setup inputs
people = ["Athos", "Porthos", "Aramis"] # friends names
totals = [300, 150, 90] # total spent per friend
# compute matrix
total_spent = np.array(totals).reshape(-1,1)
share = total_spent / len(totals)
mat = (share.T - share).clip(min=0)
# create a readable dataframe
column_labels = [f"to_{person}" for person in people]
index_labels = [f"{person}_owes" for person in people]
df = pd.DataFrame(data=mat, columns=column_labels, index=index_labels)
df.round(2)
Returns this dataframe:
to_Athos
to_Porthos
to_Aramis
Athos_owes
0
0
0
Porthos_owes
50
0
0
Aramis_owes
70
20
0
Read it like: "Porthos owes $50 to Athos" ....
This isn't the optimized version, this is the simple version, but it's simple code and may work in many situations.
I'd like to make a suggestion to change the core parameters, from a UX-standpoint if you don't mind terribly.
Whether its services or products being expensed amongst a group, sometimes these things can be shared. For example, an appetizer, or private/semi-private sessions at a conference.
For things like an appetizer party tray, it's sort of implied that everyone has access but not necessarily that everyone had it. To charge each person to split the expense when say, only 30% of the people partook can cause contention when it comes to splitting the bill. Other groups of people might not care at all. So from an algorithm standpoint, you need to first decide which of these three choices will be used, probably per-expense:
Universally split
Split by those who partook, evenly
Split by proportion per-partaker
I personally prefer the second one in-general because it has the utility to handle whole-expense-ownership for expenses only used by one person, some of the people, and the whole group too. It also remedies the ethical question of proportional differences with a blanket generalization of, if you partook, you're paying an even split regardless of how much you actually personally had. As a social element, I would consider someone who had a "small sample" of something just to try it and then decided not to have anymore as a justification to remove that person from the people splitting the expense.
So, small-sampling != partaking ;)
Then you take each expense and iterate through the group of who partook in what, and atomically handle each of those items, and at the end provide a total per-person.
So in the end, you take your list of expenses and iterate through them with each person. At the end of the individual expense check, you take the people who partook and apply an even split of that expense to each person, and update each person's current split of the bill.
Pardon the pseudo-code:
list_of_expenses[] = getExpenseList()
list_of_agents_to_charge[] = getParticipantList()
for each expense in list_of_expenses
list_of_partakers[] = getPartakerList(expense)
for each partaker in list_of_partakers
addChargeToAgent(expense.price / list_of_partakers.size, list_of_agents_to_charge[partaker])
Then just iterate through your list_of_agents_to_charge[] and report each total to each agent.
You can add support for a tip by simply treating the tip like an additional expense to your list of expenses.
Straightforward, as you do in your text:
Returns expenses to be payed by everybody in the original array.
Negativ values: this person gets some back
Just hand whatever you owe to the next in line and then drop out. If you get some, just wait for the second round. When done, reverse the whole thing. After these two round everybody has payed the same amount.
procedure SettleDepth(Expenses: array of double);
var
i: Integer;
s: double;
begin
//Sum all amounts and divide by number of people
// O(n)
s := 0.0;
for i := Low(Expenses) to High(Expenses) do
s := s + Expenses[i];
s := s / (High(Expenses) - Low(Expenses));
// Inplace Change to owed amount
// and hand on what you owe
// drop out if your even
for i := High(Expenses) downto Low(Expenses)+1 do begin
Expenses[i] := s - Expenses[i];
if (Expenses[i] > 0) then begin
Expenses[i-1] := Expenses[i-1] + Expenses[i];
Expenses.Delete(i);
end else if (Expenses[i] = 0) then begin
Expenses.Delete(i);
end;
end;
Expenses[Low(Expenses)] := s - Expenses[Low(Expenses)];
if (Expenses[Low(Expenses)] = 0) then begin
Expenses.Delete(Low(Expenses));
end;
// hand on what you owe
for i := Low(Expenses) to High(Expenses)-1 do begin
if (Expenses[i] > 0) then begin
Expenses[i+1] := Expenses[i+1] + Expenses[i];
end;
end;
end;
The idea (similar to what is asked but with a twist/using a bit of ledger concept) is to use Pool Account where for each bill, members either pay to the Pool or get from the Pool.
e.g.
in below attached image, the Costco expenses are paid by Mr P and needs $93.76 from Pool and other members pay $46.88 to the pool.
There are obviously better ways to do it. But that would require running a NP time complexity algorithm which could really show down your application. Anyways, this is how I implemented the solution in java for my android application using Priority Queues:
class calculateTransactions {
public static void calculateBalances(debtors,creditors) {
// add members who are owed money to debtors priority queue
// add members who owe money to others to creditors priority queue
}
public static void calculateTransactions() {
results.clear(); // remove previously calculated transactions before calculating again
PriorityQueue<Balance> debtors = new PriorityQueue<>(members.size(),new BalanceComparator()); // debtors are members of the group who are owed money, balance comparator defined for max priority queue
PriorityQueue<Balance> creditors = new PriorityQueue<>(members.size(),new BalanceComparator()); // creditors are members who have to pay money to the group
calculateBalances(debtors,creditors);
/*Algorithm: Pick the largest element from debtors and the largest from creditors. Ex: If debtors = {4,3} and creditors={2,7}, pick 4 as the largest debtor and 7 as the largest creditor.
* Now, do a transaction between them. The debtor with a balance of 4 receives $4 from the creditor with a balance of 7 and hence, the debtor is eliminated from further
* transactions. Repeat the same thing until and unless there are no creditors and debtors.
*
* The priority queues help us find the largest creditor and debtor in constant time. However, adding/removing a member takes O(log n) time to perform it.
* Optimisation: This algorithm produces correct results but the no of transactions is not minimum. To minimize it, we could use the subset sum algorithm which is a NP problem.
* The use of a NP solution could really slow down the app! */
while(!creditors.isEmpty() && !debtors.isEmpty()) {
Balance rich = creditors.peek(); // get the largest creditor
Balance poor = debtors.peek(); // get the largest debtor
if(rich == null || poor == null) {
return;
}
String richName = rich.name;
BigDecimal richBalance = rich.balance;
creditors.remove(rich); // remove the creditor from the queue
String poorName = poor.name;
BigDecimal poorBalance = poor.balance;
debtors.remove(poor); // remove the debtor from the queue
BigDecimal min = richBalance.min(poorBalance);
// calculate the amount to be send from creditor to debtor
richBalance = richBalance.subtract(min);
poorBalance = poorBalance.subtract(min);
HashMap<String,Object> values = new HashMap<>(); // record the transaction details in a HashMap
values.put("sender",richName);
values.put("recipient",poorName);
values.put("amount",currency.charAt(5) + min.toString());
results.add(values);
// Consider a member as settled if he has an outstanding balance between 0.00 and 0.49 else add him to the queue again
int compare = 1;
if(poorBalance.compareTo(new BigDecimal("0.49")) == compare) {
// if the debtor is not yet settled(has a balance between 0.49 and inf) add him to the priority queue again so that he is available for further transactions to settle up his debts
debtors.add(new Balance(poorBalance,poorName));
}
if(richBalance.compareTo(new BigDecimal("0.49")) == compare) {
// if the creditor is not yet settled(has a balance between 0.49 and inf) add him to the priority queue again so that he is available for further transactions
creditors.add(new Balance(richBalance,richName));
}
}
}
}
I've created a React App that implements Bin-packing approach to split trip expenses among friends with least number of transactions.
Check out the TypeScript file SplitPaymentCalculator.ts implementing the same.
You can find the working app's link on the homepage of the repo.
Related
Algorithm to calculate sum of points for groups with varying member count [closed]
Closed. This question needs debugging details. It is not currently accepting answers. Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question. Closed 6 years ago. Improve this question Let's start with an example. In Harry Potter, Hogwarts has 4 houses with students sorted into each house. The same happens on my website and I don't know how many users are in each house. It could be 20 in one house 50 in another and 100 in the third and fourth. Now, each student can earn points on the website and at the end of the year, the house with the most points will win. But it's not fair to "only" do a sum of the points, as the house with a 100 students will have a much higher chance to win, as they have more users to earn points. So I need to come up with an algorithm which is fair. You can see an example here: https://worldofpotter.dk/points What I do now is to sum all the points for a house, and then divide it by the number of users who have earned more than 10 points. This is still not fair, though. Any ideas on how to make this calculation more fair? Things we need to take into account: * The percent of users earning points in each house * Few users earning LOTS of points * Many users earning FEW points (It's not bad earning few points. It still counts towards the total points of the house) Link to MySQL dump(with users, houses and points): https://worldofpotter.dk/wop_points_example.sql Link to CSV of points only: https://worldofpotter.dk/points.csv
I'd use something like Discounted Cumulative Gain which is used for measuring the effectiveness of search engines. The concept is as it follows: FUNCTION evalHouseScore (0_INDEXED_SORTED_ARRAY scores): score = 0; FOR (int i = 0; i < scores.length; i++): score += scores[i]/log2(i); END_FOR RETURN score; END_FUNCTION; This must be somehow modified as this way of measuring focuses on the first result. As this is subjective you should decide on your the way you would modify it. Below I'll post the code which some constants which you should try with different values: FUNCTION evalHouseScore (0_INDEXED_SORTED_ARRAY scores): score = 0; FOR (int i = 0; i < scores.length; i++): score += scores[i]/log2(i+K); END_FOR RETURN L*score; END_FUNCTION Consider changing the logarithm. Tests: int[] g = new int[] {758,294,266,166,157,132,129,116,111,88,83,74,62,60,60,52,43,40,28,26,25,24,18,18,17,15,15,15,14,14,12,10,9,5,5,4,4,4,4,3,3,3,2,1,1,1,1,1}; int[] s = new int[] {612,324,301,273,201,182,176,139,130,121,119,114,113,113,106,86,77,76,65,62,60,58,57,54,54,42,42,40,36,35,34,29,28,23,22,19,17,16,14,14,13,11,11,9,9,8,8,7,7,7,6,4,4,3,3,3,3,2,2,2,2,2,2,2,1,1,1}; int[] h = new int[] {813,676,430,382,360,323,265,235,192,170,107,103,80,70,60,57,43,41,21,17,15,15,12,10,9,9,9,8,8,6,6,6,4,4,4,3,2,2,2,1,1,1}; int[] r = new int[] {1398,1009,443,339,242,215,210,205,177,168,164,144,144,92,85,82,71,61,58,47,44,33,21,19,18,17,12,11,11,9,8,7,7,6,5,4,3,3,3,3,2,2,2,1,1,1,1}; The output is for different offsets: 1182 1543 1847 2286 904 1231 1421 1735 813 1120 1272 1557
It sounds like some sort of constraint between the houses may need to be introduced. I might suggest finding the person that earned the most points out of all the houses and using it as the denominator when rolling up the scores. This will guarantee the max value of a user's contribution is 1, then all the scores for a house can be summed and then divided by the number of users to normalize the house's score. That should give you a reasonable comparison. It does introduce issues with low numbers of users in a house that are high achievers in which you may want to consider lower limits to the number of house members. Another technique may be to introduce handicap scores for users to balance the scales. The algorithm will most likely flex over time based on the data you receive. To keep it fair it will take some responsive action after the initial iteration. Players can come up with some creative ways to make scoring systems work for them. Here is some pseudo-code in PHP that you may use: <?php $mostPointsEarned; // Find the user that earned the most points $houseScores = []; foreach ($houses as $house) { $numberOfUsers = 0; $normalizedScores = []; foreach ($house->getUsers() as $user) { $normalizedScores[] = $user->getPoints() / $mostPointsEarned; $numberOfUsers++; } $houseScores[] = array_sum($normalizedScores) / $numberOfUsers; } var_dump($houseScores);
You haven't given any examples on what should be preferred state, and what are situations against which you want to be immune. (3,2,1,1 compared to 5,2 etc.) It's also a pity you haven't provided us the dataset in some nice way to play. scala> val input = Map( // as seen on 2016-09-09 14:10 UTC on https://worldofpotter.dk/points 'G' -> Seq(758,294,266,166,157,132,129,116,111,88,83,74,62,60,60,52,43,40,28,26,25,24,18,18,17,15,15,15,14,14,12,10,9,5,5,4,4,4,4,3,3,3,2,1,1,1,1,1), 'S' -> Seq(612,324,301,273,201,182,176,139,130,121,119,114,113,113,106,86,77,76,65,62,60,58,57,54,54,42,42,40,36,35,34,29,28,23,22,19,17,16,14,14,13,11,11,9,9,8,8,7,7,7,6,4,4,3,3,3,3,2,2,2,2,2,2,2,1,1,1), 'H' -> Seq(813,676,430,382,360,323,265,235,192,170,107,103,80,70,60,57,43,41,21,17,15,15,12,10,9,9,9,8,8,6,6,6,4,4,4,3,2,2,2,1,1,1), 'R' -> Seq(1398,1009,443,339,242,215,210,205,177,168,164,144,144,92,85,82,71,61,58,47,44,33,21,19,18,17,12,11,11,9,8,7,7,6,5,4,3,3,3,3,2,2,2,1,1,1,1) ) // and the results on the website were: 1. R 1951, 2. H 1859, 3. S 990, 4. G 954 Here is what I thought of: def singleValuedScore(individualScores: Seq[Int]) = individualScores .sortBy(-_) // sort from most to least .zipWithIndex // add indices e.g. (best, 0), (2nd best, 1), ... .map { case (score, index) => score * (1 + index) } // here is the 'logic' .max input.mapValues(singleValuedScore) res: scala.collection.immutable.Map[Char,Int] = Map(G -> 1044, S -> 1590, H -> 1968, R -> 2018) The overall positions would be: Ravenclaw with 2018 aggregated points Hufflepuff with 1968 Slytherin with 1590 Gryffindor with 1044 Which corresponds to the ordering on that web: 1. R 1951, 2. H 1859, 3. S 990, 4. G 954. The algorithms output is maximal product of score of user and rank of the user within a house. This measure is not affected by "long-tail" of users having low score compared to the active ones. There are no hand-set cutoffs or thresholds. You could experiment with the rank attribution (score * index or score * Math.sqrt(index) or score / Math.log(index + 1) ...)
I take it that the fair measure is the number of points divided by the number of house members. Since you have the number of points, the exercise boils down to estimate the number of members. We are in short supply of data here as the only hint we have on member counts is the answers on the website. This makes us vulnerable to manipulation, members can trick us into underestimating their numbers. If the suggested estimation method to "count respondents with points >10" would be known, houses would only encourage the best to do the test to hide members from our count. This is a real problem and the only thing I will do about it is to present a "manipulation indicator". How could we then estimate member counts? Since we do not know anything other than test results, we have to infer the propensity to do the test from the actual results. And we have little other to assume than that we would have a symmetric result distribution (of the logarithm of the points) if all members tested. Now let's say the strong would-be respondents are more likely to actually test than weak would-be respondents. Then we could measure the extra dropout ratio for the weak by comparing the numbers of respondents in corresponding weak and strong test-point quantiles. To be specific, of the 205 answers, there are 27 in the worst half of the overall weakest quartile, while 32 in the strongest half of the best quartile. So an extra 5 respondents of the very weakest have dropped out from an assumed all-testing symmetric population, and to adjust for this, we are going to estimate member count from this quantile by multiplying the number of responses in it by 32/27=about 1.2. Similarly, we have 29/26 for the next less-extreme half quartiles and 41/50 for the two mid quartiles. So we would estimate members by simply counting the number of respondents but multiplying the number of respondents in the weak quartiles mentioned above by 1.2, 1.1 and 0.8 respectively. If however any result distribution within a house would be conspicuously skewed, which is not the case now, we would have to suspect manipulation and re-design our member count. For the sample at hand however, these adjustments to member counts are minor, and yields the same house ranks as from just counting the respondents without adjustments.
I got myself to amuse me a little bit with your question and some python programming with some random generated data. As some people mentioned in the comments you need to define what is fairness. If as you said you don't know the number of people in each of the houses, you can use the number of participations of each house, thus you motivate participation (it can be unfair depending on the number of people of each house, but as you said you don't have this data on the first place). The important part of the code is the following. import numpy as np from numpy.random import randint # import random int # initialize random seed np.random.seed(4) houses = ["Gryffindor","Slytherin", "Hufflepuff", "Ravenclaw"] houses_points = [] # generate random data for each house for _ in houses: # houses_points.append(randint(0, 100, randint(60,100))) houses_points.append(randint(0, 50, randint(2,10))) # count participation houses_participations = [] houses_total_points = [] for house_id in xrange(len(houses)): houses_total_points.append(np.sum(houses_points[house_id])) houses_participations.append(len(houses_points[house_id])) # sum the total number of participations total_participations = np.sum(houses_participations) # proposed model with weighted total participation points houses_partic_points = [] for house_id in xrange(len(houses)): tmp = houses_total_points[house_id]*houses_participations[house_id]/total_participations houses_partic_points.append(tmp) The results of this method are the following: House Points per Participant Gryffindor: [46 5 1 40] Slytherin: [ 8 9 39 45 30 40 36 44 38] Hufflepuff: [42 3 0 21 21 9 38 38] Ravenclaw: [ 2 46] House Number of Participations per House Gryffindor: 4 Slytherin: 9 Hufflepuff: 8 Ravenclaw: 2 House Total Points Gryffindor: 92 Slytherin: 289 Hufflepuff: 172 Ravenclaw: 48 House Points weighted by a participation factor Gryffindor: 16 Slytherin: 113 Hufflepuff: 59 Ravenclaw: 4 You'll find the complete file with printing results here (https://gist.github.com/silgon/5be78b1ea0b55a20d90d9ec3e7c515e5).
You should enter some more rules to define the fairness. Idea 1 You could set up the rule that anyone has to earn at least 10 points to enter the competition. Then you can calculate the average points for each house. Positive: Everyone needs to show some motivation. Idea 2 Another approach would be to set the rule that from each house only the 10 best students will count for the competition. Positive: Easy rule to calculate the points. Negative: Students might become uninterested if they see they can't reach the top 10 places of their house.
From my point of view, your problem is diveded in a few points: The best thing to do would be to re - assignate the player in the different Houses so that each House has the same number of players. (as explain by #navid-vafaei) If you don't want to do that because you believe that it may affect your game popularity with player whom are in House that they don't want because you can change the choice of the Sorting Hat at least in the movie or books. In that case, you can sum the point of the student's house and divide by the number of students. You may just remove the number of student with a very low score. You may remove as well the student with a very low activity because students whom skip school might be fired. The most important part for me n your algorithm is weather or not you give points for all valuables things: In the Harry Potter's story, the students earn point on the differents subjects they chose at school and get point according to their score. At the end of the year, there is a special award event. At that moment, the Director gave points for valuable things which cannot be evaluated in the subject at school suche as the qualites (bravery for example).
Best algorithm for netting orders
I am building a marketplace, and I want to build a matching mechanism for market participants orders. For instance I receive these orders: A buys 50 B buys 100 C sells 50 D sells 20 that can be represented as a List<Orders>, where Order is a class with Participant,BuySell, and Amount I want to create a Match function, that outputs 2 things: A set of unmatched orders (List<Order>) A set of matched orders (List<MatchedOrder> where MatchOrder has Buyer,Seller,Amount The constrain is to minimize the number of orders (unmatched and matched), while leaving no possible match undone (ie, in the end there can only be either buy or sell orders that are unmatched) So in the example above the result would be: A buys 50 from C B buys 20 from D B buys 80 (outstanding) This seems like a fairly complex algorithm to write but very common in practice. Any pointers for where to look at?
You can model this as a flow problem in a bipartite graph. Every selling node will be on the left, and every buying node will be on the right. Like this: Then you must find the maximum amount of flow you can pass from source to sink. You can use any maximum flow algorithms you want, e.g. Ford Fulkerson. To minimize the number of orders, you can use a Maximum Flow/Min Cost algorithm. There are a number of techniques to do that, including applying Cycle Canceling after finding a normal MaxFlow solution. After running the algorithm, you'll probably have a residual network like the following:
Create a WithRemainingQuantity structure with 2 members: a pointeur o to an order and an integer to store the unmatched quantity Consider 2 List<WithRemainingQuantity> , 1 for buys Bq, 1 for sells Sq, both sorted by descending quantities of the contained order. the algo match the head of each queue until one of them is empty Algo (mix of meta and c++) : struct WithRemainingQuantity { Order * o; int remainingQty; // initialised with o->getQty } struct MatchedOrder { Order * orderBuy; Order * orderSell; int matchedQty=0; } List<WithRemainingQuantity> Bq; List<WithRemainingQuantity> Sq; /* populate Bq and Sq and sort by quantities descending, this is what guarantees the minimum of matched. */ List<MatchedOrder> l; while( ! Bq.empty && !Sq.empty) { int matchedQty = std::min(Bq.front().remainingQty, Sq.front().remainingQty) l.push_back( MatchedOrder(orderBuy=Bq.front(), sellOrder=Sq.front(), qtyMatched=matchedQty) ) Bq.remainingQty -= matchedQty Sq.remainingQty -= matchedQty if(Bq.remainingQty==0) Bq.pop_front() if(Sq.remainingQty==0) Sq.pop_front() } The unmatched orders are the remaining orders in Bq or Sq (one of them if fatally empty, according to the while clause).
Algorithm for fair distribution of revenue
I am after an algorithm (preferably abstract or in very clear Python or PHP code) that allows for a fair distribution of revenue both in the short and in the long term, based on the following constraints: Each incoming amount will be an integer. Each distribution will be also an integer amount. Each person in the distribution is set to receive a cut of the revenue expressed as a fixed fraction. These fractions can of course be put under a common denominator (think integer percentages with a denominator of 100). The sum of all numerators equals the denominator (100 in the case of percentages) To make it fair in the short term, person i must be receiving either floor(revenue*cut[i]) or ceil(revenue*cut[i]). EDIT: Let me emphasize that ceil(revenue*cut[i]) is not necessarily equal to 1+floor(revenue*cut[i]), which is where some algorithms fail including one presented (see my comment on the answer by Andrey). To make it fair in the long term, as payments accumulate, the actual cuts received must be as close to the theoretical cuts as possible, preferably always under 1 unit. In particular, if the total revenue is a multiple of the denominator of the common fraction, every person should have received the corresponding multiple of their numerator. [Edit] Forgot to add that the total amount distributed every time must of course add up to the incoming amount received. Here's an example for clarity. Say there are three people among which to distribute revenue, and one has to get 31%, another has to get 21%, and the third has to get 100-31-21=48%. Now imagine that there's an income of 80 coins. The first person should receive either floor(80*31/100) or ceil(80*31/100) coins, the second person should receive either floor(80*21/100) or ceil(80*21/100) and the third person, either floor(80*48/100) or ceil(80*48/100). And now imagine that there's a new income of 120 coins. Each person should again receive either the floor or the ceiling of their corresponding cuts, but since the total revenue (200) is a multiple of the denominator (100), each person should have now their exact cuts: the first person should have 62 coins, the second person should have 42 coins, and the third person should have 96 coins. I think I have an algorithm figured out for the case of two people to distribute the revenue among. It goes like this (for 35% and 65%): set TotalRevenue to 0 set TotalPaid[0] to 0 { TotalPaid[1] is implied and not necessary for the algorithm } set Cut[0] to 35 { Cut[1] is implied and not necessary for the algorithm } set Denominator to 100 each time a payment is received: let Revenue be the amount received this time set TotalRevenue = TotalRevenue + Revenue set tmp = floor(TotalRevenue*Cut[0]/Denominator) pay person 0 the amount of tmp - TotalPaid[0] set TotalPaid[0] = tmp pay person 1 the amount of TotalRevenue - TotalPaid[0] I think that this simple algorithm meets all of my constraints, but I have not found the way to extend it to more than two people without violating at least one. Can anyone figure out an extension to multiple people (or perhaps prove its impossibility)?
I think this works: Keep track of a totalReceived, the total amount of money that has entered the system. When money is added to the system, add it to totalReceived. Set person[i].newTotal = floor(totalReceived * cut[i]). Edit: had error here; thanks commenters. This distributes some of the money. Keep track of how much, to know how much "new money" is left over. To be clear, we are keeping track of how much of the total amount of money is left over, and intuitively we re-distribute the whole sum at every step, although actually nobody's fund ever goes down between one step and the next. You need to know how to distribute the left-over integer amount of money: there should be less than numPeople amount left over. For i ranging from 0 to leftOverMoney - 1, increment person[i].newTotal by 1. Effectively we give a dollar to each of the first leftOverMoney people. To compute how much a person "received" during this step, compute person[i].newTotal - person[i].total. To clean/finish up, set person[i].total = person[i].newTotal.
To accomodate constraint 4, the current payment must be used as the basis for distribution. After distributing the rounded dividends to the investors, the leftover dollars may be awarded, one each, to any eligible investors. An investor is eligible if he is due a fractional share, that is, ceil(revenuecut[i]) > floor(revenuecut[i]). Constraint 5 may be addressed by deciding who, among the eligible investors, should get the leftover dollars. Maximum long-term fairness will be most closely approached by always awarding the leftover dollars to the eligible investors who have accumulated the most total (long-term) distribution error. The following is derived from the algorithm I used for my fund manager clients. (I always used Pascal for financial applications for forensic reasons.) I have transposed the code fragments from a database application to an array-based method in an attempt to improve the clarity. Included in the accounting data structures is a table of investors. Included in the information about each investor is his share fraction (investor share count divided by fund total shares), amount earned to date, and amount distributed (actually paid to investor) to date. Investors : array [0..InvestorCount-1] of record // ... lots of information about this investor ShareFraction : float; // >0 and <1 EarnedToDate : currency; // rounded to dollars DistributedToDate : currency; // rounded to dollars end; // The sum of all the .ShareFraction in the table is exactly 1. Some temporary data is created for these calculations and freed afterwards. DistErrs : array [0..InvestorCount-1] of record TotalError : float; // distribution rounding error CurrentError : float; // distribution rounding error InvestorIndex : integer; // link to Investors record end; UNDISTRIBUTED_PAYMENTS : currency; CurrentFloat : float; CurrentInteger : currency; CurrentFraction : float; TotalFloat : float; TotalInteger : currency; TotalFraction : float; DD, II : integer; // array indices FUND_PREVIOUS_PAYMENTS : currency; is a parameter, derived from the fund history. If it is not provided as a parameter it may be calculated as the sum over all Investors[].EarnedToDate. FUND_CURRENT_PAYMENT : currency; is a parameter, derived from the current increase in fund value. FUND_TOTAL_PAYMENTS : currency; is a parameter, derived from the current fund value. This is the fund total amount previously paid out plus the fund current payment. These three values form a dependents system with two degrees of freedom. Any two may be provided and the third calculated from the others. // Calculate how much each investor has earned after the fund current payment. UNDISTRIBUTED_PAYMENTS := FUND_CURRENT_PAYMENT; for II := 0 to InvestorCount-1 do begin // Calculate theoretical current dividend whole and fraction parts. CurrentFloat := FUND_CURRENT_PAYMENT * Investors[II].ShareFraction; CurrentInteger := floor(CurrentFloat); CurrentFraction := CurrentFloat - CurrentInteger; // Calculate theoretical total dividend whole and fraction parts. TotalFloat := FUND_TOTAL_PAYMENTS * Investors[II].ShareFraction; TotalInteger := floor(TotalFloat); TotalFraction := TotalFloat - TotalInteger; // Distribute the current whole dollars to the investor. Investors[II].EarnedToDate := Investors[II].EarnedToDate + CurrentInteger; // Track total whole dollars distributed. UNDISTRIBUTED_PAYMENTS := UNDISTRIBUTED_PAYMENTS - CurrentInteger; // Record the fractional dollars in the errors table and link to investor. DistErrs[II].CurrentError := CurrentFraction; DistErrs[II].TotalError := TotalFraction; DistErrs[II].InvestorIndex := II; end; At this point UNDISTRIBUTED_PAYMENTS is always less than InvestorCount. // Sort DistErrs by .TotalError descending. In the real world the data is kept in a database not in arrays, so sorting is done by creating an index on DistErrs using TotalError as a key. // Distribute one dollar each to the first UNDISTRIBUTED_PAYMENTS eligible // investors (i.e. those whose current share ceilings are higher than their // current share floor), in order from greatest to least .TotalError. for DD := 0 to InvestorCount-1 do begin if UNDISTRIBUTED_PAYMENTS <= 0 then break; if DistErrs[DD].CurrentError <> 0 then begin II := DistErrs[DD].InvestorIndex; Investors[II].EarnedToDate := Investors[II].EarnedToDate + 1; UNDISTRIBUTED_PAYMENTS := UNDISTRIBUTED_PAYMENTS - 1; end; end; In a subsequent process, each investor is paid the difference between his .EarnedToDate and his .DistributedToDate, and his .DistributedToDate is adjusted to reflect that payment.
Who owes who money optimization
Say you have n people, each who owe each other money. In general it should be possible to reduce the amount of transactions that need to take place. i.e. if X owes Y £4 and Y owes X £8, then Y only needs to pay X £4 (1 transaction instead of 2). This becomes harder when X owes Y, but Y owes Z who owes X as well. I can see that you can easily calculate one particular cycle. It helps for me when I think of it as a fully connected graph, with the edges being the amount each person owes. Problem seems to be NP-complete, but what kind of optimisation algorithm could I make, nevertheless, to reduce the total amount of transactions? Doesn't have to be that efficient, as N is quite small for me. Edit: The purpose of this problem would be to be able to have in the accounting system something that can say to each person when they log in "You can remove M amount of transactions by simply paying someone X amount, and someone else Y amount". Hence the bank solution (though optimal if everyone is paying at the same time) cannot really be used here.
Are people required to clear their debts by paying somebody that they actually owe money to personally? If not, the following seems to work suspiciously easily: For each person, work out the net amount they should pay, or should receive. Have somebody who owes money net pay somebody who should receive money net min(amount owed, amount to be received). After this, at least one of the two participants owes nothing and should receive nothing, and so can be removed from the problem. Assuming I have missed something, what are the constraints that apply (or gross error made)?
I have created an Android app which solves this problem. You can input expenses during the trip, it even recommends you "who should pay next". At the end it calculates "who should send how much to whom". My algorithm calculates minimum required number of transactions and you can setup "transaction tolerance" which can reduce transactions even further (you don't care about $1 transactions) Try it out, it's called Settle Up: https://market.android.com/details?id=cz.destil.settleup Description of my algorithm: I have basic algorithm which solves the problem with n-1 transactions, but it's not optimal. It works like this: From payments, I compute balance for each member. Balance is what he paid minus what he should pay. I sort members according to balance increasingly. Then I always take the poorest and richest and transaction is made. At least one of them ends up with zero balance and is excluded from further calculations. With this, number of transactions cannot be worse than n-1. It also minimizes amount of money in transactions. But it's not optimal, because it doesn't detect subgroups which can settle up internally. Finding subgroups which can settle up internally is hard. I solve it by generating all combinations of members and checking if sum of balances in subgroup equals zero. I start with 2-pairs, then 3-pairs ... (n-1)pairs. Implementations of combination generators are available. When I find a subgroup, I calculate transactions in the subgroup using basic algorithm described above. For every found subgroup, one transaction is spared. The solution is optimal, but complexity increases to O(n!). This looks terrible but the trick is there will be just small number of members in reality. I have tested it on Nexus One (1 Ghz procesor) and the results are: until 10 members: <100 ms, 15 members: 1 s, 18 members: 8 s, 20 members: 55 s. So until 18 members the execution time is fine. Workaround for >15 members can be to use just the basic algorithm (it's fast and correct, but not optimal). Source code: Source code is available inside a report about algorithm written in Czech. Source code is at the end and it's in English: http://settleup.destil.cz/report.pdf
Nominate one person arbitrarily to be the banker. Each other person transfers the sum of all the outgoing transactions minus the incoming transactions (so either deposits or withdraws) to that person. There will be a maximum of (n-1) transactions, which is pretty small. It is fast. It is simple. Given that everyone who transfers money will have to be involved in a transaction anyway*, it is bounded to be at worst twice the optimal case.** * The exception is the banker themselves. A quick optimisation is to ensure the nominated banker is not someone who holds a neutral position. ** Explaining my upper bound logic further: Suppose the optimal case is A gives $1 to B, and C gives $1 to D, and E is neutral = two transactions. Then with this logic, if E is the nominated banker, A gives $1 to E, E gives $1 to B, C gives $1 to E and E gives $1 to D = four transactions. With the optimisation, making sure you don't choose a neutral person for banker, select A instead. A gives $1 to B, C gives $1 to A. A gives $1 to D = three transactions.
for each debt in debts debt.creditor.owed -= debt.amount debt.deptor.owed += debt.amount end for each person in persons if person.owed > 0 then deptors.add person else if person.owed < 0 then creditors.add person end end deptors.sort_by_owed_desc creditor.sort_by_owed_asc for each debtor in deptors while debtor.owed > 0 creditor = creditors.top amount = min( debtor.owed, -creditor.owed) creditor.owed += amount debtor.owed -= amount if creditor.owed == 0 then creditors.remove_top end write debtor.name " owes " creditor.name " " amount "€" end end
Just thinking about it I'd start by looking at each cycle in the directed graph and reducing each edge in the cycle by the value of the minimum edge in the cycle, then remove the minimum edge altogether. Rinse and repeat.
Here's the Python solution I used; it's the same idea as Gunner's post, with a few line changes: for i in N: for j in N: if i!=j and owes[i][j] > owes[j][i]: owes[i][j] -= owes[j][i] owes[j][i] = 0 for k in N: for i in N: for j in N: if k == i or i == j or k == j: continue if owes[j][k] > owes[i][j]: owes[i][k] += owes[i][j] owes[j][k] -= owes[i][j] owes[i][j] = 0; Works a treat. You can test it with i.e.: owes = [[0,2,11], [4,0,7], [2,3,0]] N = range(len(owes))
I think you need to build a different data structure ( a tree, each time one person is the root node) that will check for each person how many "transaction" can you "kill", than, choose the best one, make the cycle, and rebuild it again.it is not o(N), I Think it's N^2 though, and it will not give you the best result. it is just a strategy.
This problem may be tackled with the Warshall algorithm. for(i=0;i<n;i++) for(j=0;j<n;j++) if ( i!= j && owes[i][j] > owes[j][i] ) owes[i][j] -= (owes[i][j] - owes[j][i]), owes[j][i] = 0; for(k=0;k<n;k++) for(i=0;i<n;i++) for(j=0;j<n;j++) { if( k == i || i == j || k == j ) continue; if ( owes[j][k] > owes[i][j] ) { int diff = owes[j][k] - owes[i][j]; owes[i][j] = 0; owes[i][k ] += diff; owes[j][k] -= diff; } } After the algorithm finishes, the total number of transactions required would be the number of positive entries in the owes table. I have not verified yet whether the algorithm will work, based on nature of the problem it may work. Solution is O(N^3).
I think you must remove all cicles reducing edges by minimal edge value and removingedges with value 0. After it you will get graph withouth cicles. I think you must find vertexes, wich have no pointers to them (man's wich owes only others money). This man's must pay money, beacouse there is no one to pay the money for them. So my point is that you must find somehow who they must pay.
I have a solution to the problem written in matlab. It is based on a matrix of who owes who what. The number in the (i,j) means that person j owes person i the number. E.g. B owes A 2 and A owes B 1 of course in this case it is trivial that B should just give A 1 This becomes more complex with more entries. However, with the algorithm i wrote i can guarantee that no more than N-1 transactions occurs where N is the number of persones 2 in this case. Here is the code i wrote. function out = whooweswho(matrix) %input sanitation if ~isposintscalar(matrix) [N M] = size(matrix); if N ~= M error('Matrix must be square'); end for i=1:N if matrix(N,N) ~= 0 error('Matrix must have zero on diagonals'); end end else %construction of example matrix if input is a positive scalar disp('scalar input: Showing example of NxN matrix randomly filled'); N = matrix; matrix = round(10*N*rand(N,N)).*(ones(N,N)-eye(N)) end %construction of vector containing each persons balance net = zeros(N,1); for i=1:N net(i) = sum(matrix(i,:))-sum(matrix(:,i)); end %zero matrix, so it can be used for the result matrix = zeros(size(matrix)); %sum(net) == 0 always as no money dissappears. So if min(net) == 0 it %implies that all balances are zero and we are done. while min(net) ~= 0 %find the poorest and the richest. [rec_amount reciever] = max(net); [give_amount giver] = min(net); %balance so at least one of them gets zero balance. amount =min(abs(rec_amount),abs(give_amount)); net(reciever) = net(reciever) - amount; net(giver) = net(giver) + amount; %store result in matrix. matrix(reciever,giver) = amount; end %output equivalent matrix of input just reduced. out = matrix; end
algorithm to determine minimum payments amongst a group
The Problem I was recently asked to calculate the money owed amongst a group of people who went on a trip together and came upon an interesting problem: given that you know the amounts that each person owes another, what is a general algorithm to consolidate the debts between people so that only the minimum number of payments needs to be made? Take this as an example: Mike owes John 100 John owes Rachel 200 Mike owes Rachel 400 We can remove a payment between Mike and John by reformulating the debts like this: Mike owes John 0 John owes Rachel 100 Mike owes Rachel 500 I did the math by hand since it was easy enough, but then the programmer in me was itching to figure out a general algorithm to do it for an arbitrarily large group. This seems like a graph algorithm to me, so I'll reformulate this as a graph: Viewed as a Graph The vertices are the people in the group The edges are directed and weighted by the amount owed. For example, an edge from Mike to Rachel with weight 500 means that Mike owes Rachel 500. Constraint: the net sum of weights for each node must remain unchanged. The goal is to find a graph with the minimum number of edges that still satisfy the constraint.
My opinion: You're making this overly complicated. Think of it as a "pool" of money, and lose the relationships altogether: Instead of: Mike owes John 100 John owes Rachel 200 Mike owes Rachel 400 The algorithm only has to think: Mike owes 100 John is owed 100 John owes 200 Rachel is owed 200 Mike owes 400 Rachel is owed 400 Netting this: Mike owes 500 John owes 100 Rachel is owed 600 Separate this into a list of "givers" and "receivers". Each giver on the list will go through the list of receivers, giving each receiver what they need until the giver has payed up. When a receiver receives everything they need, they go off the list. Later Edit As other posters have observed, this simplifies the problem. However, there might be an optimal ordering of the "givers" and "receivers" lists, but we haven't yet identified a straightforward way to determine this ordering.
It does not suffice to just figure out the receivers and givers. While I think this strategy is on the right track it also does not ensure an algorithm to find the least possible amount of payments. For Example, Person A owes 25 Person B owes 50 Person C owes 75 Person D is owed 100 Person E is owed 50 While it is obvious that this can be done in 3 pays (A and C to D, B to E). I can't think of an efficient algorithm that will satisfy this for all problem sets. Better Example, Person A owes 10 Person B owes 49 Person C owes 50 Person D owes 65 Person E is owed 75 Person F is owed 99 If we took the greedy approach of having person D pay to F we would wind up with a sub-optimal solution as opposed to the optimal(A&D to E, B&C to F). This problem has a lot of similarity with the Bin Packing Problem which has been proven to be NP-hard. The only difference being that we have multiple bins of varying sizes and the condition that the total space in all bins is equal to the total size of all items. This leads me to believe that the problem is likely NP-hard but with the added constraints it may be possible to solve in polynomially time.
Take a look at this blog article, "Optimal Account Balancing", goes over your problem exactly.
In the world of the corporate treasury, this is known as payment or settlement netting. Multinational corporates usually have many flows between their subsidiaries every month, often in different currencies. They can save considerable amounts by optimising the settlement of these flows. Typically a corporate will perform such an optimisation (a netting cycle) once a month. When there are multiple currencies, there are three sources of savings: bank transaction fees (fewer payments means lower fees) lower interest rate float and settlement risk arising from streamlined processing by the bank (the money spends less time tied up in the banking system) FX matching (much less foreign currency is exchanged because most of it is 'netted out') There are two ways to actually calculate the optimised settlement. Bilateral netting is the solution well described by #AndrewShepherd on this page. However, in a cross-border implementation, this approach can have legal and administrative problems implications since different borders are being crossed each month. Multilateral netting solves the network by adding a new subsidiary called the netting centre and re-routes all amounts through it. Compare the before and after diagrams below: Before netting After netting Although this adds one more flow than is necessary (compared to bi-lateral netting), the advantages are: the calculation is simpler and the result is easier to visualise (also, there is only one solution, as opposed to the bilateral approach) the netting centre becomes an invaluable resource regarding flows and FX exposure within the whole group if the netting centre is, say, in Germany, then all legal issues with cross-border payments are dealt once and for all within the netting centre's country (central bank reporting, etc.) all foreign exchange required for the optimised settlement can be bought or sold from the netting centre (At it's basic level, the calculation is simple, but there can be many legal and administrative complications so corporates frequently develop or purchase a netting system from a software vendor or service provider.)
While I concur with #Andrew that turning this into a graph problem is probably overcomplicated, I'm not sure his approach yields the minimal number of transactions. It's how you'd solve the problem in real life to save yourself a headache; just pool the money. A few steps that seem 'right': Remove all individuals with zero debt; they don't need to send or receive money from anyone. Pair all givers and receivers with identical amounts owed/owing. Since the minimal connectivity per node of non-zero debt is 1, their transactions are already minimal if they just pay each other. Remove them from the graph. Starting with the individual with the largest amount to pay back, create a list of all receivers with owed less than that amount. Try all combinations of payment until one is found that satisfies most receivers with one transaction. 'Save' the surplus debt remaining. Move on to the next largest giver, etc. Allocate all the surplus debt to the remaining receivers. As always, I'm afraid I'm pretty sure about the first two steps, less sure about the others. In any case, it does sound like a textbook problem; I'm sure there's a 'right' answer out there.
if A, B and C each owe $1 to each of D, E and F, the "list" or "central bank" solution creates five transactions (e.g. A,B,C -$3-> D, D -$3-> E,F) whereas the naive solution results in nine transactions. However, if A owes only to D, B only to E and C only to F the central bank solution creates still five transactions (A,B,C -$1-> D, D -$1-> E,F) whereas the best solution needs only three (A -$1-> D, B -$1-> E, C -$1-> F). This shows that the "list" or "central bank" solution is not optimal in general. The following greedy algorithm can be used to create better solutions to the problem, but they are not always optimal. Let "debt[i,j]" denote the amount of money person i owes to person j; initially this array is initialized according to the situation. repeat until last: find any (i, j) such that |K = {k : debt[i,k] > 0 and debt[j,k] > 0}| >= 2 if such (i, j) found: // transfer the loans from i to j total = 0 for all k in K: debt[j,k] += debt[i,k] total += debt[i,k] debt[i,k] = 0 person i pays 'total' to person j else: last for every i, j in N: if (debt[i,j] > 0) person i pays debt[i,j] to person j They key of this algorithm is the observation that if both A and B owe money to both C and D, instead of the four transactions required for direct payments, B can pay the net debt to A who can take care of paying back both A's and B's loans. To see how this algorithm works, consider the case where A, B and C each own $1 to each of D, E, F: A transfers A's debts to B, and pays $3 to B (one transaction) B transfers B's debts to C, and pays $6 to C (one transaction) Only C has debts any more; C pays $3 to D, E and F each (three transactions) But in the case where A owes D, B owes E and C owes F, the algorithm falls through immediately to the payment loop, resulting in the optimal number of transactions (only three) instead of five transactions which would result from the "central bank" approach. An example of non-optimality is where A owes to D and E, B owes to E and F and C owes to F and D (assume $1 for every debt). The algorithm fails to consolidate the loans because no two payers share two common payees. This could be fixed by changing ">= 2" on the second line to ">= 1", but then the algorithm would most likely become very sensitive to the order in which the debts are collateralized.
So, I implemented this for a spreadsheet to keep track of my roommates' debt to each other. I know this is really old, but I referenced it in my solution, and it's high on Google when searching for the subject, so I wanted to post and see if anyone has any input. My solution uses the "central bank" or "netting center" concept people mentioned here. Before running this algorithm I calculate the net profit each person is owed, which is the sum of all their credits, minus the sum of all their debts. The complexity of calculating this is dependent on the number of transactions, not the number of individuals involved. Fundamentally the point of the algorithm is to have every individual be paid or pay out the correct amount regardless of what individual they are transferring money to. I would ideally like to do this in the fewest number of payments, however it's difficult to prove this to be the case. Note all debits and credits will sum to zero. I was very, very verbose for part of this code. In part to communicate what I was doing, and in part to solidify the logic I am using as I go forward. Apologies if it's unreadable. Input: {(Person, Net Profit)} //Net Profit < 0 is debt, Net Profit > 0 is credit. Output: {(Payer, Payee, Amount paid)} find_payments(input_list): if input_list.length() > 2: //More than two people to resolve payments between, the non-trivial case max_change = input_list[0] not_max_change = [] //Find person who has the highest change to their account, and //the list of all others involved who are not that person for tuple in input_list: if abs(tuple[Net Profit]) > abs(max_change[Net Profit]) not_max_change.push(max_change) max_change = tuple else: not_max_change.push(tuple) //If the highest change person is owed money, they are paid by the //person who owes the most money, and the money they are paid is deducted //from the money they are still owed. //If the highest change person owes money, they pay the person who //is owed the most money, and the money they pay is deducted //from the money they are still owe. not_yet_resolved = [] if max_change[Net Profit] > 0: //The person with the highest change is OWED money max_owing = not_max_change[0] //Find the remaining person who OWES the most money //Find the remaining person who has the LOWEST Net Profit for tuple in not_max_change: if tuple[Net Paid] < max_owing[Net Paid]: not_yet_resolved.push(max_owing) max_owing = tuple else: not_yet_resolved.push(tuple) //The person who has the max change which is positive is paid //by the person who owes the most, reducing the amount of money //they are owed. Note max_owing[Net Profit] < 0. max_change = [max_change[Person], max_change[Net Profit]+max_owing[Net Profit]] //Max_owing[Person] has paid max_owing[Net Profit] to max_change[Person] //max_owing = [max_owing[Person], max_owing[Net Profit]-max_owing[Net Profit]] //max_owing = [max_owing[Person], 0] //This person is fully paid up. if max_change[Net Profit] != 0: not_yet_resolved.push(max_owing) //We have eliminated at least 1 involved individual (max_owing[Person]) //because they have paid all they owe. This truth shows us //the recursion will eventually end. return [[max_owing[Person], max_change[Person], max_owing[Net Profit]]].concat(find_payments(not_yet_resolved)) if max_change[Net Profit] < 0: //The person with the highest change OWES money //I'll be way less verbose here max_owed = not_max_change[0] //Find who is owed the most money for tuple in not_max_change: if tuple[Net Paid] > max_owed[Net Paid]: not_yet_resolved.push(max_owed) max_owed = tuple else: not_yet_resolved.push(tuple) //max_change pays the person who is owed the most. max_change = [max_change[Person], max_change[Net Profit]+max_owed[Net Profit]] if max_change[Net Profit] != 0: not_yet_resolved.push(max_owing) //Note position of max_change[Person] moved from payee to payer return [[max_change[Person], max_owed[Person], max_owed[Net Profit]]].concat(find_payments(not_yet_resolved)) //Recursive base case //Two people owe each other some money, the person who owes pays //the person who is owed. Trivial. if input_list.length() == 2: if input_list[0][Net Profit] > input_list[1][Net Profit]: return [[input_list[1][Person], input_list[0][Person], input_list[0][Net Profit]]]; else return [[input_list[0][Person], input_list[1][Person], input_list[1][Net Profit]]]; Note: max_change = (payee, $A); max_owing = (payer, $B) |$A|>=|$B| by nature of 'max_change' $A > 0 => $A >= |$B| //max_change is owed money $B < 0 by nature of 'max_owing' $A >= -$B => $A + $B >= 0 => Payee does not go into debt and: max_change = (payee, $A); max_owed = (payer, $B) |$A|>=|$B| by nature of 'max_change' $A < 0 => -$A >= |$B| //max_change owes money $B > 0 by nature of 'max_owed' -$A >= $B => 0 >= $A + $B => Payee does not go into credit also: Sum of Payments = 0 = $A + $B + Remainder = ($A + $B) + 0 + Remainder The sum always being 0 after someone's debt is completely settled is the basis of the recursion logic. Someone is paid/has paid, the problem gets smaller. If this algorithm is running for n people with non-zero debts (discard people who broke even before running the algorithm) this algorithm will give at most n-1 payments to settle the debt. It's unclear if it is always an ideal payment scheme (I've yet to find a counter example). I may try to prove if the number of transactions < n-1 then a debt and a credit must be exactly equal, which this algorithm accounts for I believe. I'm extremely interested in any errors anyone sees in this. I haven't done development in a while, never mind algorithmics, and people will be paying each other based off this. I had fun and this is an interesting, meaty question, I hope some of you are still around.
As one #Edd Barret stated, this can be solved approximately using linear programming. I have written a blog post describing this approach, along with a tiny R package that implements it.