I have created a Jira issue already. I only use the non-hadoop part of Mahout recommender algorithms. May be I can create a patch for that part. However, I have not done it before, and don't know how to proceed.
On Wed, Mar 5, 2014 at 1:01 AM, Sebastian Schelter <s...@apache.org> wrote: > Would you be willing to set up a jira issue and create a patch for this? > > --sebastian > > > On 03/04/2014 11:58 PM, Mario Levitin wrote: > >> >>> I think we should introduce a new parameter for the recommend() method in >>> the Recommender interface that tells whether already known items should >>> be >>> recommended or not. >>> >> >> >> I agree (if the parameter is missing then defaults to current behavior as >> Pat suggested) >> >> >> >> >>> >> On 03/04/2014 05:32 PM, Pat Ferrel wrote: >> >>> >>> I'd suggest a command line option if you want to submit a patch. Most >>>> people will want that line executed so the default should be the current >>>> behavior. But a large minority will want it your way. >>>> >>>> And please do submit a patch with the Jira, it will make your life >>>> easier >>>> when new releases come out you won't have to manage a fork. >>>> >>>> On Mar 2, 2014, at 12:38 PM, Mario Levitin <mariolevi...@gmail.com> >>>> wrote: >>>> >>>> Juan, I don't understand your solution, if there are no ratings how can >>>> you >>>> blend the recommendations from the system and the user's already read >>>> news. >>>> >>>> Anyway, I think, as Pat does, the best way is to remove the mentioned >>>> line. >>>> It should be the responsibility of the business logic to remove user's >>>> items if needed. >>>> >>>> I will also create a Jira issue as you suggested. >>>> >>>> thanks >>>> On Sun, Mar 2, 2014 at 7:12 PM, Ted Dunning <ted.dunn...@gmail.com> >>>> wrote: >>>> >>>> On Sun, Mar 2, 2014 at 8:52 AM, Pat Ferrel <p...@occamsmachete.com> >>>> >>>>> wrote: >>>>> >>>>> You are not the only one to see this so I'd recommend creating an >>>>> option >>>>> >>>>>> for the Job, which will be checked before executing that line of code >>>>>> >>>>>> then >>>>> >>>>> submit it as a patch to the Jira you need to create in any case. >>>>>> >>>>>> That way it might get into the mainline and you won't have to >>>>>> maintain a >>>>>> fork. >>>>>> >>>>>> >>>>>> Avoiding the cost of a fork over a trivial issue like this is a grand >>>>> idea. >>>>> >>>>> >>>>> >>>> >>> >> >
