[
https://issues.apache.org/jira/browse/MAHOUT-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Owen updated MAHOUT-576:
-----------------------------
Attachment: MAHOUT-576.patch
If you'd be willing to try this out I'd be grateful. It's a fairly overhauled
approach. I haven't tested it so won't promise there aren't a few typos in
there but should be close enough you can perhaps get it working if necessary
and upload a modified patch.
> AbstractJDBCDiffStorage.updateItemPref is updating the AVG incorrectly in
> most cases
> ------------------------------------------------------------------------------------
>
> Key: MAHOUT-576
> URL: https://issues.apache.org/jira/browse/MAHOUT-576
> Project: Mahout
> Issue Type: Bug
> Components: Collaborative Filtering
> Affects Versions: 0.4
> Reporter: Renaud Bruyeron
> Assignee: Sean Owen
> Fix For: 0.5
>
> Attachments: MAHOUT-576.patch
>
>
> the JDBC version of the DiffStorage is not using a RunningAverage in the
> removePreference case, and ends up making incorrect calculations.
> In a scenario where users are setting and removing a lot of preferences, the
> AVG stored in the diff table quickly diverges from the correct value because
> of this.
> Right now, the input to updateItemPref comes from SlopeOneRecommender, and in
> the case of removePreference, it is *the old preference* value, not a delta.
> However, the code uses it as if it were a delta. Thus the calculation is off
> by PEER(removedpreference,userid)/count everytime a user removes a preference.
> At first glance, the code should compute the old delta instead of the old
> preference, and use this in the updateItemPref
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.