Oh OK thought you were referring to an implementation in the library. As far as I personally am concerned, you're still honoring the contract of "estimate preference". You could change the implementation to record and return actual preferences, yes, regardless of what the implementation otherwise does. This would make it more consistent with other implementations. Maybe that's good. But maybe it costs a lot of resources in practice. So I support your tradeoff. There's loads of this in the library, for better or worse. I think it still hangs together well.
On Mon, Dec 6, 2010 at 11:09 PM, Lance Norskog <[email protected]> wrote: > I'm working on User-Item and Item-Item Recommenders based on Semantic > Vectors: > > http://ultrawhizbang.blogspot.com/2010/11/semantic-vectors-part-1.html > > http://ultrawhizbang.blogspot.com/2010/11/semantic-vectors-for-recommenders-with.html > > (Please comment on errors and lack of clarity.) > > The SemanticVectorDataModel only saves the projected vectors, not the > original recommender input. It cannot return the original prefs, only > its own prefs (N-dimensional vector distances). > > On Mon, Dec 6, 2010 at 1:53 AM, Sean Owen (JIRA) <[email protected]> wrote: > > > > [ > https://issues.apache.org/jira/browse/MAHOUT-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12967140#action_12967140] > > > > Sean Owen commented on MAHOUT-558: > > ---------------------------------- > > > > There's a tension between the need to fit several algorithms into one > common API, and the fact that they do have different characteristics. Making > them all work exactly the same would mean jumping through a few hoops and > also cutting off access to shortcuts that improve performance. > > > > One big example to me is fudging what a preference estimate means when > the data model has no preference values. estimatePreference() should > unusefully return 1.0 all the time, really but it doesn't, in order to be > more useful in practice. > > > > That said, at the level of your example we ought to have consistent > behavior. Which recommender doesn't return the known pref value? That sounds > like an unintentional behavior. > > > > However I would point out that the contract is to "estimate" a preference > -- nobody said what the estimate has to be! > > > >> Extend ItembasedRecommender to offer different "exclusion modes" when > computing most similar items to a collection of input items > >> > --------------------------------------------------------------------------------------------------------------------------------- > >> > >> Key: MAHOUT-558 > >> URL: https://issues.apache.org/jira/browse/MAHOUT-558 > >> Project: Mahout > >> Issue Type: New Feature > >> Components: Collaborative Filtering > >> Affects Versions: 0.5 > >> Reporter: Sebastian Schelter > >> Attachments: MAHOUT-558-2.patch, MAHOUT-558.patch > >> > >> > >> GenericItembased Recommender currently excludes all items that are not > similar at least one of the input items when computing the most similar > items to a collection of items. We should introduce a way to have the user > decide whether he/she wants this behavior or he/she wants to have all items > included that are similar to at least one of the input items, which is more > useful in practice in my experience. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > > > > -- > Lance Norskog > [email protected] >
