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 srowen@gmail.com designates
 209.85.219.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=fbQ+Y4PDuO6s1wyDS/xrsDP8X2L1LDVZhjufWO+hWH/GlUVvBzTBkyG4llTMs2Q6GT
         7IEqeNVLVBr/Z4zDQycFotn1Tr5bCYRy0Yp6NPv+5wknnBEpg7qxQd5YXezDXk6jti/m
         KHf9XrFtTSpHNVbMtVM94XjJPoebY1e/rPa5o=
MIME-Version: 1.0
In-Reply-To: <e2e029610904220516w7de99724ldc7251c8c8cb8f5@mail.gmail.com>
References: <e2e029610904220302o12a77e31qa3b6fd89ebb4b759@mail.gmail.com>
	 <e2e029610904220314p7a961a0aq3aa8dd4fc3454ef9@mail.gmail.com>
	 <20090422140532.cl6jnjm2o0c8oksg@www.di.unito.it>
	 <e2e029610904220516w7de99724ldc7251c8c8cb8f5@mail.gmail.com>
Date: Fri, 1 May 2009 15:00:34 +0100
Message-ID: <e2e029610905010700j50692a41p11c2a5fd34692da5@mail.gmail.com>
Subject: Re: Considering removing User/Item abstractions
From: Sean Owen <srowen@gmail.com>
To: mahout-user@lucene.apache.org
Content-Type: multipart/alternative; boundary=0016e6dee6fc8a49de0468da3c96

--0016e6dee6fc8a49de0468da3c96
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

As an update on this thought, I began exploring exactly what the API impact
would be. I think there is a big impact for those that subclassed or
implemented components, but probably little for clients of the standard
implementations.

I found one ugly snag when replacing Users and Items with IDs (Objects).
These entities need an ordering; Users and Items implement Comparable. When
dealing with IDs it is not sufficient to use Object; we must declare IDs as
- get this - Comparable<Comparable<?>>. This turns into a mess.

One alternative is to assume all IDs are Strings, since some components like
FileDataModel already necessarily assume this. But I don't like it.

I am inclined to defer this big change for now since the code is getting new
attention as part of Mahout and it is not a good time for a big change. I
imagine it will happen sooner or later for performance reasons; the
framework is eternally short on performance rather than felxibility so the
tradeoffs have to start happening.

More thoughts are welcome.

Sean

On Apr 22, 2009 1:16 PM, "Sean Owen" <srowen@gmail.com> wrote:

Agree about Preference -- there will have to be some kind of object
that represents an item-value pair. While the interface probably goes
away, the "GenericPreference" class probably stays.

Anyone who customized a component probably has to make some
non-trivial changes. People that just use standard components actually
may have little or no changes.

Thanks for the input, I will await more comments.


I should also add that performance has become my top priority, as it
always seems that the code consumes too much time and memory. So this
is a large reason why I favor a change that could simplify and speed
up the code and data structures, even if it means reducing flexibility
slightly.


Sean

On Wed, Apr 22, 2009 at 1:05 PM, Andre Panisson <panisson@di.unito.it>
wrote: > I think removing t...

--0016e6dee6fc8a49de0468da3c96--