Re: I don't get it anymore (if ever): OSB pR increases linearly with message size. Is that by design?

   From: "Ger Hobbelt" <[email protected]>

   The problem is twofold: I think I can explain why this also happens
   for bigger messages: if a three-word message 'A B C' has pR P1 and 'A
   B C A B C' gets pR P2 ~ 2*P1, then that is caused by the 'counting'
   done in the classifier code; I'd say then that the length of the
   message doesn't matter; just the fact that the 'duplication' _always_
   means HALF your features will be dupes so completely correlated, will
   hence always cause the same effect.
    <unique> would sensibly work for messages of any length as it would
   remove any glaring correlation in the features.

Well, it gets rid of some of it.  It does not get rid of all of it;
that would require knowledge of the cross-correlation of every phrase
fragment versus every other phrase fragment in the entire language.

That's why the bit-entropy and compressive classifiers hold such 
promise; they are built on the expectation of that correlation.  But
experimental reality shows that they are still in the same ballpark
accuracy-wise, and that only for very large test sets.


   What worries me as well (if not more) is the second fact I mentioned
   in passing. That is:

   learn('A B D', bad)
   learn('A B C', good)
   classify('A B C') -> c1
   learn('A B C', good)
   classify('A B C') -> c2
   learn('A B C', good)
   classify('A B C') -> c3

   does not significantly 'push' message 'A B C' into the 'good' zone
   (incrementally with each 'learn')): pR value c3 is quite close to c1.
   Keep this up a few hundred rounds even and you still are stuck with a
   relative low pR (progression is asymptomatic, as I'd expect, just not
   the asymptote value I wished for ;-) ). This is because in the code
   the two cpcorr[] correction factors pressure my 'good' Ps down (and
   lift 'bad' up) as much as I can train them (because cpcorr[] assigns
   global weights based on the number of trainings in each CSS); so any
   added 'importance' I give my features by additional learning (which
   runs up their learncounts correctly) is (almost) lost.

   I have been thinking about adjusting those learncount-per-feature
   based weights, based on their occurrence in _both_ camps, but not sure
   about it. Too little clarity about what is _really_ going on
   math-wise.

   I fear this is another error of mine due to (over)simplification of my
   thought model and that really bothers me.

What cpcorr is for is to renormalize the total number of learns done
in the current file versus the total number of learns in all of the
files.  The idea is that a feature in a file with only one LEARN done 
on it will have each feature weighted three times as heavily as 
a file with three LEARNs done in it.

And yes, it does tend to marginalize repeated learnings of the
same single text.  That's supposedly a good thing, in that 
it makes one-shot learning more of a reality.

If you want to take it out, go to line 1232++ in crm_osb_bayes.c
and change the cpcorr setting to 1.00 always.

    - 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=/