Thanks Sebastian.
Although I got the FileDataModel updating correctly after following your
advice, everything seems to point that I will need to use a database to
back my dataModel.
On Mon, Mar 3, 2014 at 3:47 PM, Sebastian Schelter wrote:
> I think it depends on the difference between
,
IIRC then FileDataModel has a parameter that determines how much time must
have been spent since the last modification of the underlying file. You can
also directly append new data to the original file.
If you want a to have a DataModel that can be concurrently updated, I
suggest your data to a
calls to recommender.refresh(null)?
Many thanks.
On Mon, Mar 3, 2014 at 1:18 PM, Sebastian Schelter wrote:
> Hi Juan,
>
> IIRC then FileDataModel has a parameter that determines how much time must
> have been spent since the last modification of the underlying file. You can
> also
Hi Juan,
IIRC then FileDataModel has a parameter that determines how much time
must have been spent since the last modification of the underlying file.
You can also directly append new data to the original file.
If you want a to have a DataModel that can be concurrently updated, I
suggest
I am having issues refreshing my recommender, in particular with the
DataModel.
I am using a FileDataModel and a GenericItemBasedRecommender that also has
a CachingItemSimilarity wrapping a FileItemSimilarity. But for the test I
am running I am making things even simpler.
By the time I
A follow-up question.
I worked around for quite a while and got stuck. It is difficult for me to
figure out which are the classes I need to extend.
I suppose they are : FileDataModel, Preference, PreferenceArray, am I
correct?
Thanks!
Jia
On Fri, May 17, 2013 at 1:20 AM, Manuel Blechschmidt
tps://github.com/ManuelB/facebook-recommender-demo/blob/master/src/main/resources/DemoFriendsLikes.csv
>>
>> Hope that helps
>>Manuel
>>
>> Am 16.05.2013 um 03:19 schrieb huangjia:
>>
>>> Hi,
>>>
>>> I want to build a recommendatio
ild a recommendation model based on Mahout. My dataset format
> > is in the format of
> >
> > userID, itemID, rating timestamp tag1 tag2 tag3. Thus, I think I need to
> > extend the FileDataModel.
> >
> > I looked into *JesterDataModel* as an example. However, I hav
ag3. Thus, I think I need to
> extend the FileDataModel.
>
> I looked into *JesterDataModel* as an example. However, I have a problem
> with the logic flow. In its *buildModel()* method, an empty map "data" is
> first constructed. It is then thrown into processFile. I assu
is in the format of
>
> userID, itemID, rating timestamp tag1 tag2 tag3. Thus, I think I need to
> extend the FileDataModel.
>
> I looked into *JesterDataModel* as an example. However, I have a problem
> with the logic flow. In its *buildModel()* method, an empty map "data&qu
Hi,
I want to build a recommendation model based on Mahout. My dataset format
is in the format of
userID, itemID, rating timestamp tag1 tag2 tag3. Thus, I think I need to
extend the FileDataModel.
I looked into *JesterDataModel* as an example. However, I have a problem
with the logic flow. In
integrate any new data everything must be reloaded.
> > On Mar 2, 2013 6:34 AM, "Nadia Najjar" wrote:
> >
> >> I am using a FileDataModel and remove and insert preferences before
> >> estimating preferences. Do I need to rebuild the recommender after these
> >> methods are called for it to be reflected in the prediction?
>
>
> Yes to integrate any new data everything must be reloaded.
> On Mar 2, 2013 6:34 AM, "Nadia Najjar" wrote:
>
>> I am using a FileDataModel and remove and insert preferences before
>> estimating preferences. Do I need to rebuild the recommender after these
>> m
Yes to integrate any new data everything must be reloaded.
On Mar 2, 2013 6:34 AM, "Nadia Najjar" wrote:
> I am using a FileDataModel and remove and insert preferences before
> estimating preferences. Do I need to rebuild the recommender after these
> methods are called for it
I am using a FileDataModel and remove and insert preferences before estimating
preferences. Do I need to rebuild the recommender after these methods are
called for it to be reflected in the prediction?
once, and then
it's in memory.
On Sun, Nov 11, 2012 at 10:53 AM, Onur Kuru wrote:
> Hi all,
>
> If I use FileDataModel, it takes about 5 secs to build the data model
> with 1m movielens data but it takes about 25 secs if I use
> ReloadFromJDBCDataModel.
> I know the
reduce the
loading time by tuning those.
Best,
Sebastian
On 11.11.2012 11:53, Onur Kuru wrote:
> Hi all,
>
> If I use FileDataModel, it takes about 5 secs to build the data model
> with 1m movielens data but it takes about 25 secs if I use
> ReloadFromJDBCDataModel.
> I know
in:1.2.1:java (default-cli) @ mahoutrec <<<
> [INFO]
> [INFO] --- exec-maven-plugin:1.2.1:java (default-cli) @ mahoutrec ---
> Feb 29, 2012 10:38:07 PM org.slf4j.impl.JCLLoggerAdapter info
> INFO: Creating FileDataModel for file datasets\mydb.csv
> Feb 29, 2012 10:38:08 PM org.slf4j.im
There is a Dictionary class that might help.
Do you have some code to contribute?
On Thu, Aug 11, 2011 at 7:30 PM, Charles McBrearty wrote:
> After having actually having implemented the import/export conversions it
> makes a little more sense why you didn't want to put this in the source tree
Putting a dictionary into a FileDataModel subclass is actually what I ended up
deciding to use.
After having actually having implemented the import/export conversions it makes
a little more sense why you didn't want to put this in the source tree since
it's kind of an ugly b
You don't need to rekey those tables.
You can use hashes of the strings. Or you can build a dictionary to use at
the import/export points.
On Thu, Aug 11, 2011 at 3:27 PM, Charles McBrearty wrote:
> In any event, your suggestion to switch to numeric IDs is a non-starter.
> This is because re-
>>
> >> I am taking a look at running some of the recommender examples from
> Mahout
> >> in action on a data set that I have that uses strings as the ItemID's
> and it
> >> looks to me like the suggested way to do this is to subclass
> FileDataModel
>
gt;> Hi,
>>
>> I am taking a look at running some of the recommender examples from Mahout
>> in action on a data set that I have that uses strings as the ItemID's and it
>> looks to me like the suggested way to do this is to subclass FileDataModel
>> and then use File
2011 at 1:02 AM, Charles McBrearty wrote:
> Hi,
>
> I am taking a look at running some of the recommender examples from Mahout
> in action on a data set that I have that uses strings as the ItemID's and it
> looks to me like the suggested way to do this is to subclass FileDataMod
ion on a data set that I have that uses strings as the ItemID's and it
looks to me like the suggested way to do this is to subclass FileDataModel
and then use FileIdMigrator to manage the String <-> Long mapping.
>
> This seems like a lot of complication to deal with what I would imag
The issue is that actually supporting strings through the whole process
kills performance.
Interning the strings to be consecutively assigned integers helps
ginormously.
On Wed, Aug 10, 2011 at 5:02 PM, Charles McBrearty wrote:
> This seems like a lot of complication to deal with what I would i
Hi,
I am taking a look at running some of the recommender examples from Mahout in
action on a data set that I have that uses strings as the ItemID's and it looks
to me like the suggested way to do this is to subclass FileDataModel and then
use FileIdMigrator to manage the String <
If the item similarities are already precomputed there's no sense in
fetching them from the data model, you can just read use the already
precomputed set of possibly similar items as no other items can be
recommended anyway and it's faster to fetch them from a similarity
implementation that holds t
May I ask why you choose to go with
AllSimilarItemsCandidateItemsStrategy over the default
PreferredItemsNeighborhoodCandidateItemsStrategy?
On 7/4/11 10:23 AM, Sebastian Schelter wrote:
A look into a recent blogpost of mine might maybe be helpful with
choosing the appropriate data access stra
A look into a recent blogpost of mine might maybe be helpful with
choosing the appropriate data access strategies for your recommender
setup. It covers a very common usecase in great detail:
http://ssc.io/deploying-a-massively-scalable-recommender-system-with-apache-mahout/
--sebastian
2011/7/4
I wouldn't use the in memory JDBC solution.
I was wondering do most people choose the JDBC backed solutions or the
File backed?
On 7/4/11 10:17 AM, Sean Owen wrote:
Yes. Both are just fine to use in production. For speed and avoiding abuse
of the database, I'd load into memory and tell it to
Yes. Both are just fine to use in production. For speed and avoiding abuse
of the database, I'd load into memory and tell it to periodically reload.
But that too is a bit of a choice between how often you want to consume new
data and how much work you want to do to recompute new values.
On Mon, Ju
speed. If you can fit everything in memory,
then you should. FileDataModel is in memory.
MySQLJDBCDataModel is not in memory and queries the DB every time. This is
pretty slow, though by caching item-item similarity as you do, a lot of the
load is removed. However if you want to go all in memory
Yes, this is trading memory for speed. If you can fit everything in memory,
then you should. FileDataModel is in memory.
MySQLJDBCDataModel is not in memory and queries the DB every time. This is
pretty slow, though by caching item-item similarity as you do, a lot of the
load is removed. However
I've read the source for FileDataModel and it suggested using a JDBC
backed implementation for larger datasets so I decided to upgrade our
recommendation system to use MySQLJDBCDataModel with
MySQLJDBCInMemoryItemSimilarity.
I've found that the JDBC backed versions performance i
27;s just a few
lines of change.
On Mon, Nov 15, 2010 at 2:31 PM, Jordan, Eric wrote:
> Hi,
>
> This is my second time trying to post this - the first time did not seem to
> work; my apologies if this ends up being a duplicate post.
>
> I'm having an issue with FileDataMod
Hi,
This is my second time trying to post this - the first time did not seem to
work; my apologies if this ends up being a duplicate post.
I'm having an issue with FileDataModel. In particular, suppose you have a main
data file (say, /tmp/data.lst) and two incremental files (say, /tmp/d
In the past I've extended the FileDataModel (if I recall correctly) that did
this exact filtering that ChrisS was asking for. It worked well.
Otis
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/
- Original Me
Maybe, my hunch is that it will affect so much in the code as to be hard to
support. It is rare you want to filter the data in different ways repeatedly
I think. And if you're filtering one way probably better to not have it in
memory.
On Oct 8, 2010 6:43 PM, "Steven Bourke" wrote:
> It would be a
It would be a nice feature to have build into the api for sure. You could
use the getPreferencesFromUser to determine which users have the appropriate
level of options.
On Fri, Oct 8, 2010 at 6:27 PM, Sean Owen wrote:
> There's nothing built-in. Yeah I'd view that as a step outside the core
> li
There's nothing built-in. Yeah I'd view that as a step outside the core library.
On Fri, Oct 8, 2010 at 5:56 PM, Chris Schilling
wrote:
> Hello,
>
> I am wondering if it is possible to place selection criteria when reading in
> the preference data used by taste to make predictions. For instance
Hello,
I am wondering if it is possible to place selection criteria when reading in
the preference data used by taste to make predictions. For instance: I only
want to use users who have reviewed more than 15 items. This is a data
cleansing step that I can take care of before feeding the data
Ah yeah I see the problem now. I'll fix that.
On Sun, Aug 15, 2010 at 5:00 PM, Tamas Jambor wrote:
> DataModel model = new FileDataModel(new File("./data/test.txt"));
> //just to make sure it loads the model
> model.getNumItems();
> System.out.println(model.getMaxPre
DataModel model = new FileDataModel(new File("./data/test.txt"));
//just to make sure it loads the model
model.getNumItems();
System.out.println(model.getMaxPreference());
this prints out a NaN
because you have maxPreference/minPreference calculated when it creates
the inner Da
What do you mean by this? I'm not clear yet.
On Sun, Aug 15, 2010 at 1:09 PM, Tamas Jambor wrote:
> Hi,
>
> One more possible bug, in FileDataModel, there is nothing to make sure that
> the superclass - AbstractDataModel gets the value for maxPreference and
> minPreference.
>
> Tamas
>
Hi,
One more possible bug, in FileDataModel, there is nothing to make sure
that the superclass - AbstractDataModel gets the value for maxPreference
and minPreference.
Tamas
46 matches
Mail list logo
