|
|
|
|
|
by pitherandd
2146 days ago
|
|
Another fantastic reply! I really need to get this to take off already so I can hire you before you make your own and out-compete me. The more I read this reply, the more I agree with it, and I think it may actually not be that difficult of a change. Card sets could be integrated into the existing cluster concept and I could just give users the ability to choose which sets (clusters) they swipe on and the weighting that they apply to each. They could also decide which clusters should be factored into their similarity matching. I _think_ this will all work with the existing CUBE concept, which is exciting, because many other proposed solutions by others didn't fit nicely within that mathematical structure. You've honestly given me a lot to think about and I think I see a better way forward now. Your insight really increased my mood because I think you've discovered something very important that I am likely going to be spending quite a bit of time on in the next coming weeks and months. Thanks so much! |
|
In terms of producing a "total match score" with a user, you compute a match score for each cardset that both users have, then use a simple normalized linear combination to get the total.
If users A and B have cardsets X Y and Z in common, you would produce similarity scores "S" for S(A,B,X), S(A,B,Y), and S(A,B,Z). Then, you use the weights that user A selects for each cardset (W(A), W(B), W(C)), normalize such that they add up to 1 but maintain their ratios, and compute total similarity of A matched to B as: W(A) * S(A) + W(B) * S(B) + W(C) * S(C).
As long as you have pre-computed the scores between all user-cardset pairs (your scaling pain point), computing match scores even with weights is trivial and fast.