The stuff in the book is largely just the command line stuff and doesn't go into much detail about API access to the NB stuff.
My own lamentable tendency would be to prototype the algorithm using Plume, partly to push Plume development and partly to see if that helps build API oriented map-reduce components. I say lamentable because a straightforward implementation would definitely be done sooner. On Sat, Sep 25, 2010 at 9:52 AM, Sean Owen <[email protected]> wrote: > I think it's fine to do a rewrite at this stage. 0.5 sounds like a > nice goal. Just recall that aspects of this will be 'in print' soon so > yeah you want to a) plan to deprecate rather than remove the old code > for some time, b) make the existing code "forwards compatible" with > what you'll do next while you have the chance! > > On Sat, Sep 25, 2010 at 2:32 PM, Robin Anil <[email protected]> wrote: > > Hi, I was in the middle of changing the classifier over to to vectors and > I > > realized how radically it will change for people using it and how > difficult > > it is to fit the new interfaces ted checked it. There are many components > to > > it, including the Hbase stuff, which will take a lot of time to port. I > > think its best to start from scratch rewrite it, keeping the old version > so > > that it wont break for users using it?. If that is agreeable, I can > complete > > a new map/reduce + imemory classifier in o.a.m.c.naivebayes fitting the > > interfaces and deprecate the old bayes package?. The new package wont > have > > the full set of features as the old for 0.4 release. But it will be > > functional, and hopefully future proof. Let me know your thoughts > > > > Robin > > >
