Implement a mostPopular method about myrrix-recommender HOT 12 CLOSED

Yes, understood. It's less trivial than it sounds just because the recommender 
does not already have this information at runtime, actually. Only the projected 
feature space data is on-line. Of course it wouldn't be too hard to also record 
and load this sort of thing. The main work is just the overhead of new API 
methods, updates, etc.

In fact, the recommender may have this information if the Generation provides 
the knownUserIDs (this is the implementation I've used for now): the score is 
the size of the knownUserID set. Patch will follow shortly.

And yes, the main work is the overhead of the API methods, updates, etc.

Attaching the patch file (note: this is a git patch)

Yeah that's a lot of the change. I had thought most popular might mean highest 
sum of input values rather than just highest cardinality. So an item has 
interaction values of 4, 9, and 1, that's a score of 14 for purposes of 
ranking, not 3.

I'll look into this.

I tried to store the sum of input values in the Generation (as a 
FastByIDFloatMap itemsWeight), but I do not know how to handle the remove 
preference (nor a preference update by the way, as it would count as a new 
preference).

The only solution I see for now is to store the whole preferences data in 
memory (would not that be too much??) as a FastByIDMap<FastByIDFloatMap> 
knownUserIDsWithPref.
But this solution has another issue: the MostPopularIterator would have to sum 
all the values of the FastByIDFloatMap corresponding to the users prefs for a 
given item to get the score for the item, which could be time consuming if 
there is lots of users and/or items.

What do you think?

For the second issue, I found a simple way to do it: compute the sum of all the 
values inside the FastByIDFloatMap (via a specialized copy and/or subclass): 
compute and maintain the accurate sum in put/remove/clear methods.

Here is a patch (not: this is a git patch) which implements the second proposed 
solution:
- Generation#knownUserIDs has been changed from FastByIDMap<FastIDSet> to 
FastByIDMap<FastByIDFloatMap>, to store the pref values
- FastByIDFloatMap now has a field sumOfValues, maintained within the 
put/remove/clear/entry.setValue methods
- ServerRecommender updates the user pref values in knownUserIDs.

OK I'll have a look. On second thought your original idea may be better, to 
avoid storing more data by just using the count rather than sum of values. It 
just requires the data structure already in place.

Ok, thanks a lot

Take a look at what I've added here and see if it works for you. I'm reluctant 
to add another larger data structure in memory, so implemented something less 
efficient at runtime using what's already being loaded. It still works fairly 
quickly.

It works really fine, thanks !
If you could just consider the addition of an IDRescorer to the 
mostPopularItems method (a requirement for us), I've attached a patch which 
does just that.

Again, many thanks !

OK, see my latest change, which is 95% the same as yours