Re: Fwd: general document classification using crm114

Bill Yerazunis <[email protected]>
Newsgroups gmane.mail.spam.crm114
Message-ID <[email protected]>
   From: "Ger Hobbelt" <[email protected]>

   On Fri, Jul 18, 2008 at 1:18 PM, Hoon-Young Cho <[email protected]> wrote:
   >  Bit Entropy sounds promising..but, if documents can be tokenized (or word
   >  -delimited), then can BE beat other approaches? anyway, I think I have to
   >  try your first or second approach first before I can test the BE method.

   I don't have numbers on this, so I don't know if BE will beat other
   classifiers given that you are able to tokenize the input.
   Besides, since your documents are rather short, you'll probably
   experience different behaviour for any classifier as most published
   material is about (longer) emails.

   Anyway, a good thing would be to create your own particular test set
   for testing the various classifiers (and learn methods! Learn methods
   can have a huge impact on the results) and see which one works best
   for your data feed.

Yes, very much so.  

   Oh, and since you have such small documents, DO NOT take my advice of
   'making them look like emails': the added data, though identical for
   all data files then, will noticably influence your pR numbers. Think
   of it like this: say you add a 'header' line to make it look like a
   real email; that line is 5 words. Your /actual/ data is only 10 words,
   so that makes a document of 15 words. Now IF a classifier X finds one
   of those words to be 'remarkable' (either good or bad), generally
   speaking its influence on the final pR number will be somewhat reduced
   when it's only one shouting in a sea of 15 instead of a lake of 10. I
   know, not all classifiers work like this, and it also depends on the
   options/flags you feed your classifier, but when you don't know
   /exactly/ what your classifier does to your data & numbers, it's
   better not to introduce the extra risk of 'watering' your results this
   way.
   For larger documents it's no matter, because the added amount is
   insignificant, but for your small sized documents, the impact /can/ be
   huge.

Also true.

   So that would mean you'ld better go the route of checking out the
   mail*.crm scripts -- they can handle your data as is, btw -- and see
   what you want to do with that.

   If you wish to improve your numbers, and given your data
   specifications now, I'd say: start with testing various learn methods.
   mailtrainer.crm supports them all, in a way, it's just that you'll
   need to 'translate' the various published methods (e.g. TOE, TONE,
   etc.) into the proper valaues for the various parameters in
   mailconfig.cf to configure mailtrainer.crm act in different ways.

Maybe.... but if you have a big bash script on top anyway, you
might be better off using the short little scripts from the
manual to learn and to classify.

   - Bill Yerazunis

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.