Yes, I'm suggesting that could at least be 80% of what you need. If you can generalize that bit further and refactor it, all the better.
I wouldn't bother necessarily extending to support the "user: item item item" syntax or else we'd get into supporting a lot of stuff. That conversion IMHO can be left to the caller. On Wed, Aug 31, 2011 at 4:52 PM, Grant Ingersoll <gsing...@apache.org>wrote: > > On Aug 31, 2011, at 11:47 AM, Sean Owen wrote: > > > No it still wants "user,item[,rating]" input. But otherwise yes, it's > > translated and un-translated internally as needed. > > > > You could change the mapper to read that input easily though. > > > > it still wants numeric input. It's hashing longs to ints. But this could > > easily be changed to record a more general mapping. > > Ah, so I would still have to do the conversion, or hash on the string. > > > > > On Wed, Aug 31, 2011 at 4:44 PM, Grant Ingersoll <gsing...@apache.org > >wrote: > > > >> > >> On Aug 31, 2011, at 11:26 AM, Sean Owen wrote: > >> > >>> Is the problem not just a matter of "translating" from the original > >>> identifiers to ints, so they can be used as offsets into a vector, and > >> then > >>> back again? > >> > >> Yeah, I was wondering about that when looking at the RecommenderJob. > >> > >> If I understand you right, I could just output lines of text as: > >> from: msgId1, msgId3, ... msgIdn > >> ... > >> > >> And the RecommenderJob would automatically do the translation? > >> > >> > >
