chrisokasaki / trademaximizer Goto Github PK

It's been said many times that prioritizing doesn't do much; however I do believe that there still is a good case for prioritizing specifically within named lists.

The most important thing about named lists is that they should guarantee that I will receive only one copy of the game from the given named list.

The case would be:

When creating my "wanted games" list, I want to priorize the best editions/offers of a given specific game over worse editions/offers.

Moreover, if possible, I would like to be able to nest named lists inside of other named lists. I expect this to guarantee that I will only receive one game from each "top-level" named list that I place in my exchanges list.

// desired default syntax
(nickname) %WANTED_GAME: 1 2 ; 3 4 ; 5 6
(nickname) 987 : %WANTED_GAME

// desired alternative syntax 
(nickname) %WANTED_GAME_BEST: 1 2
(nickname) %WANTED_GAME_MEDIOCRE: 3 4
(nickname) %WANTED_GAME_WORST: 5 6
(nickname) %WANTED_GAME: %WANTED_GAME_BEST ; %WANTED_GAME_MEDIOCRE ; %WANTED_GAME_WORST
(nickname) 987 : %WANTED_GAME

// expected outcome: 
// my desired offers priority order will be respected, and also, if I get game 1, then I won't get any of 2 3 4 5 6. 

As a side note, there was a real-life case where I wanted to prioritize games like this using the current syntax, in which ; inside named lists definitions completely doesn't matter.

I tried to be smart (lol) about it and use duplicated entries in my named lists to game the existing algorithm, but it ended up badly:

(nickname) %WANTED_GAME_BEST_OFFERS: 1 2 3
(nickname) %WANTED_GAME_ALL_OFFERS: 1 2 3 4 5 6
(nickname) 987 : %WANTED_GAME_BEST_OFFERS; %WANTED_GAME_ALL_OFFERS

// expected outcome: 
// if I get game 1, then I won't get any of games 2 3 4 5 6.

// non-desirable, but at least understandable outcome:
// if I get game 1 from %WANTED_GAME_BEST_OFFERS list, I can also get games 4 5 6 from %WANTED_GAME_ALL_OFFERS list,
// but at least I still won't get any of games 2 3.

// actual real-life outcome:
// I got games 1 and 2, despite the fact that they are *both* on *both* lists.

I guess this happened because the algorithm doesn't check whether any game from the currently considered named list was already assigned, but rather whether this named list already had some game from it assigned, regardless of its contents (which feels completely backwards, but possibly it makes the whole thing more efficient?...)

I won't say this is a bug, since named lists with duplicates like this aren't really a supported feature, but it's an outcome that really surprised me.

I'm happy to, hm, try to raise a PR implementing this feature (I'm not a Java dev, and not familiar with this code), but I'd love a response to understand if this is something that is viable/doable at all, and to ensure this repo is still actually maintained.

Hello,

Not sure if you still follow this project, but I have a possible PR with some changes that could improve the "happiness" of the choices with the penalty of number of trades. I am interested in your opinion if this would be useful in the real world. I already did the code modifications and came up with the following results, where avg. fulfilled want position means the average position of the received item on the receiver's wantlist (#1 being most wanted):

• original algo on ask.txt with square priorities: 197 trades, avg. fulfilled want position: 15.09 (median 8)
• modified algo on ask.txt: 173 trades, avg. fulfilled want position: 9.80 (median 7)

Meaning that originally the people that traded got their 15th most desired item on average, while with the updated algo they got their 10th most desired item on average. However the median - most often - received desired item only changed from number 8 to number 7 in this case.

Explanation of the thought process and changes:

The original algorithm's core goal is to maximize the number of trades, hence the weights of non-trades is set very high. In the case with no wishlist ranking (preferential ordering, let's call it wishlist ranking), this is probably the optimal way. However, when there is a wishlist ranking, depending on the input data, this can mean that many people will get the less desired items on their wishlist, because the algorithm values the number of trades much more than the wishlist ranking. By lowering the weight on the non-trade, it is possible to achieve better fulfilled wishlist rankings (people getting the items they want more), but the number of trades will be less. Of course, this then becomes a parameter question of where the trade-off is worth it. The parameters of this trade-off are, in my opinion, the percent of total trades willing to sacrifice, for the percentage of average wishlist ranking improvement. This could be done through iterative repetitions and bisection (if needed) to find the desired balance between total trades and best wishlist rankings.
I only did a quick modification and test on the sample data to confirm this idea.
What do you think about this? In the ask.txt sample, we got 35% a better fulfilled average wishlist rank for the cost of 12% less trades - 12% of people that would otherwise trade, did not trade in this case, but the ones that did trade got their 10th favorite item instead of their 15th favorite, on average.

Another thing I was thinking about is the weighting of the first and last item on the wishlist. I think generally, people will much prefer the first item in the wishlist, and at least in case of a shorter wishlist, much dislike the last item in the wishlist (still better then a no trade of course). So I also experimented with adjusting the weights of the first and last item in the wishlist, by simply adding a fixed penalty to non-first items and twice that for the last item. In the case of the same ask.txt example, with some value I tested I got 60% more people getting first-choices (16 instead of 10 people), at the expense of the average wishlist ranking going from 9.8 to 9.96 and getting 2 trades less (171 instead of 173).

My thinking is to create a simple parameter in the way of a small range of preference (e.g. number 1-5), which would determine how much trades to sacrifice for better average wishlist ranking (e.g. sacrifice up to 10% trades for at least 30% better rankings), and also how much trades and average ranking to sacrifice for getting more "number 1" picks and less "last picks".

Any opinion on this?