Yes I understand that you need (user, item+action) input for user based recs returned from recommender.recommend(userID, n).
But can you expect item similarity to work with the same input? I am fuzzy about how item similarity is calculated in cf/taste. I was expecting to train one recommender with (user, item+action) and call recommender1.recommend(userID, n) to get recs but also train another recommender with (user+action, item) to get recommender2.mostSimilarItems( itemID, n). I realize it's a hack but that aside is this second recommender required? I'd expect it to return items that use all actions to calculate similarity and therefore will use view information to improve the similarity calculation. No? On Feb 23, 2013, at 10:06 PM, Ted Dunning <[email protected]> wrote: No. It is uniformly better to have (item+action, user). In fact, I would prefer to have it the other way around when describing it to match the matrix row x column convention. (user, item+action) where action is binary leads to A = [A_1 | A_2] = user by 2xitem. The alternative of (user+action, item) leads to [ A_1 ] A = [ ] = 2xuser by item [ A_2 ] This last form doesn't have a uniform set of users to connect the items together. When you compute the cooccurrence matrix you get A_1' A_1 + A_2' A_2 which gives you recommendations from 1=>1 and from 2=>2, but no recommendations 1=>2 or 2=>1. Thus, no cross recommendations. On Sat, Feb 23, 2013 at 10:39 AM, Pat Ferrel <[email protected]> wrote: > But the discussion below lead me to realize that cf/taste is doing > something in addition to [B'B] h_p, which returns user history based recs. > I'm getting better results currently from item similarity based recs, which > I blend with user-history based recs. To get item similarity based recs > cf/taste is using a similarity metric and I'd guess that it uses the input > matrix to get these results (something like the dot product for cosine). > For item similarity should I create a training set of (item, user+action)?
