mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <>
Subject Re: Considering removing User/Item abstractions
Date Fri, 01 May 2009 14:00:34 GMT
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

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.


On Apr 22, 2009 1:16 PM, "Sean Owen" <> 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


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

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