Re: Mixed 64-bit system GerH binaries / BillYscripts --> two-sided training? YES!
"Ger Hobbelt" <[email protected]>
| Newsgroups | gmane.mail.spam.crm114 |
|---|---|
| Message-ID | <[email protected]> |
Spot on for OSB and colleagues (had the same thought myself a while back), but CRM114 also has 'growing' classifiers, i.e. classifiers without constant filesize (HyperSpace IIRC, BE and other 'experimentals' can also 'grow' the CSS file) and for those *I* would not know how to 'mix&merge' the two CSS files into one. Which is kind of a showstopper for me regarding 'bundled' CSS. Which doesn't mean it's not doable and a great idea besides. Advocate of the Devil here: the only 'drawback' I can see is when you intend to 're-use' single CSS files in multiple A/B comparisons based on different CSS file combos: merging all those into one will bottleneck the training if that can be applied to a single pair A/B in a large set of N CSS files (as they are re-used). It's VERY hypothetical and please don't ask why you'ld want to do a scheme like that, but I am fairly sure Bill never thought of /my/ application of CRM114 either when he started out, and I don't know about other 'wicked' uses of CRM114 out there, so I hang back a little regarding support for 'bundled CSS', that's all. > Hey, all we'd need to modify is "just" the whole .CSS concept, after > all, and perhaps a few hundred thousand lines of (existing and working) > code... :-) Aw, heck, trivialities, that. What's the word? "Negligible"? ;-)))) Anyhow, good thinking IMO. (And side note: you can even do it when the hash/word must exist on both sides, but then the CSS total size stays the same compared to today. When you can prove hash on one side only, you can introduce 'negative counts' to signal side (good vs bad) and store same amount of info in about half the total file size. ;-) (Where I 'forget' to mention a few details, but no time for long elaborations now.) ) <sorry for choppy text above, but now I must go back to my prayer beads and hope the next phonecall is a green light instead of another failure report for my release tomorrow...> Ger On Sun, Aug 31, 2008 at 8:01 PM, C. Cau <crm114-tRhV7SAp1/[email protected]> wrote: > I'm now wondering whether the idea of having more than 1 .CSS file is > still a good idea... > > I mean: as things stand now, we (crm114, that is) implicitly make a few > assumptions when opening a certain .CSS file, like the class the tokens > score should be attributed to (good/bad or perhaps 1/2/3/...) and a few > other things. > > Now, if we push forward the concept of two-sided training, why the heck > shouldn't we merge the N .CSS files into a single, unified in > fact, .CSS file? > > What sounds clear enough to me is that the nasty 'the' word Ger > complains about :-) would be present only once as a hash, and with a > neutral score. Ah, the class the score is related to doesn't exist yet > in the .CSS files, perhaps? > > Hey, all we'd need to modify is "just" the whole .CSS concept, after > all, and perhaps a few hundred thousand lines of (existing and working) > code... :-) > > cheers, > > Corrado > > > On Sunday 31 August 2008, Ger Hobbelt wrote: > [...] >> When you look at such CSS files and 'read' the files, you can say >> that in both CSS files the common word 'the' has an extremely high >> 'weight' (the 'count'!) which only 'equals out' if your >> classification takes the DIFFERENCE between left and right weight of >> a word[*] AND MOST IMPORTANTLY: you stuck religiously to the >> 'balanced training' dogma. [*]= (does _your_ classifier do that? > [...] >> The 'solution' (which will require extensive field testing, but I can >> hope, can I?): >> >> First of all, I need the training code to 'know about' the COMPLETE >> set of CSS files - as they are fed to the 'classify' statement as >> well. Right now, 'learn' only gets to see ONE of the buggers. Dang! > [...] > > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [email protected] mobile: +31-6-11 120 978 -------------------------------------------------- ------------------------------------------------------------------------- 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=/