It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Over already? Rats! :-P
Post edited December 26, 2013 by mrbax
Congrats to the winners and thanks for your generosity, Gyroplast!
avatar
DragoonHP: I must know this algorithim... for research purposes of course. :-D

PS: Which language did you write the program in?
This first time I did things manually, and fortunately the algorithm worked out without a lot of backtracking, otherwise it'd have taken me longer. :) However, I'm planning to write a sample implementation in Python to get the idea across.

The algorithm itself as I used it basically consisted of creating an ordered list of 3-tuples (N,O,W), with N := arbitrary name, O := set of owned games and W := set of wanted games. O and W are subsets of the set of games included in the giveaway, only.

Then I ordered this list of tuples by #O, then #W in descending order, read: most owned first, then most wanted first. The basic premise is that an optimal AND ideal solution would be found if exactly one game is awared to each person until no more games are left.

A solution is found in an iterative fashion:
Look at which games are left on the gift code, then find all tuples which
a) would redeem the least amount of games, ideally one
b) would redeem the most games on their wanted list (to make sure you get what you're in for)
c) own the least amount of games.
If multiple tuples are equally good, a random choice is made.
After picking a tuple T, note it down with the awarded game(s), and remove the awarded games from the set W from all other tuples (as they can't get those anymore), and prune all tuples with an empty set W.
Repeat until all games are awarded.

Unfortunately, this algorithm WILL fail under certain circumstances, that's where backtracking comes in. Whenever a game is awarded, the pick may be worse "down the road" than another pick awarding the same number of games, but *other* games. This is due to the pruning that happens. Example: If you pick games 1 and 2 from a list of 1,2,3 and 4, and all the remaining people own 3 and 4 as well, these are out of luck, following this pick. If another pick owns 1 and 2 and wants 3 and 4, another pick can be made, which is better in terms of the defined solution quality metric.
In other words, one cannot decide by "number of games" alone, but must take into account which games are awarded as well. It seems to me that this problem is, unfortunately, only solvable by combinatorial exploration and comparison of all possible solution paths. :(

Luckily, I could 'eyeball' the solution good enough in this case to be certain that no better solution exists, but this means that I'm still looking to optimize the algorithm to scale better and cover hundreds of participants and dozens of games, and hope to find a way to circumvent the combinatorial explosion altogether.

Well, in any case, I am happy this worked out so well, despite a little lapse at the very beginning, which was sorted out by tinyE in the blink of an eye. And that's why I think people here are awesome.

Best wishes to all of you!
avatar
Gyroplast: -snip
Gyroplast, thanks for the explanation.

Interesting. but it would always favour the players with more games. I wonder if there's a way to write (a little more) random and still get useful results.

Time to taste out some ideas.
As I'm sure many have noticed the forum had/has some problems, so please excuse my late post.

Thank you for the giveaway Gyroplast! Congratulations to the winners and Merry Christmas to all!