mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Owen (Commented) (JIRA)" <>
Subject [jira] [Commented] (MAHOUT-906) Allow collaborative filtering evaluators to use custom logic in splitting data set
Date Tue, 20 Dec 2011 14:27:30 GMT


Sean Owen commented on MAHOUT-906:

OK the problem I'm still having with it, which is a small matter of organization, is that
this plucks out two unrelated pieces of code to refactor and places them into one interface
with two methods. For example it's called "RelevantItemsDataSplitter" when that only describes
1 of the 2 roles it plays.

Can this be two interfaces, since these are two different roles conceptually? For example
the "processOneUser()" ought to be in a different interface and have a more descriptive name
I'd imagine. 

If you can please use 2 spaces instead of tab for formatting.

Otherwise this is pretty uncontroversial, just pulling out some code and leaving a hook in
its place, which seems just fine.
> Allow collaborative filtering evaluators to use custom logic in splitting data set
> ----------------------------------------------------------------------------------
>                 Key: MAHOUT-906
>                 URL:
>             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,
>   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:!default.jspa
For more information on JIRA, see:


View raw message