On May 2, 2008, at 2:35 PM, Jeff Eastman wrote:
Hi Grant,
Well, the tests all run as advertised. The nature of the algorithm
itself is not obvious from the tests or the comments, and so it
leaves one needing to reverse-engineer that part. This might be
simple if the reader already understands Bayesian classifiers, but
others (like me) could use additional help. Perhaps more comments in
the code and more explanations in the wiki would be a useful adjunct
or else I should buy "ML for Dummies".
I don't know about ML for Dummies, but "Programming Collective
Intelligence" is pretty nice, even if you don't know python. As an
exercise, a few years back, I started doing a "Paper of the Week" blog
(now stagnant, but always interested in guest authors ;-), but that's
an off list discussion ) as a personal way to get more into ML at
least from the theoretical side, having worked mainly on rule-based
systems (and some ML) in a practical manner for most of my career. It
was helpful, and occasionally I even would try implementing. I
managed to stick with it for a couple of months before life got in the
way...
At any rate, I am in the process of writing up more docs. Naive Bayes
is relatively straightforward from the training side, basically, as I
understand it as glorified word counting algorithm, at least at the
simplistic level. One of the things I am interested in, is seeing
what improvements can be made, etc. as well as learning more on the
complementary NB this summer.
I also notice you use assertTrue() exclusively in your tests.
AssertEquals() gives more useful error messages - what was found vs.
what was expected - when it fails and you might want to consider
using that method in situations where you are comparing values.
Yeah, I have these old standby "live templates" in IntelliJ that I
tend to use. I probably should update them.
I was able to get DummyObjectCollector committed in the brief SVN
window yesterday.
I did see that. Makes sense.
Will you also be adding the lucene jar to the lib?
As of now, yes, but I was debating how to do it. I want to keep the
core dependencies down, as the Lucene dep. really is only for helping
create the feature vector and not "core". I was thinking it might be
better served in a Utility lib that we ship separately, but wanted to
get other opinions. I know Ted has some interesting ideas on using
Lucene on MAHOUT-7 so maybe it does fit in core.
-Grant
