mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Zhang <zjf...@gmail.com>
Subject Re: 答复: Does the FileDataModel still require the UserID and ItemID numeric?
Date Wed, 23 Dec 2009 12:24:20 GMT
Hi Liu,

For small data set, I suggest you use MemoryIDMigrator for experiment.


Jeff Zhang


On Wed, Dec 23, 2009 at 3:48 AM, 刘逸哲 <zhe.liuyz@alibaba-inc.com> wrote:

> Hi,zhang
>  Could you give some example show how to use it?
>
> -----邮件原件-----
> 发件人: Jeff Zhang [mailto:zjffdu@gmail.com]
> 发送时间: 2009年12月23日 19:41
> 收件人: mahout-user@lucene.apache.org
> 主题: Re: Does the FileDataModel still require the UserID and ItemID numeric?
>
> Hi 刘,
>
> In the mahout 0.20, the user and item id must be long type. It is for
> performance.
> If your data model's id is string type , you should implement the interface
> IDMigrator which help you convert string to long. There's also some
> implementation such as MySQLJDBCIDMigrator in mahout which you can refer
> to.
>
>
> Jeff Zhang
>
>
>
> On Wed, Dec 23, 2009 at 3:15 AM, 刘逸哲 <zhe.liuyz@alibaba-inc.com> wrote:
>
> > I saw this "Further, this ID value must be
> > numeric; it is a Java long type through the APIs" in the taste
> documation.
> > But in the javadoc of FileDataModel,there is "The user and item IDs are
> > ready literally as Strings and treated as such in the API"
> > Does it mean that userID and ItemID could be string now, for example, my
> > data is look like this:
> > "Auser,apple,1
> > User2,banana,2
> > User3,car,3"
> > Could I use FileDataModel directly?
> > Thanks
> >
> >
> >
> > This email (including any attachments) is confidential and may be legally
> > privileged. If you received this email in error, please delete it
> > immediately and do not copy it or use it for any purpose or disclose its
> > contents to any other person. Thank you.
> >
> >
> >
> 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人,请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message