Re: bug in mailfilter.crm for training: wrong spam training threshold decision (+ extra: code duping / unreachable code fix)

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

   just above that line it says (and read VERY carefully):

	       classify <:*:clf:> [:text:] /:*:lcr:/ \
		       (:*:fileprefix::*:spamcss: :*:fileprefix::*:nonspamcss: )\
		       (:classify_status:)

   See what is missing? The '|' pipe symbol!

Nope.  Look a little further.  Here's the same line (I think)
with further context:

           #      Not cached...
            #
            #    Verify that we need to learn this first (TOE strategy)
            classify <:*:clf:> [:text:] /:*:lcr:/ \
                    (:*:fileprefix::*:spamcss: :*:fileprefix::*:nonspamcss: )\
                    (:classify_status:)
            match [:classify_status:] <nomultiline> \  <<<<< ---  HERE 
                 /^#0.* pR: ([-. 0-9]+)/ (:: :pr:)
            eval /:@: :*:pr: < :*:thick_threshold: : /
            #
            #     write out the pre-mutilation text, with newlines
            #
            output [:*:fileprefix:spamtext.txt] <append> /\n\n:*:cmd_txt: \n/
            learn < :*:clf:> (:*:fileprefix::*:spamcss:) [:text:] /:*:lcr:/
            call /:mungmail_add:/ [X-CRM114-Action: LEARNED SPAM]
            call /:mungmail_unique:/ [X-CRM114-Status: Good (Spam Learn)]
            accept
            exit /:*:accepted_mail_exit_code:/
        }

Note that the next thing is to pluck the pR value of spamcss from 
the :classify_status: variable, then to EVAL it to see that it is less
than :thick_threshold:

In short, the pass/fail of the CLASSIFY is thrown away; what's
useful here is the pR of file 0 which should be _positive_ for 
"more than spammy enough".

That's why there's a "serious lack of | symbols" in much of the
code- if you're doing thick threshold stuff, you do the pR comparison
in a second EVAL statement.


   And unless I am VERY wrong (and I got my mouth and foot ready to plant
   in former...), this will significantly b0rk attempts to train in a
   non-cache environment as the classify joins both CSS files on a single
   side.
   Wrong? Or Right?



   Despite the hour (~ 6 AM) my guess is I've hit paydirt, so I kicked
   out the minor smartness (no more css swap in classify) and then the
   fix for #1 is this:
   (yes, the pipe symbol is /consistently/ lacking in mailfilter.crm in
   the non-cached learn situations...)

   @@ -619,31 +831,29 @@
		       #   No, it didn't exist.  Add an error message header.
		       call /:mungmail_add:/ [X-CRM114-ERROR: No cached text with that
   cacheID, so nothing done!]
		       accept
		       exit /:*:accepted_mail_exit_code:/
		   }
	   }
   -	{     #  No cacheing, so we learn "natively"
   +        {
   +            #  No cacheing, so we learn "natively"
		   #
		   #    Verify that we need to learn this first (TOE strategy)
		   classify <:*:clf:> [:text:] /:*:lcr:/ \
   -		  (:*:fileprefix::*:nonspamcss: :*:fileprefix::*:spamcss: ) \
   +              (:*:fileprefix::*:nonspamcss: | :*:fileprefix::*:spamcss: ) \
		     (:classify_status:)
		   match [:classify_status:] <nomultiline> \
			   /^#0.* pR: ([-. 0-9]+)/ (:: :pr:)
   -		eval /:@: :*:pr: < :*:thick_threshold: :/
   +            eval /:@: :*:pr: < :*:good_threshold: :/    # was
   comparison against 'thick_threshold'
		   output [:*:fileprefix:nonspamtext.txt] \
			   <DEFANGED_append> /\n\n:*:cmd_txt:\n/
		   #
		   #     write out the pre-mutilation text, with newlines
		   #
		   learn <:*:clf:> (:*:fileprefix::*:nonspamcss:) [:text:] /:*:lcr:/
		   call /:mungmail_add:/ [X-CRM114-Action: LEARNED NONSPAM]
		    call /:mungmail_unique:/ [X-CRM114-Status: Good (Learn)]
   -                accept
   -                exit /:*:accepted_mail_exit_code:/

		   accept
		   exit /:*:accepted_mail_exit_code:/
	   }
	   alius
	   {
   @@ -721,17 +941,18 @@
	   }
	   {
	       #      Not cached...
	       #
	       #    Verify that we need to learn this first (TOE strategy)
	       classify <:*:clf:> [:text:] /:*:lcr:/ \
   -		    (:*:fileprefix::*:spamcss: :*:fileprefix::*:nonspamcss: )\
   +                    (:*:fileprefix::*:nonspamcss: |
   :*:fileprefix::*:spamcss: )\
		       (:classify_status:)
	       match [:classify_status:] <nomultiline> \
		       /^#0.* pR: ([-. 0-9]+)/ (:: :pr:)
   -	    eval /:@: :*:pr: < :*:thick_threshold: : /
   +            # eval /:@: :*:pr: > (0 - :*:thick_threshold:) : /
   +            eval /:@: :*:pr: > :*:spam_threshold: : /   # are we not
   yet recognized as spam?
	       #
	       #     write out the pre-mutilation text, with newlines
	       #
	       output [:*:fileprefix:spamtext.txt] <DEFANGED_append> /\n\n:*:cmd_txt: \n/
	       learn < :*:clf:> (:*:fileprefix::*:spamcss:) [:text:] /:*:lcr:/
	       call /:mungmail_add:/ [X-CRM114-Action: LEARNED SPAM]



   Conclusion:

   a) I should clean my glasses and maybe splurge on reading lessons
   because I apparently can't do code reviews anymore.

   b) we, ah, um, might benefit from an extended test suite.



   (And in case anyone is wondering: why am I seeing the same issue (pipe
   missing in classify) in mailreaver @ 542 and no!body gets hurt?  :-S
   :-S :-S
   I must've forgotten to pay the brain bill, 'cause they sure as Hell
   have disconnected *me*, as I can't see how that ever would have worked
   out well given OSB et al, as the '|' pipe (vbar_seen) is used to
   determine which CSS files are 'left' and which are 'right' (succhash
   variable in most prod classifier C code) and that should have had some
   serious effect on the pR output, shouldn't it?)

Nope... it's just a little idiom that you hadn't seen before.

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