Mailing-List: contact mahout-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mahout-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of panisson@di.unito.it designates
 130.192.156.1 as permitted sender)
Message-ID: <20090422140532.cl6jnjm2o0c8oksg@www.di.unito.it>
Date: Wed, 22 Apr 2009 14:05:32 +0200
From: Andre Panisson <panisson@di.unito.it>
To: mahout-user@lucene.apache.org
Subject: Re: Considering removing User/Item abstractions
References: <e2e029610904220302o12a77e31qa3b6fd89ebb4b759@mail.gmail.com>
	<e2e029610904220314p7a961a0aq3aa8dd4fc3454ef9@mail.gmail.com>
In-Reply-To: <e2e029610904220314p7a961a0aq3aa8dd4fc3454ef9@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=UTF-8;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)

I think removing the User and Item abstractions would be a good idea. =20
The User interface is a bit more complex with the getPreferences =20
methods, but I think it can be easily ported to the DataModel. There =20
will be some impact in the already written code, but I think the =20
benefits are interesting.
I dont know if removing the Preference abstraction will bring a better =20
performance. The getPreferences methods are very useful to iterate =20
over the preferences of users and items, and I think it save a lot of =20
lookups if the association user/item is present in a single object.

Andr=C3=A9

Citando Sean Owen <srowen@gmail.com>:

> I am considering a somewhat large change to org.apache.mahout.cf.taste cod=
e
> and would like to solicit feedback from users.
>
> The change would be to remove the User, Item and Preference
> interfaces/abstractions from the code. Everything would proceed in terms o=
f
> user and item IDs, and preference values instead.
>
> The reasons for these interfaces originally were, well, it seemed nice. It
> also provided a way for implementors to substitute domain-specific
> implementations with additional information.
>
> But there are problems too.
>
> - Do methods take a User, or user ID? The code is not consistent in this
> regard. If User, the caller is forced to look up a User if it only has an
> ID. (Conversely, if the caller already has a User, and the method needs a
> User, then passing an ID only forces a redundant lookup. I think this is
> rarer.)
>
> - Factory method problem. There are many points in the code where it shoul=
d
> call to factory methods to generate a User/Item/Preference object since th=
e
> domain may use specialized implementations instead of GenericUser, etc. At
> the moment some methods just assume GenericUser, etc. Fixing this would be=
 a
> bit hard but would more importantly impact performance I think.
>
> - Object overhead. Holding these extra objects has a cost in memory and
> performance.
>
> The code already really assumes there are nothing but user and item IDs an=
d
> a pref value. So why not make the core reflect this and gain some simplici=
ty
> and speed performance?
>
> I think that domains that need to inject extra information can still do th=
is
> fine without needing custom User, Item implementations.
>
> It is just a thought now. Anybody have more?
>
> Sean
>