[
https://issues.apache.org/jira/browse/MAHOUT-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175902#comment-13175902
]
Anatoliy Kats commented on MAHOUT-906:
--------------------------------------
You're right, the copy-paste is a bad sign, but I don't quite know how to fix
it. I do want a constructor with at least three distinct times. In a real
system, preferences older than a certain age might be deleted as irrelevant. A
simple way to emulate that is to test using a sliding window: Days 1-30
training, day 31 testing, then 2-31 training, 32 testing, etc. So, I'd need a
start date, split date, and end date. Relevance threshold is here for the same
reason as it is in the generic splitter -- we dont' want to test on negatively
rated items. I think storing it in the splitter classes is a good idea.
Perhaps we could create an abstract class that leafs through a user's
preferences and returns a sorted list of those above the threshold? Then we
can use that function in our splitters.
> Allow collaborative filtering evaluators to use custom logic in splitting
> data set
> ----------------------------------------------------------------------------------
>
> Key: MAHOUT-906
> URL: https://issues.apache.org/jira/browse/MAHOUT-906
> Project: Mahout
> Issue Type: Improvement
> Components: Collaborative Filtering
> Affects Versions: 0.5
> Reporter: Anatoliy Kats
> Priority: Minor
> Labels: features
> Attachments: MAHOUT-906.patch, MAHOUT-906.patch, MAHOUT-906.patch,
> MAHOUT-906.patch, MAHOUT-906.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> I want to start a discussion about factoring out the logic used in splitting
> the data set into training and testing. Here is how things stand: There are
> two independent evaluator based classes:
> AbstractDifferenceRecommenderEvaluator, splits all the preferences randomly
> into a training and testing set. GenericRecommenderIRStatsEvaluator takes
> one user at a time, removes their top AT preferences, and counts how many of
> them the system recommends back.
> I have two use cases that both deal with temporal dynamics. In one case,
> there may be expired items that can be used for building a training model,
> but not a test model. In the other, I may want to simulate the behavior of a
> real system by building a preference matrix on days 1-k, and testing on the
> ratings the user generated on the day k+1. In this case, it's not items, but
> preferences(user, item, rating triplets) which may belong only to the
> training set. Before we discuss appropriate design, are there any other use
> cases we need to keep in mind?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
