Taste: throwing NoSuchElementException
Hello,
Question about NoSuchElementException usage in Taste:
I'm using Taste in an environment where lots of requests for recommended items
are for users who are new to the system - users who have no previously consumed
items. When I try to get recommendations for such users, the following is
thrown:
java.util.NoSuchElementException
at
org.apache.mahout.cf.taste.impl.model.BooleanUserGenericDataModel.getUser(BooleanUserGenericDataModel.java:81)
at
org.apache.mahout.cf.taste.impl.model.file.BooleanPrefUserFileDataModel.getUser(BooleanPrefUserFileDataModel.java:163)
at
org.apache.mahout.cf.taste.impl.recommender.BooleanUserGenericUserBasedRecommender.recommend(BooleanUserGenericUserBasedRecommender.java:86)
This looks correct, and comes from this piece of code in
BooleanUserGenericDataModel (the same happens in non-Boolean versions of the
code):
public User getUser(Object id) {
User user = userMap.get(id);
if (user == null) {
throw new NoSuchElementException();
}
return user;
}
I'm wondering if this is good/best thing to do here. Here is some reasoning:
- it's not really an error to ask a RE to recommend items for a user the RE
knows nothing about - it's the cold start issue
- I believe throwing exceptions is expensive, and I'm wondering if it would be
cheaper to do something else
- one could say this falls in the "using exceptions for flow control" category
(because that's what I'll have to do on the higher level)
- I briefly looked at returning null, but it looks like this would require
checks for null to avoid NPE in a number of places
I'm not sure this needs to change, but it's been on my mind for a while now.
On my end I can simply catch this ugly exception and eat it, although this
"NoSuchElementException" is so non-specific that if I just catch
NoSuchElementException the code may one day end up catching a
NoSuchElementException from some other part of Taste.
Thoughts?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Re: Taste: throwing NoSuchElementException
Yeah let's see, to boil it down: either way there has to be a way to
signal the user isn't known, and either way the caller has to handle
it. I've always preferred exceptions to null, all else being equal. I
don't mind the idea of exceptions being used for control flow; they
aren't that expensive. (In a performance-critical block, OK, I'd use
null instead, but here, this case is rare enough that I don't think
performance is a factor.)
Catching an exception needs a bit more code than handling null. You
can't force a caller to handle null, but you can force a caller to
handle an exception -- but here I'm using an unchecked exception so
that doesn't matter anyway. You have a point about catching this maybe
masking another exception.
I could be talked into changing this, but here, I think the right
behavior for a DataModel is to know about all users that exist, not
just ones with preferences. That is this user should be known in your
situation.
But are you using FileDataModel or something similar? because this
condition isn't really fulfilled by this implementation. It only knows
about users that have expressed a preference, by its nature. That can
be addressed so that you can express users, without expressing a
preference.
If this is the issue -- let me attack that issue directly to solve
this, and punt on the exception vs. null discussion. Am I right?
Sean
On 21 Jan 2009, 3:23 PM, "Otis Gospodnetic" wrote:
Hello,
Question about NoSuchElementException usage in Taste:
I'm using Taste in an environment where lots of requests for
recommended items are for users who are new to the system - users who
have no previously consumed items. When I try to get recommendations
for such users, the following is thrown:
java.util.NoSuchElementException
at
org.apache.mahout.cf.taste.impl.model.BooleanUserGenericDataModel.getUser(BooleanUserGenericDataModel.java:81)
at
org.apache.mahout.cf.taste.impl.model.file.BooleanPrefUserFileDataModel.getUser(BooleanPrefUserFileDataModel.java:163)
at
org.apache.mahout.cf.taste.impl.recommender.BooleanUserGenericUserBasedRecommender.recommend(BooleanUserGenericUserBasedRecommender.java:86)
This looks correct, and comes from this piece of code in
BooleanUserGenericDataModel (the same happens in non-Boolean versions
of the code):
public User getUser(Object id) {
User user = userMap.get(id);
if (user == null) {
throw new NoSuchElementException();
}
return user;
}
I'm wondering if this is good/best thing to do here. Here is some reasoning:
- it's not really an error to ask a RE to recommend items for a user
the RE knows nothing about - it's the cold start issue
- I believe throwing exceptions is expensive, and I'm wondering if it
would be cheaper to do something else
- one could say this falls in the "using exceptions for flow control"
category (because that's what I'll have to do on the higher level)
- I briefly looked at returning null, but it looks like this would
require checks for null to avoid NPE in a number of places
I'm not sure this needs to change, but it's been on my mind for a
while now. On my end I can simply catch this ugly exception and eat
it, although this "NoSuchElementException" is so non-specific that if
I just catch NoSuchElementException the code may one day end up
catching a NoSuchElementException from some other part of Taste.
Thoughts?
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Re: Taste: throwing NoSuchElementException
Hello,
- Original Message
> From: Sean Owen
>
> Yeah let's see, to boil it down: either way there has to be a way to
> signal the user isn't known, and either way the caller has to handle
> it. I've always preferred exceptions to null, all else being equal. I
> don't mind the idea of exceptions being used for control flow; they
> aren't that expensive. (In a performance-critical block, OK, I'd use
> null instead, but here, this case is rare enough that I don't think
> performance is a factor.)
I think this last bit is an assumption. I'm working with a setup where 80% of
recommendation requests will be for unknown users.
Imagine a web site that is not super sticky. New users pass through all the
time. Most users are irregular visitors. The system gets their ID from a
cookie, but doesn't know much else about that user.
> Catching an exception needs a bit more code than handling null. You
> can't force a caller to handle null, but you can force a caller to
> handle an exception -- but here I'm using an unchecked exception so
> that doesn't matter anyway. You have a point about catching this maybe
> masking another exception.
>
> I could be talked into changing this, but here, I think the right
> behavior for a DataModel is to know about all users that exist, not
> just ones with preferences. That is this user should be known in your
> situation.
I think there'll always be unknown users in my case. The reason I have such a
high % of unknown users is because in addition to what I described above, I
furthermore skip "noisy users" and don't have the FileDataModel read them. I
skip users who don't have much history - users for whom I don't have enough
data to make good recommendations. If I keep them, they consume my precious
JVM heap and recommendation computation is slower. If I skip them, I see
noticeable improvement in performance (and I haven't noticed degradation in
quality so far... should I have?)
> But are you using FileDataModel or something similar? because this
> condition isn't really fulfilled by this implementation. It only knows
> about users that have expressed a preference, by its nature. That can
> be addressed so that you can express users, without expressing a
> preference.
I think the above explains my particular situation.
> If this is the issue -- let me attack that issue directly to solve
> this, and punt on the exception vs. null discussion. Am I right?
I'm doing okay performance-wise after I skip my noisy users, so this is not a
huge problem for me. Perhaps just changing the exception to a specific checked
exception would be an improvement if handling null is too much of a pain.
Otis
> On 21 Jan 2009, 3:23 PM, "Otis Gospodnetic" wrote:
>
> Hello,
>
> Question about NoSuchElementException usage in Taste:
>
> I'm using Taste in an environment where lots of requests for
> recommended items are for users who are new to the system - users who
> have no previously consumed items. When I try to get recommendations
> for such users, the following is thrown:
>
> java.util.NoSuchElementException
>at
> org.apache.mahout.cf.taste.impl.model.BooleanUserGenericDataModel.getUser(BooleanUserGenericDataModel.java:81)
>at
> org.apache.mahout.cf.taste.impl.model.file.BooleanPrefUserFileDataModel.getUser(BooleanPrefUserFileDataModel.java:163)
>at
> org.apache.mahout.cf.taste.impl.recommender.BooleanUserGenericUserBasedRecommender.recommend(BooleanUserGenericUserBasedRecommender.java:86)
>
> This looks correct, and comes from this piece of code in
> BooleanUserGenericDataModel (the same happens in non-Boolean versions
> of the code):
>
> public User getUser(Object id) {
>User user = userMap.get(id);
>if (user == null) {
> throw new NoSuchElementException();
>}
>return user;
> }
>
>
> I'm wondering if this is good/best thing to do here. Here is some reasoning:
> - it's not really an error to ask a RE to recommend items for a user
> the RE knows nothing about - it's the cold start issue
> - I believe throwing exceptions is expensive, and I'm wondering if it
> would be cheaper to do something else
> - one could say this falls in the "using exceptions for flow control"
> category (because that's what I'll have to do on the higher level)
> - I briefly looked at returning null, but it looks like this would
> require checks for null to avoid NPE in a number of places
>
> I'm not sure this needs to change, but it's been on my mind for a
> while now. On my end I can simply catch this ugly exception and eat
> it, although this "NoSuchElementException" is so non-specific that if
> I just catch NoSuchElementException the code may one day end up
> catching a NoSuchElementException from some other part of Taste.
>
> Thoughts?
>
> Otis
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
@Override annotations
I'm trying to compile the latest Mahout trunk on my MacBook using the JVM 1.6.0 JRE and the @Override annotations are causing a lot of errors. There must be a simple solution to this problem but I cannot recall it. Can somebody help? Jeff PGP.sig Description: PGP signature
Re: @Override annotations
Delete them? On Wed, Jan 21, 2009 at 9:07 PM, Jeff Eastman wrote: > I'm trying to compile the latest Mahout trunk on my MacBook using the JVM > 1.6.0 JRE and the @Override annotations are causing a lot of errors. There > must be a simple solution to this problem but I cannot recall it. Can > somebody help? > > Jeff > -- Ted Dunning, CTO DeepDyve 4600 Bohannon Drive, Suite 220 Menlo Park, CA 94025 www.deepdyve.com 650-324-0110, ext. 738 858-414-0013 (m)
Re: @Override annotations
IIRC, Eclipse adds them erroneously but some versions do not complain. I believe it is incorrect to use override annotations for implementing methods defined in interfaces. Am I the only person experiencing this problem? Jeff Ted Dunning wrote: Delete them? On Wed, Jan 21, 2009 at 9:07 PM, Jeff Eastman wrote: I'm trying to compile the latest Mahout trunk on my MacBook using the JVM 1.6.0 JRE and the @Override annotations are causing a lot of errors. There must be a simple solution to this problem but I cannot recall it. Can somebody help? Jeff PGP.sig Description: PGP signature
Re: @Override annotations
More seriously, that means that the method that is annotated that way should be over-riding something and it isn't. If isn't supposed to over-ride something, then deleting the annotation is the right thing to do. If it IS supposed to over-ride and it isn't doing that, then you have found a bug. It is real unlikely that the compiler is complaining without reason. On Wed, Jan 21, 2009 at 9:22 PM, Ted Dunning wrote: > > Delete them? > > > On Wed, Jan 21, 2009 at 9:07 PM, Jeff Eastman > wrote: > >> I'm trying to compile the latest Mahout trunk on my MacBook using the JVM >> 1.6.0 JRE and the @Override annotations are causing a lot of errors. There >> must be a simple solution to this problem but I cannot recall it. Can >> somebody help? >> >> Jeff >> > > > > -- > Ted Dunning, CTO > DeepDyve > 4600 Bohannon Drive, Suite 220 > Menlo Park, CA 94025 > www.deepdyve.com > 650-324-0110, ext. 738 > 858-414-0013 (m) > > -- Ted Dunning, CTO DeepDyve 4600 Bohannon Drive, Suite 220 Menlo Park, CA 94025 www.deepdyve.com 650-324-0110, ext. 738 858-414-0013 (m)
Re: @Override annotations
See here: http://blogs.sun.com/ahe/?entry=override The upshot: If you want to generate code that compiles cleanly on 1.5 and 1.6, then you need to remove @override where you have implementations rather than over-rides. This makes @override wy less useful and makes eclipse a little bit more of a pisser to use. On Wed, Jan 21, 2009 at 9:27 PM, Jeff Eastman wrote: > IIRC, Eclipse adds them erroneously but some versions do not complain. I > believe it is incorrect to use override annotations for implementing methods > defined in interfaces. > > Am I the only person experiencing this problem? > > Jeff > > > > Ted Dunning wrote: > >> Delete them? >> >> On Wed, Jan 21, 2009 at 9:07 PM, Jeff Eastman > >wrote: >> >> >> >>> I'm trying to compile the latest Mahout trunk on my MacBook using the JVM >>> 1.6.0 JRE and the @Override annotations are causing a lot of errors. >>> There >>> must be a simple solution to this problem but I cannot recall it. Can >>> somebody help? >>> >>> Jeff >>> >>> >>> >> >> >> >> >> > > -- Ted Dunning, CTO DeepDyve 4600 Bohannon Drive, Suite 220 Menlo Park, CA 94025 www.deepdyve.com 650-324-0110, ext. 738 858-414-0013 (m)
Re: @Override annotations
There are a lot of them and the commit log sez Sean added them: "Big ol' patch that mostly adds @Override for interface methods, for Java 6, but also tacks on a number of small performance tweaks and other small refactorings". Am I the only person seeing this problem? Jeff Ted Dunning wrote: More seriously, that means that the method that is annotated that way should be over-riding something and it isn't. If isn't supposed to over-ride something, then deleting the annotation is the right thing to do. If it IS supposed to over-ride and it isn't doing that, then you have found a bug. It is real unlikely that the compiler is complaining without reason. On Wed, Jan 21, 2009 at 9:22 PM, Ted Dunning wrote: Delete them? On Wed, Jan 21, 2009 at 9:07 PM, Jeff Eastman wrote: I'm trying to compile the latest Mahout trunk on my MacBook using the JVM 1.6.0 JRE and the @Override annotations are causing a lot of errors. There must be a simple solution to this problem but I cannot recall it. Can somebody help? Jeff -- Ted Dunning, CTO DeepDyve 4600 Bohannon Drive, Suite 220 Menlo Park, CA 94025 www.deepdyve.com 650-324-0110, ext. 738 858-414-0013 (m) PGP.sig Description: PGP signature
Re : @Override annotations
Last time I tried to compile the Mahout trunk, I got a similar problem. In my case, I'm using Eclipse and the errors were caused by the JDK Compliance Level (in the project properties). In short, I was using JVM 1.6 JRE but with 5.0 compliance level (forgot to change it !). I found the answer in the following link: http://dev.eclipse.org/newslists/news.eclipse.newcomer/msg19329.html --- En date de : Jeu 22.1.09, Jeff Eastman a écrit : > De: Jeff Eastman > Objet: @Override annotations > À: mahout-dev@lucene.apache.org > Date: Jeudi 22 Janvier 2009, 6h07 > I'm trying to compile the latest Mahout trunk on my > MacBook using the JVM 1.6.0 JRE and the @Override > annotations are causing a lot of errors. There must be a > simple solution to this problem but I cannot recall it. Can > somebody help? > > Jeff
