The javadoc should be a nice start https://builds.apache.org/job/Mahout-Quality/javadoc/org/apache/mahout/cf/taste/impl/recommender/AbstractCandidateItemsStrategy.html
Apart from that, I'd say you should have a look around the code. On Thu, Feb 21, 2013 at 3:42 PM, Koobas <[email protected]> wrote: > On Thu, Feb 21, 2013 at 9:39 AM, Sean Owen <[email protected]> wrote: > > > It's also valid, yes. The difference is partly due to asymmetry, but also > > just historical (i.e. no great reason).* The item-item system uses a > > different strategy for picking candidates based on > CandidateItemStrategy.* > > > > Where do I find more information about this? > And thanks for the instantaneous reply :) > > > > > On Thu, Feb 21, 2013 at 2:37 PM, Koobas <[email protected]> wrote: > > > > > In the GenericUserBasedRecommender the concept of a neighborhood seems > to > > > be fundamental. > > > I.e., it is a classic implementation of the kNN algorithm. > > > > > > But it is not the case with the GenericItemBasedRecommender. > > > I understand that the two approaches are not meant to be completely > > > symmetric, > > > but still, wouldn't it make sense, from the performance perspective, to > > > compute items' neighborhoods first, > > > and then use them to compute recommendations? > > > > > > If kNN was run on items first, then every item-item similarity would be > > > computed once. > > > It looks like in the GenericItemBasedRecommender each item-item > > similarity > > > will be computed multiple times. > > > (How much, depends on the data, but still.) > > > > > > I am wondering if anybody has any thoughts on the validity of doing > > > item-item kNN in the context of: > > > 1) performance, > > > 2) quality of recommendations. > > > > > >
