Re: size of variables in hyperspace?

but ger's point is still very welcome, because i'm worrying that when
i plonk in a fresh file that hasn't been meticulously trained on the
errors from previous categories (and remove the original .chs-file),
the bottom sort of falls out of the categorizer's ability to recognize
the very basic elements of that category.


On Tue, Jul 21, 2009 at 3:37 PM, Thomas Michael
Hagen<[email protected]> wrote:
> one big aspect of my project is that it is not an ongoing one!
>
> i haven't explicitly mentioned this, but the whole gradual chain thing
> is not really applicable since i'm supposed to only train until the
> categorizer is good enough to tag the whole corpus, and then never
> train it further.
>
>
>
> On Tue, Jul 21, 2009 at 3:24 PM, Ger Hobbelt<[email protected]> wrote:
>> Actually, one can think of Chris' concept as a booster of depth=0,
>> when you think of the boost chain as limited (like a 'sliding window'
>> ;-) ).
>> Which makes Chris' the simplest to build, but you can expand it into
>> boosting-a-la-Bill by folding & delayed autotraining.
>>
>> Think of this: assume a booster chain with, say, two stages, i.e. 2
>> classifications and thus 2 CSS DBs per category: the initial one (C0),
>> the next one which gets trained to correct the errors in C0, hence
>> called C1.
>> Since C1 must overrule errors in C0, it needs to overpower C0 with its
>> verdict, hence that pR = pR(C0) + 2*pR(C1) scheme Bill mentions.
>>
>> Now the tacky bit is you want to ditch C0 after a while and replace
>> it, and the same goes for C1.
>> So you've a C2 lurking in the background, which is fed all the vetted
>> items, i.e. the entire training feed of C1, and it is trained on those
>> as well.
>>
>> Since C2 is being groomed to replace C0 in a while, it needs more than
>> just this, so we also queue a delayed feed of all the other incoming,
>> which the verdicts attached. (This system assumes that a verdict by
>> C0+C1 is good when a certain delay time T has elapsed; any human
>> corrections will have happened before that moment, or they won't make
>> it into C2; this is a potential source of lessened quality of C2, but
>> even so it'll become better than C0 is, or so we hope. Anyway, after T
>> elapses, we can autotrain C2 on the delayed feed as we now 'know' that
>> data is correctly vetted by the existing system+human monitors.
>>
>> After a time X we ditch C0+C1 and put C2 in place as the new C0, while
>> starting any subsequent training in a fresh, empty C3, which is the
>> new C1.
>>
>> Further improvement can be had by not just plonking in a fresh empty
>> C3 but already prepping it by feeding it any items that C2 didn't
>> train well on: sometimes you end up with items that are a bear to
>> train, so those can be moved to the C3 training queue while we were
>> still using C0+C1 as the live ones, thus producing a completely
>> preloaded boost chain C2+C3 when we discard C0+C1.
>>
>> The benefit of this is that we can still use the boost method to cope
>> with the error-only training after this, while during preload we make
>> sure the later errors are trained _before_ the ones that don't trouble
>> us, thanks to the delayed feed.
>>
>>
>> Just a thought; haven't done this in Real Life yet, but it might be
>> worth it for the extra few percent score improvement you might get
>> from the boosting approach.
>>
>>
>>
>>
>>
>> On Tue, Jul 21, 2009 at 2:36 PM, Thomas Michael
>> Hagen<[email protected]> wrote:
>>> chris' solution, where you gradually get rid of the old .chs-files,
>>> sounds more implementable than bill's version with doubling weights.
>>>
>>> i'm now running a new .chs-file for the sports articles, and plan on
>>> ditching the old one when the classifier gets confident on the new
>>> one.
>>>
>>> i have not trained enough data to notice ger's comment on big O for
>>> hyperspace, but that could become a problem as the amount of data
>>> increases. that's partly why i would like to do it chris' way and get
>>> rid of old .chs-files every now and then.
>>
>>
>>
>>
>> --
>> 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
>> --------------------------------------------------
>>
>

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge