tmva-users — Open mailing list for TMVA users

[TMVA-users] Save plots in png format

[Betty C. <bet...@ce...>]

Dear experts,

I see here [1] instructions to save plots in png format, but as I'm

using the root TMVA (so I can't modify the root code), I wonder how I

should do that in my code?

Regards

[1]

https://root.cern.ch/doc/v606/tmvaglob_8cxx_source.html

Re: [TMVA-users] When can I use BDTD

[Betty C. <bet...@ce...>]

Dear Helge,

ok, thank you very much for your answers.

Regards

On 10/17/16 3:35 PM, Helge Voss wrote:
> Sure!
>
> You need to understand that: Different options just lead to a somewhat
> different classifier, and all you care about is to get the best
> performing classifier for your problem.
> ... nothing else matters :)   (well, as always:  as long as you study
> it's true performance, i.e. have a proper test sample to estimate its
> unbiased performance etc.etc)
>
> Helge
>
>
> On 17 October 2016 at 15:03, Betty Calpas <bet...@ce...> wrote:
>> Dear Helge,
>>
>> thank you for the explanation. So you mean that
>>
>> I can play with any option, as long as the code
>>
>> does not crash, and then keep the one which give
>>
>> me the best figure of merith?
>>
>> For example, if I'm using the BDT with strong
>>
>> correlated variables (>80%), but that the code does not crash,
>>
>> and I have nice a BDT variable distribution, can I still
>>
>> be confident in the results?
>>
>> Regards
>>
>>
>> On 10/14/16 11:38 AM, Helge Voss wrote:
>>> Hi,
>>>
>>>
>>>> percentage value (VAL) can we start to use the BDTD?
>>>    I don't think there can be a 'general answer' given ... guess you have
>>> to try
>>> (just 'do it' and see if your performance gets better or not ;) )
>>>
>>> Please note: BDTD is just a 'name given to an example' which shows the
>>> usage
>>> of the 'variable transormation' as an argument give to the BookMethod
>>> command. The other options in the option string are totally
>>> independent from that.
>>> ... I just want to make sure you just don't chose "BDTD" instead of "BDT"
>>> in the
>>> 'command line' of the call to our example "TMVAClassification.C"  when
>>> testing
>>> how 'variable decorrelation' affects your training :)   as all the
>>> other options
>>> like MaxDept, NTrees, etc.. also might be different in those examples..
>>>
>>>> - if I have many variables some have VAL > "values from previous
>>>> question"
>>>> and
>>>>
>>>> other have VAL < "values from previous question", can I still used the
>>>> BDTD?
>>> Well, sure, as I said: Just try :)
>>>
>>> In addition, there has been an option implemented at some point that
>>> allows to
>>> de-correlated only a subset of variables. But I have to admit, I never
>>> tried it and
>>> I don't even know it's syntax anymore. If interested.. mail Peter
>>> Speckmayer :)
>>>
>>>> - is there a "non linear correlation coe fficients" plot?
>>> Sure, the 'variable scatter plots'  :)    (they are produced however
>>> only by default
>>> if you number of variables is smaller than .. I guess it was 20..)
>>>
>>>> - Because to make a decision we need to know both the linear and
>>>> non-linear
>>>> coefficient, right?
>>> sure .. but as I said, in the end, nothing will save you from 'trying'
>>> (testing) ..
>>> to see what works best..
>>>
>>> ( of course, making well informed trials makes a lot of sense, I'm
>>> just trying to
>>> make the point again that there is no: wrong classifier .. just .. bad
>>> performing
>>> ones , and one should 'play' with the various options to get the best one
>>> :)  )
>>>
>>> Cheers,
>>>
>>> Helge
>>>
>>>
>>> Cheers,
>>>
>>> Helge
>>>
>>>
>>>> Regards
>>>>
>>>>
>>>> On 10/14/16 10:37 AM, Helge Voss wrote:
>>>>> Hi Betty,
>>>>>
>>>>> well... the 'decorrelation' option is eliminating 'linear
>>>>> correlations" between variables,
>>>>> but all 'non-linear dependencies' between variables it cannot handle
>>>>> and the therefore
>>>>> you should still try to find variables that are as little correlated
>>>>> as possible.
>>>>>
>>>>> (and .. applying blindely a  linear decorrelation algorithm to
>>>>> variables that are not "linear" correlated
>>>>> by in some other 'weird' way, may well result in variables that are
>>>>> more complicated to handle by
>>>>> the algorithm (i.e. the BDT or some other classifier) than the
>>>>> original ones. Hence one should use
>>>>> it with care (i.e. check how the variables look after the
>>>>> decorrelation attempt etc..)
>>>>>
>>>>> Helge
>>>>>
>>>>>
>>>>>
>>>>> On 14 October 2016 at 08:57, Betty Calpas <bet...@ce...> wrote:
>>>>>> Dear experts,
>>>>>>
>>>>>> I wonder in which cases is it recommend to use the BDTD method.
>>>>>>
>>>>>> Indeed I understood that it is better to do not use correlated
>>>>>> variables,
>>>>>>
>>>>>> but there is a decorrelation option right? so if I use this option,
>>>>>>
>>>>>> should I still care about the variable correlation?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> TMVA-users mailing list
>>>>>> TMV...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>>>
>>>>
>>>> --
>>>>
>>>> Cheers,
>>>> Betty
>>>>
>>
>> --
>>
>> Cheers,
>> Betty
>>


-- 

Cheers,
Betty

Re: [TMVA-users] When can I use BDTD

[Helge V. <Hel...@ce...>]

Sure!

You need to understand that: Different options just lead to a somewhat
different classifier, and all you care about is to get the best
performing classifier for your problem.
... nothing else matters :)   (well, as always:  as long as you study
it's true performance, i.e. have a proper test sample to estimate its
unbiased performance etc.etc)

Helge


On 17 October 2016 at 15:03, Betty Calpas <bet...@ce...> wrote:
> Dear Helge,
>
> thank you for the explanation. So you mean that
>
> I can play with any option, as long as the code
>
> does not crash, and then keep the one which give
>
> me the best figure of merith?
>
> For example, if I'm using the BDT with strong
>
> correlated variables (>80%), but that the code does not crash,
>
> and I have nice a BDT variable distribution, can I still
>
> be confident in the results?
>
> Regards
>
>
> On 10/14/16 11:38 AM, Helge Voss wrote:
>>
>> Hi,
>>
>>
>>> percentage value (VAL) can we start to use the BDTD?
>>
>>   I don't think there can be a 'general answer' given ... guess you have
>> to try
>> (just 'do it' and see if your performance gets better or not ;) )
>>
>> Please note: BDTD is just a 'name given to an example' which shows the
>> usage
>> of the 'variable transormation' as an argument give to the BookMethod
>> command. The other options in the option string are totally
>> independent from that.
>> ... I just want to make sure you just don't chose "BDTD" instead of "BDT"
>> in the
>> 'command line' of the call to our example "TMVAClassification.C"  when
>> testing
>> how 'variable decorrelation' affects your training :)   as all the
>> other options
>> like MaxDept, NTrees, etc.. also might be different in those examples..
>>
>>> - if I have many variables some have VAL > "values from previous
>>> question"
>>> and
>>>
>>> other have VAL < "values from previous question", can I still used the
>>> BDTD?
>>
>> Well, sure, as I said: Just try :)
>>
>> In addition, there has been an option implemented at some point that
>> allows to
>> de-correlated only a subset of variables. But I have to admit, I never
>> tried it and
>> I don't even know it's syntax anymore. If interested.. mail Peter
>> Speckmayer :)
>>
>>> - is there a "non linear correlation coe fficients" plot?
>>
>> Sure, the 'variable scatter plots'  :)    (they are produced however
>> only by default
>> if you number of variables is smaller than .. I guess it was 20..)
>>
>>> - Because to make a decision we need to know both the linear and
>>> non-linear
>>> coefficient, right?
>>
>> sure .. but as I said, in the end, nothing will save you from 'trying'
>> (testing) ..
>> to see what works best..
>>
>> ( of course, making well informed trials makes a lot of sense, I'm
>> just trying to
>> make the point again that there is no: wrong classifier .. just .. bad
>> performing
>> ones , and one should 'play' with the various options to get the best one
>> :)  )
>>
>> Cheers,
>>
>> Helge
>>
>>
>> Cheers,
>>
>> Helge
>>
>>
>>> Regards
>>>
>>>
>>> On 10/14/16 10:37 AM, Helge Voss wrote:
>>>>
>>>> Hi Betty,
>>>>
>>>> well... the 'decorrelation' option is eliminating 'linear
>>>> correlations" between variables,
>>>> but all 'non-linear dependencies' between variables it cannot handle
>>>> and the therefore
>>>> you should still try to find variables that are as little correlated
>>>> as possible.
>>>>
>>>> (and .. applying blindely a  linear decorrelation algorithm to
>>>> variables that are not "linear" correlated
>>>> by in some other 'weird' way, may well result in variables that are
>>>> more complicated to handle by
>>>> the algorithm (i.e. the BDT or some other classifier) than the
>>>> original ones. Hence one should use
>>>> it with care (i.e. check how the variables look after the
>>>> decorrelation attempt etc..)
>>>>
>>>> Helge
>>>>
>>>>
>>>>
>>>> On 14 October 2016 at 08:57, Betty Calpas <bet...@ce...> wrote:
>>>>>
>>>>> Dear experts,
>>>>>
>>>>> I wonder in which cases is it recommend to use the BDTD method.
>>>>>
>>>>> Indeed I understood that it is better to do not use correlated
>>>>> variables,
>>>>>
>>>>> but there is a decorrelation option right? so if I use this option,
>>>>>
>>>>> should I still care about the variable correlation?
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> TMVA-users mailing list
>>>>> TMV...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>>
>>>
>>>
>>> --
>>>
>>> Cheers,
>>> Betty
>>>
>
>
> --
>
> Cheers,
> Betty
>

Re: [TMVA-users] When can I use BDTD

[Betty C. <bet...@ce...>]

Dear Helge,

thank you for the explanation. So you mean that

I can play with any option, as long as the code

does not crash, and then keep the one which give

me the best figure of merith?

For example, if I'm using the BDT with strong

correlated variables (>80%), but that the code does not crash,

and I have nice a BDT variable distribution, can I still

be confident in the results?

Regards

On 10/14/16 11:38 AM, Helge Voss wrote:
> Hi,
>
>
>> percentage value (VAL) can we start to use the BDTD?
>   I don't think there can be a 'general answer' given ... guess you have to try
> (just 'do it' and see if your performance gets better or not ;) )
>
> Please note: BDTD is just a 'name given to an example' which shows the usage
> of the 'variable transormation' as an argument give to the BookMethod
> command. The other options in the option string are totally
> independent from that.
> ... I just want to make sure you just don't chose "BDTD" instead of "BDT" in the
> 'command line' of the call to our example "TMVAClassification.C"  when testing
> how 'variable decorrelation' affects your training :)   as all the
> other options
> like MaxDept, NTrees, etc.. also might be different in those examples..
>
>> - if I have many variables some have VAL > "values from previous question"
>> and
>>
>> other have VAL < "values from previous question", can I still used the BDTD?
> Well, sure, as I said: Just try :)
>
> In addition, there has been an option implemented at some point that allows to
> de-correlated only a subset of variables. But I have to admit, I never
> tried it and
> I don't even know it's syntax anymore. If interested.. mail Peter Speckmayer :)
>
>> - is there a "non linear correlation coe fficients" plot?
> Sure, the 'variable scatter plots'  :)    (they are produced however
> only by default
> if you number of variables is smaller than .. I guess it was 20..)
>
>> - Because to make a decision we need to know both the linear and non-linear
>> coefficient, right?
> sure .. but as I said, in the end, nothing will save you from 'trying'
> (testing) ..
> to see what works best..
>
> ( of course, making well informed trials makes a lot of sense, I'm
> just trying to
> make the point again that there is no: wrong classifier .. just .. bad
> performing
> ones , and one should 'play' with the various options to get the best one :)  )
>
> Cheers,
>
> Helge
>
>
> Cheers,
>
> Helge
>
>
>> Regards
>>
>>
>> On 10/14/16 10:37 AM, Helge Voss wrote:
>>> Hi Betty,
>>>
>>> well... the 'decorrelation' option is eliminating 'linear
>>> correlations" between variables,
>>> but all 'non-linear dependencies' between variables it cannot handle
>>> and the therefore
>>> you should still try to find variables that are as little correlated
>>> as possible.
>>>
>>> (and .. applying blindely a  linear decorrelation algorithm to
>>> variables that are not "linear" correlated
>>> by in some other 'weird' way, may well result in variables that are
>>> more complicated to handle by
>>> the algorithm (i.e. the BDT or some other classifier) than the
>>> original ones. Hence one should use
>>> it with care (i.e. check how the variables look after the
>>> decorrelation attempt etc..)
>>>
>>> Helge
>>>
>>>
>>>
>>> On 14 October 2016 at 08:57, Betty Calpas <bet...@ce...> wrote:
>>>> Dear experts,
>>>>
>>>> I wonder in which cases is it recommend to use the BDTD method.
>>>>
>>>> Indeed I understood that it is better to do not use correlated variables,
>>>>
>>>> but there is a decorrelation option right? so if I use this option,
>>>>
>>>> should I still care about the variable correlation?
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> TMVA-users mailing list
>>>> TMV...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>
>>
>> --
>>
>> Cheers,
>> Betty
>>


-- 

Cheers,
Betty

Re: [TMVA-users] Parse a variable as an option

[Betty C. <bet...@ce...>]

Hi experts,

to solve this I had to use %% in the Form (answer from the ROOT experts).

MinNodeSize=5%  --> MinNodeSize=5%%


Regards

On 10/15/16 5:49 PM, Helge Voss wrote:
> Hi, Betty,
>
> that's because there "%" signs in the option string, and the "Form()
> function tries to interpret them as 'format strings'..
> so you have to 'escape' th one after
>
> MinNodeSize=5%  --> MinNodeSize=5\%     t
>
> that should then work
>
> Helge
>
>
> On 15 October 2016 at 16:02, Betty Calpas <bet...@ce...> wrote:
>> Hi Peter,
>>
>> thank you for your answer.
>>
>> When I did [1], I have the warning message[2], why?
>>
>> PS: notice that in the warning it says "orm(..." while I used "Form(..."
>>
>> Regards
>>
>> [1]
>>    int ntree{50};
>>    factory->BookMethod( TMVA::Types::kBDT, "BDTD",
>>    Form("!H:!V:NTrees=%i:MinNodeSize=5%:MaxDepth=3...", ntree) );
>>
>> [2]
>> main.cc:165:138: warning: unknown conversion type character ':' in format
>> [-Wformat=]
>>
>> orm("!H:!V:NTrees=%i:MinNodeSize=5%:MaxDepth=3:BoostType=AdaBoost:SeparationType=GiniIndex:nCuts=20:VarTransform=Decorrelate",
>> ntree) );
>>
>>
>>
>> On 10/15/16 4:28 PM, Peter Speckmayer wrote:
>>
>> Do 'Form' for the whole option.
>>
>> Form("!H:!V:NTrees=%g:MinNodeSize=3:MaxDepth=3..", var)
>>
>> Cheers,
>>
>> Peter
>>
>>
>>
>> Betty Calpas <bet...@ce...> schrieb am Sa., 15. Okt. 2016, 15:37:
>>> Dear experts,
>>>
>>> in the expression [1], if for example I want to parse the "NTrees=100"
>>> option
>>>
>>> as a variable (I tried [2] without success) do you know how I can do that?
>>>
>>> Regards
>>>
>>>
>>> [1]
>>>
>>> factory->BookMethod( TMVA::Types::kBDT, "BDT",
>>> "!H:!V:NTrees=100:MinNodeSize=5%:MaxDepth=3...);
>>>
>>> [2]
>>>
>>> int val=100
>>>
>>> factory->BookMethod( TMVA::Types::kBDT, "BDT", "!H:!V:NTrees= Form("%g",
>>> val):MinNodeSize=5%:MaxDepth=3...);
>>>
>>>
>>> Regards
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TMVA-users mailing list
>>> TMV...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>
>>
>> --
>>
>> Cheers,
>> Betty
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TMVA-users mailing list
>> TMV...@li...
>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>


-- 

Cheers,
Betty

Re: [TMVA-users] Spikes in BDTD distribution

[Betty C. <bet...@ce...>]

Dear experts,

I understood what was wrong.

Regards

On 10/15/16 3:43 PM, Betty Calpas wrote:
> Dear experts,
>
> I have spikes in my BDTD distribution (see cc) and I wonder if it is 
> normal?
>
> If not, I checked the overtraining plots, and the agreement was ok, so 
> what
>
> can be the reason to have them? Can this be a statistical fluctuation?
>
> or some default weigh applied by the BDTD...
>
> Please let me know if you need have more information.
>
> Regards
>


-- 

Cheers,
Betty

Re: [TMVA-users] Parse a variable as an option

[Betty C. <bet...@ce...>]

Hi Helge,

sorry, I'm confused and did not well understood what you meant, so I tried:

- [1] and I still get [2].

- [3] and I got [4]

what is wrong (the problem seems to come to the ":")?

Regards

[1]
  Form("!H:!V:NTrees=%i:MinNodeSize=5\%:MaxDepth=3:BoostType=AdaBoost:SeparationType=GiniIndex:nCuts=20:VarTransform=Decorrelate", ntree) );

[2]
main.cc:167:139: warning: unknown conversion type character ':' in 
format [-Wformat=]
Form("!H:!V:NTrees=%i:MinNodeSize=5\%:MaxDepth=3:BoostType=AdaBoost:SeparationType=GiniIndex:nCuts=20:VarTransform=Decorrelate", 
ntree) );


[3]
factory->BookMethod( TMVA::Types::kBDT, "BDTD",
        Form("!H:!V:NTrees=%i:MinNodeSize=5\% 
t:MaxDepth=3:BoostType=AdaBoost:SeparationType=GiniIndex:nCuts=20:VarTransform=Decorrelate", 
ntree) );

[4]
main.cc:167:145: warning: repeated ' ' flag in format [-Wformat=]
  rm("!H:!V:NTrees=%i:MinNodeSize=5\% 
t:MaxDepth=3:BoostType=AdaBoost:SeparationType=GiniIndex:nCuts=20:VarTransform=Decorrelate", 
ntree) );
^
main.cc:167:145: warning: repeated ' ' flag in format [-Wformat=]
main.cc:167:145: warning: repeated ' ' flag in format [-Wformat=]
main.cc:167:145: warning: repeated ' ' flag in format [-Wformat=]
main.cc:167:145: warning: unknown conversion type character ':' in 
format [-Wformat=]


On 10/15/16 5:49 PM, Helge Voss wrote:
> Hi, Betty,
>
> that's because there "%" signs in the option string, and the "Form()
> function tries to interpret them as 'format strings'..
> so you have to 'escape' th one after
>
> MinNodeSize=5%  --> MinNodeSize=5\%     t
>
> that should then work
>
> Helge
>
>
> On 15 October 2016 at 16:02, Betty Calpas <bet...@ce...> wrote:
>> Hi Peter,
>>
>> thank you for your answer.
>>
>> When I did [1], I have the warning message[2], why?
>>
>> PS: notice that in the warning it says "orm(..." while I used "Form(..."
>>
>> Regards
>>
>> [1]
>>    int ntree{50};
>>    factory->BookMethod( TMVA::Types::kBDT, "BDTD",
>>    Form("!H:!V:NTrees=%i:MinNodeSize=5%:MaxDepth=3...", ntree) );
>>
>> [2]
>> main.cc:165:138: warning: unknown conversion type character ':' in format
>> [-Wformat=]
>>
>> orm("!H:!V:NTrees=%i:MinNodeSize=5%:MaxDepth=3:BoostType=AdaBoost:SeparationType=GiniIndex:nCuts=20:VarTransform=Decorrelate",
>> ntree) );
>>
>>
>>
>> On 10/15/16 4:28 PM, Peter Speckmayer wrote:
>>
>> Do 'Form' for the whole option.
>>
>> Form("!H:!V:NTrees=%g:MinNodeSize=3:MaxDepth=3..", var)
>>
>> Cheers,
>>
>> Peter
>>
>>
>>
>> Betty Calpas <bet...@ce...> schrieb am Sa., 15. Okt. 2016, 15:37:
>>> Dear experts,
>>>
>>> in the expression [1], if for example I want to parse the "NTrees=100"
>>> option
>>>
>>> as a variable (I tried [2] without success) do you know how I can do that?
>>>
>>> Regards
>>>
>>>
>>> [1]
>>>
>>> factory->BookMethod( TMVA::Types::kBDT, "BDT",
>>> "!H:!V:NTrees=100:MinNodeSize=5%:MaxDepth=3...);
>>>
>>> [2]
>>>
>>> int val=100
>>>
>>> factory->BookMethod( TMVA::Types::kBDT, "BDT", "!H:!V:NTrees= Form("%g",
>>> val):MinNodeSize=5%:MaxDepth=3...);
>>>
>>>
>>> Regards
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TMVA-users mailing list
>>> TMV...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>
>>
>> --
>>
>> Cheers,
>> Betty
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TMVA-users mailing list
>> TMV...@li...
>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>


-- 

Cheers,
Betty

Re: [TMVA-users] Parse a variable as an option

[Helge V. <Hel...@ce...>]

Hi, Betty,

that's because there "%" signs in the option string, and the "Form()
function tries to interpret them as 'format strings'..
so you have to 'escape' th one after

MinNodeSize=5%  --> MinNodeSize=5\%     t

that should then work

Helge


On 15 October 2016 at 16:02, Betty Calpas <bet...@ce...> wrote:
> Hi Peter,
>
> thank you for your answer.
>
> When I did [1], I have the warning message[2], why?
>
> PS: notice that in the warning it says "orm(..." while I used "Form(..."
>
> Regards
>
> [1]
>   int ntree{50};
>   factory->BookMethod( TMVA::Types::kBDT, "BDTD",
>   Form("!H:!V:NTrees=%i:MinNodeSize=5%:MaxDepth=3...", ntree) );
>
> [2]
> main.cc:165:138: warning: unknown conversion type character ':' in format
> [-Wformat=]
>
> orm("!H:!V:NTrees=%i:MinNodeSize=5%:MaxDepth=3:BoostType=AdaBoost:SeparationType=GiniIndex:nCuts=20:VarTransform=Decorrelate",
> ntree) );
>
>
>
> On 10/15/16 4:28 PM, Peter Speckmayer wrote:
>
> Do 'Form' for the whole option.
>
> Form("!H:!V:NTrees=%g:MinNodeSize=3:MaxDepth=3..", var)
>
> Cheers,
>
> Peter
>
>
>
> Betty Calpas <bet...@ce...> schrieb am Sa., 15. Okt. 2016, 15:37:
>>
>> Dear experts,
>>
>> in the expression [1], if for example I want to parse the "NTrees=100"
>> option
>>
>> as a variable (I tried [2] without success) do you know how I can do that?
>>
>> Regards
>>
>>
>> [1]
>>
>> factory->BookMethod( TMVA::Types::kBDT, "BDT",
>> "!H:!V:NTrees=100:MinNodeSize=5%:MaxDepth=3...);
>>
>> [2]
>>
>> int val=100
>>
>> factory->BookMethod( TMVA::Types::kBDT, "BDT", "!H:!V:NTrees= Form("%g",
>> val):MinNodeSize=5%:MaxDepth=3...);
>>
>>
>> Regards
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TMVA-users mailing list
>> TMV...@li...
>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>
>
>
> --
>
> Cheers,
> Betty
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> TMVA-users mailing list
> TMV...@li...
> https://lists.sourceforge.net/lists/listinfo/tmva-users
>

[TMVA-users] Spikes in BDTD distribution

[Betty C. <bet...@ce...>]

Dear experts,

I have spikes in my BDTD distribution (see cc) and I wonder if it is normal?

If not, I checked the overtraining plots, and the agreement was ok, so what

can be the reason to have them? Can this be a statistical fluctuation?

or some default weigh applied by the BDTD...

Please let me know if you need have more information.

Regards

Re: [TMVA-users] Parse a variable as an option

[Betty C. <bet...@ce...>]

Hi Peter,

thank you for your answer.

When I did [1], I have the warning message[2], why?

PS: notice that in the warning it says "orm(..." while I used "Form(..."

Regards

[1]
   int ntree{50};
   factory->BookMethod( TMVA::Types::kBDT, "BDTD",
   Form("!H:!V:NTrees=%i:MinNodeSize=5%:MaxDepth=3...", ntree) );

[2]
main.cc:165:138: warning: unknown conversion type character ':' in 
format [-Wformat=]
  orm("!H:!V:NTrees=%i:MinNodeSize=5%:MaxDepth=3:BoostType=AdaBoost:SeparationType=GiniIndex:nCuts=20:VarTransform=Decorrelate", ntree) );


On 10/15/16 4:28 PM, Peter Speckmayer wrote:
> Do 'Form' for the whole option.
>
> Form("!H:!V:NTrees=%g:MinNodeSize=3:MaxDepth=3..", var)
>
> Cheers,
>
> Peter
>
>
>
> Betty Calpas <bet...@ce... <mailto:bet...@ce...>> 
> schrieb am Sa., 15. Okt. 2016, 15:37:
>
>     Dear experts,
>
>     in the expression [1], if for example I want to parse the "NTrees=100"
>     option
>
>     as a variable (I tried [2] without success) do you know how I can
>     do that?
>
>     Regards
>
>
>     [1]
>
>     factory->BookMethod( TMVA::Types::kBDT, "BDT",
>     "!H:!V:NTrees=100:MinNodeSize=5%:MaxDepth=3...);
>
>     [2]
>
>     int val=100
>
>     factory->BookMethod( TMVA::Types::kBDT, "BDT", "!H:!V:NTrees=
>     Form("%g",
>     val):MinNodeSize=5%:MaxDepth=3...);
>
>
>     Regards
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>     _______________________________________________
>     TMVA-users mailing list
>     TMV...@li...
>     <mailto:TMV...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tmva-users
>


-- 

Cheers,
Betty

Re: [TMVA-users] Parse a variable as an option

[Peter S. <pet...@gm...>]

Do 'Form' for the whole option.

Form("!H:!V:NTrees=%g:MinNodeSize=3:MaxDepth=3..", var)

Cheers,

Peter



Betty Calpas <bet...@ce...> schrieb am Sa., 15. Okt. 2016, 15:37:

Dear experts,

in the expression [1], if for example I want to parse the "NTrees=100"
option

as a variable (I tried [2] without success) do you know how I can do that?

Regards


[1]

factory->BookMethod( TMVA::Types::kBDT, "BDT",
"!H:!V:NTrees=100:MinNodeSize=5%:MaxDepth=3...);

[2]

int val=100

factory->BookMethod( TMVA::Types::kBDT, "BDT", "!H:!V:NTrees= Form("%g",
val):MinNodeSize=5%:MaxDepth=3...);


Regards

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TMVA-users mailing list
TMV...@li...
https://lists.sourceforge.net/lists/listinfo/tmva-users

[TMVA-users] Parse a variable as an option

[Betty C. <bet...@ce...>]

Dear experts,

in the expression [1], if for example I want to parse the "NTrees=100" 
option

as a variable (I tried [2] without success) do you know how I can do that?

Regards


[1]

factory->BookMethod( TMVA::Types::kBDT, "BDT", 
"!H:!V:NTrees=100:MinNodeSize=5%:MaxDepth=3...);

[2]

int val=100

factory->BookMethod( TMVA::Types::kBDT, "BDT", "!H:!V:NTrees= Form("%g", 
val):MinNodeSize=5%:MaxDepth=3...);


Regards

Re: [TMVA-users] When can I use BDTD

[Helge V. <Hel...@ce...>]

Hi,


> percentage value (VAL) can we start to use the BDTD?

 I don't think there can be a 'general answer' given ... guess you have to try
(just 'do it' and see if your performance gets better or not ;) )

Please note: BDTD is just a 'name given to an example' which shows the usage
of the 'variable transormation' as an argument give to the BookMethod
command. The other options in the option string are totally
independent from that.
... I just want to make sure you just don't chose "BDTD" instead of "BDT" in the
'command line' of the call to our example "TMVAClassification.C"  when testing
how 'variable decorrelation' affects your training :)   as all the
other options
like MaxDept, NTrees, etc.. also might be different in those examples..

>
> - if I have many variables some have VAL > "values from previous question"
> and
>
> other have VAL < "values from previous question", can I still used the BDTD?

Well, sure, as I said: Just try :)

In addition, there has been an option implemented at some point that allows to
de-correlated only a subset of variables. But I have to admit, I never
tried it and
I don't even know it's syntax anymore. If interested.. mail Peter Speckmayer :)

>
> - is there a "non linear correlation coe fficients" plot?

Sure, the 'variable scatter plots'  :)    (they are produced however
only by default
if you number of variables is smaller than .. I guess it was 20..)

>
> - Because to make a decision we need to know both the linear and non-linear
> coefficient, right?

sure .. but as I said, in the end, nothing will save you from 'trying'
(testing) ..
to see what works best..

( of course, making well informed trials makes a lot of sense, I'm
just trying to
make the point again that there is no: wrong classifier .. just .. bad
performing
ones , and one should 'play' with the various options to get the best one :)  )

Cheers,

Helge


Cheers,

Helge


>
> Regards
>
>
> On 10/14/16 10:37 AM, Helge Voss wrote:
>>
>> Hi Betty,
>>
>> well... the 'decorrelation' option is eliminating 'linear
>> correlations" between variables,
>> but all 'non-linear dependencies' between variables it cannot handle
>> and the therefore
>> you should still try to find variables that are as little correlated
>> as possible.
>>
>> (and .. applying blindely a  linear decorrelation algorithm to
>> variables that are not "linear" correlated
>> by in some other 'weird' way, may well result in variables that are
>> more complicated to handle by
>> the algorithm (i.e. the BDT or some other classifier) than the
>> original ones. Hence one should use
>> it with care (i.e. check how the variables look after the
>> decorrelation attempt etc..)
>>
>> Helge
>>
>>
>>
>> On 14 October 2016 at 08:57, Betty Calpas <bet...@ce...> wrote:
>>>
>>> Dear experts,
>>>
>>> I wonder in which cases is it recommend to use the BDTD method.
>>>
>>> Indeed I understood that it is better to do not use correlated variables,
>>>
>>> but there is a decorrelation option right? so if I use this option,
>>>
>>> should I still care about the variable correlation?
>>>
>>> Regards
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TMVA-users mailing list
>>> TMV...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>
>
>
> --
>
> Cheers,
> Betty
>

Re: [TMVA-users] When can I use BDTD

[Betty C. <bet...@ce...>]

Hi Helge,

if I have many variables (>5):

- from the "linear correlation coefficients" plot, from which

percentage value (VAL) can we start to use the BDTD?

- if I have many variables some have VAL > "values from previous 
question" and

other have VAL < "values from previous question", can I still used the BDTD?

- is there a "non linear correlation coefficients" plot?

- Because to make a decision we need to know both the linear and 
non-linear coefficient, right?

Regards

On 10/14/16 10:37 AM, Helge Voss wrote:
> Hi Betty,
>
> well... the 'decorrelation' option is eliminating 'linear
> correlations" between variables,
> but all 'non-linear dependencies' between variables it cannot handle
> and the therefore
> you should still try to find variables that are as little correlated
> as possible.
>
> (and .. applying blindely a  linear decorrelation algorithm to
> variables that are not "linear" correlated
> by in some other 'weird' way, may well result in variables that are
> more complicated to handle by
> the algorithm (i.e. the BDT or some other classifier) than the
> original ones. Hence one should use
> it with care (i.e. check how the variables look after the
> decorrelation attempt etc..)
>
> Helge
>
>
>
> On 14 October 2016 at 08:57, Betty Calpas <bet...@ce...> wrote:
>> Dear experts,
>>
>> I wonder in which cases is it recommend to use the BDTD method.
>>
>> Indeed I understood that it is better to do not use correlated variables,
>>
>> but there is a decorrelation option right? so if I use this option,
>>
>> should I still care about the variable correlation?
>>
>> Regards
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TMVA-users mailing list
>> TMV...@li...
>> https://lists.sourceforge.net/lists/listinfo/tmva-users


-- 

Cheers,
Betty

Re: [TMVA-users] When can I use BDTD

[Helge V. <Hel...@ce...>]

Hi Betty,

well... the 'decorrelation' option is eliminating 'linear
correlations" between variables,
but all 'non-linear dependencies' between variables it cannot handle
and the therefore
you should still try to find variables that are as little correlated
as possible.

(and .. applying blindely a  linear decorrelation algorithm to
variables that are not "linear" correlated
by in some other 'weird' way, may well result in variables that are
more complicated to handle by
the algorithm (i.e. the BDT or some other classifier) than the
original ones. Hence one should use
it with care (i.e. check how the variables look after the
decorrelation attempt etc..)

Helge



On 14 October 2016 at 08:57, Betty Calpas <bet...@ce...> wrote:
> Dear experts,
>
> I wonder in which cases is it recommend to use the BDTD method.
>
> Indeed I understood that it is better to do not use correlated variables,
>
> but there is a decorrelation option right? so if I use this option,
>
> should I still care about the variable correlation?
>
> Regards
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> TMVA-users mailing list
> TMV...@li...
> https://lists.sourceforge.net/lists/listinfo/tmva-users

[TMVA-users] When can I use BDTD

[Betty C. <bet...@ce...>]

Dear experts,

I wonder in which cases is it recommend to use the BDTD method.

Indeed I understood that it is better to do not use correlated variables,

but there is a decorrelation option right? so if I use this option,

should I still care about the variable correlation?

Regards

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Betty C. <bet...@ce...>]

Hi Helge,

ok, thank you for your answers.

Regards

On 10/12/16 12:13 PM, Helge Voss wrote:
> Hi,
>
>
>     ok, thank you. I still wonder if it makes sense to think that
>
>     we may gain in sensitivity if we train the MVA with
>
>     a number of signal evt very high compare to the evt of bkg?
>
>
> ​sure, using the same (effective/weighted) number of signal and background
> for the training is just a 'reasonable default' and one could play 
> with other
> relative weightings. That​'s what the 'NormMode=None' and the 
> possibility to
> apply your own tree weights is for.
>
> In principle the 'thought' was that the more the signal is weighted in 
> the training
> the larger the 'a-prioro' or 'prior' probability of an event being a 
> signal would be
> for the classifier, hence it would be more easily classify s.th 
> <http://s.th>. as signal --> focusing
> the classifier to have 'high efficience".
>
> On the other hand, as small weight on signal would mean a smaller 
> prior for signal
> and should result in classifiers more focused on 'high background 
> rejection' ..
>
> However, on a (small) test I did on that, I couldn't really find this 
> behaviour that I expected...
> but you could try  (I only made one very small test) !
>
> Helge
>
>
>
>
>
>
>     Regards
>
>     On 10/12/16 11:54 AM, Helge Voss wrote:
>>     Yes, you got it :)
>>
>>     Helge
>>
>>
>>     On 12 October 2016 at 10:49, Betty Calpas <bet...@ce...
>>     <mailto:bet...@ce...>> wrote:
>>
>>         Hi Helge,
>>
>>         so I can either:
>>
>>         - normalize by hand the signal and the bkgs to a luminosity
>>         (use NormMode=None)
>>
>>         - or normalize only the bkgs to a luminosity, and do not
>>         normalize
>>
>>         the signal (use NormMode=NumEvents). In this case it will use
>>         the same number
>>
>>         of evt for the bkgs and the signal.
>>
>>         - Is the second point correct?
>>
>>         Cheers,
>>         Betty
>>
>>
>>
>>
>>
>>         On 10/12/16 11:24 AM, Helge Voss wrote:
>>>         Exactly !
>>>
>>>         And if you do this 'by hand' (i.e. setting the accoring
>>>         'tree weights') just make sure that you don't have a
>>>         'NormMode=NumEvents' but 'NormMode=None' ) in the
>>>         factory->PrepareTrainingAndTestTree(..) call ..
>>>
>>>         (the option: NormMode=NumEvents  would otherwise overwrite
>>>         your relative weighting between the total of your background
>>>         and the total of your signal, by scaling them again such
>>>         that the total (scaled) number of background events is the
>>>         same a s teh total (scaled) number of signal events.)
>>>
>>>         Of course, you could also 'forget' completely about the
>>>         relative weighting between signal and background and simply
>>>         use "NormMode=NumEvents" :)
>>>         (you only need to make sure you have the relative weighting
>>>         of the different background sources worked out correctly ...
>>>         which is why my first email only treated that part ...)
>>>
>>>         Helge
>>>
>>>
>>>
>>>         On 12 October 2016 at 10:03, Betty Calpas
>>>         <bet...@ce... <mailto:bet...@ce...>> wrote:
>>>
>>>             Hi Helge,
>>>
>>>             so you mean that I can scale the bkg and the signal in
>>>             to different way?
>>>
>>>             - for the bkg1, bkg2 ... I can apply for each evt the
>>>             weight w1, w2 ...
>>>
>>>             with the same luminosity:
>>>
>>>             w1 = cs1 * lumi / ngenerated_evt_1
>>>
>>>             w2 = cs2 * lumi / ngenerated_evt_2
>>>
>>>             ...
>>>
>>>             - and for the signal I can use (any luminosity):
>>>
>>>             ws = css * lumi*100 / ngenerated_evt_s
>>>
>>>             Regards
>>>
>>>
>>>
>>>             On 10/11/16 7:00 PM, Helge Voss wrote:
>>>>             Hi,
>>>>
>>>>             what I said was for 'normalizing' the various
>>>>             background sources relative to each other.
>>>>             For the normalization of the signal vs your collective
>>>>             backgrounds, you're right, it is
>>>>             typically better to have them both normalized to the
>>>>             same number of events..
>>>>
>>>>             You want to discriminate events distributed like your
>>>>             signal events  from events that
>>>>             are distributed according the sum of all your
>>>>             background events.
>>>>
>>>>             You want to make sure that the 'sum of background
>>>>             events' are distributed like in the
>>>>             data (i.e. all different sources weighted to the same
>>>>             integrated luminosity generated),
>>>>
>>>>             Scaling the signal doesn't change the distribution ..
>>>>             so you can happily scale the signal
>>>>             to a different integrated luminosity .. and you should
>>>>             (e.g. to the same number of events)
>>>>
>>>>             it's not that you would 'overtrain' otherwise .. but if
>>>>             your signal is very small compared to the background,
>>>>             the classifier would otherwise simply have to classify
>>>>             everything as 'background' and already
>>>>             perform very good... the classifier simply wouldn't get
>>>>             an 'incentive' to actually identify your
>>>>             signal.
>>>>
>>>>             Cheers,
>>>>
>>>>             Helge
>>>>
>>>>             On 11 October 2016 at 17:11, Betty Calpas
>>>>             <bet...@ce... <mailto:bet...@ce...>> wrote:
>>>>
>>>>                 Hi Helge,
>>>>
>>>>                 sure, but if I normalize to get the expected evt
>>>>                 number, for a Higgs signal
>>>>
>>>>                 the number is very low, and we will have
>>>>                 overtraining. Am I wrong?
>>>>
>>>>                 So I wonder how to normalize the sample btw them
>>>>                 and avoid low number (in signal sample) issue?
>>>>
>>>>                 Regards
>>>>
>>>>                 On 10/11/16 5:03 PM, Helge Voss wrote:
>>>>>                 Hi Betty,
>>>>>
>>>>>                 well, obviously simply scaling by the cross
>>>>>                 section is 'meaningless' if you don't take into
>>>>>                 account the
>>>>>                 number of events generated. Just think .. in
>>>>>                 another world, maybe the guy/girl responsible for
>>>>>                 the MC
>>>>>                 generation simply generated 2x more of one
>>>>>                 particular bkg-source just because he/she regarded
>>>>>                 it as more
>>>>>                 interesting ... if you simply scale by 'cross
>>>>>                 section' you'd get a different event sample
>>>>>                 distribution w/o changing
>>>>>                 any physics..
>>>>>
>>>>>                 So you'd probably want to scale them such that the
>>>>>                 generated integrated luminosity for all bkg
>>>>>                 sources is the same. Assuming you don't
>>>>>                 have any 'preselection cuts' in the MC generation
>>>>>                 (which is probably a wrong assumption), then
>>>>>                 scaling each bkg
>>>>>                 by weighting all bkg sources i, bkg(i) by
>>>>>                  int_lum(i) is then proportional to
>>>>>                  #events(i)/crosssection(i), so in that case you'd
>>>>>                 have to
>>>>>                 get a multiplicative event weight of
>>>>>                 weight(i)=1/int_lumi(i)=crosssection(i)/#events-generated(i)
>>>>>                  ..
>>>>>
>>>>>                 that would make the distriution of the sum of the
>>>>>                 bkg events in your simulation look like that one
>>>>>                 expected in the data, which
>>>>>                 is probably a good way to go as default for any
>>>>>                 mva training (not, it's not a 'must' .. you can
>>>>>                 also somehow weigh the various
>>>>>                 types different, get a slightly different
>>>>>                 classifier... , you'd just have to watch out how
>>>>>                 to calculate backgr. rejection then ..)
>>>>>
>>>>>                 Cheers,
>>>>>
>>>>>                 Helge
>>>>>
>>>>>
>>>>>                 On 11 October 2016 at 14:27, Betty Calpas
>>>>>                 <bet...@ce...
>>>>>                 <mailto:bet...@ce...>> wrote:
>>>>>
>>>>>                     Dear,
>>>>>
>>>>>                     any idea?
>>>>>
>>>>>                     Regards
>>>>>
>>>>>
>>>>>
>>>>>                     -------- Forwarded Message --------
>>>>>                     Subject: 	Event normalization in tmva training
>>>>>                     Date: 	Tue, 11 Oct 2016 11:30:36 +0200
>>>>>                     From: 	Betty Calpas <bet...@ce...>
>>>>>                     <mailto:bet...@ce...>
>>>>>                     To: 	tmv...@li...
>>>>>                     <mailto:tmv...@li...>
>>>>>                     <tmv...@li...>
>>>>>                     <mailto:tmv...@li...>
>>>>>
>>>>>
>>>>>
>>>>>                     Dear experts,
>>>>>
>>>>>                     to normalize my bkg btw them, I multiplyed each event by
>>>>>
>>>>>                     their cross section. But the bkg samples have different
>>>>>
>>>>>                     initial number of event, so I wonder if applying the cross
>>>>>
>>>>>                     section as a weight is enough? Should I take into account
>>>>>
>>>>>                     the initial number of event?
>>>>>
>>>>>                     Regards
>>>>>
>>>>>
>>>>>                     ------------------------------------------------------------------------------
>>>>>                     Check out the vibrant tech community on one of
>>>>>                     the world's most
>>>>>                     engaging tech sites, SlashDot.org!
>>>>>                     http://sdm.link/slashdot
>>>>>                     _______________________________________________
>>>>>                     TMVA-users mailing list
>>>>>                     TMV...@li...
>>>>>                     <mailto:TMV...@li...>
>>>>>                     https://lists.sourceforge.net/lists/listinfo/tmva-users
>>>>>                     <https://lists.sourceforge.net/lists/listinfo/tmva-users>
>>>>>
>>>>>
>>>>
>>>>
>>>>                 -- 
>>>>
>>>>                 Cheers,
>>>>                 Betty
>>>>
>>>>
>>>
>>>
>>>             -- 
>>>
>>>             Cheers,
>>>             Betty
>>>
>>>
>>
>>
>>         -- 
>>
>>         Cheers,
>>         Betty
>>
>>
>
>
>     -- 
>
>     Cheers,
>     Betty
>
>


-- 

Cheers,
Betty

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Betty C. <bet...@ce...>]

Hi Helge,

ok, thank you. I still wonder if it makes sense to think that

we may gain in sensitivity if we train the MVA with

a number of signal evt very high compare to the evt of bkg?

Regards

On 10/12/16 11:54 AM, Helge Voss wrote:
> Yes, you got it :)
>
> Helge
>
>
> On 12 October 2016 at 10:49, Betty Calpas <bet...@ce... 
> <mailto:bet...@ce...>> wrote:
>
>     Hi Helge,
>
>     so I can either:
>
>     - normalize by hand the signal and the bkgs to a luminosity (use
>     NormMode=None)
>
>     - or normalize only the bkgs to a luminosity, and do not normalize
>
>     the signal (use NormMode=NumEvents). In this case it will use the
>     same number
>
>     of evt for the bkgs and the signal.
>
>     - Is the second point correct?
>
>     Cheers,
>     Betty
>
>
>
>
>
>     On 10/12/16 11:24 AM, Helge Voss wrote:
>>     Exactly !
>>
>>     And if you do this 'by hand' (i.e. setting the accoring 'tree
>>     weights') just make sure that you don't have a
>>     'NormMode=NumEvents' but 'NormMode=None' ) in the
>>     factory->PrepareTrainingAndTestTree(..) call ..
>>
>>     (the option: NormMode=NumEvents  would otherwise overwrite your
>>     relative weighting between the total of your background and the
>>     total of your signal, by scaling them again such that the total
>>     (scaled) number of background events is the same a s teh total
>>     (scaled) number of signal events.)
>>
>>     Of course, you could also 'forget' completely about the relative
>>     weighting between signal and background and simply use
>>     "NormMode=NumEvents" :)
>>     (you only need to make sure you have the relative weighting of
>>     the different background sources worked out correctly ... which
>>     is why my first email only treated that part ...)
>>
>>     Helge
>>
>>
>>
>>     On 12 October 2016 at 10:03, Betty Calpas <bet...@ce...
>>     <mailto:bet...@ce...>> wrote:
>>
>>         Hi Helge,
>>
>>         so you mean that I can scale the bkg and the signal in to
>>         different way?
>>
>>         - for the bkg1, bkg2 ... I can apply for each evt the weight
>>         w1, w2 ...
>>
>>         with the same luminosity:
>>
>>         w1 = cs1 * lumi / ngenerated_evt_1
>>
>>         w2 = cs2 * lumi / ngenerated_evt_2
>>
>>         ...
>>
>>         - and for the signal I can use (any luminosity):
>>
>>         ws = css * lumi*100 / ngenerated_evt_s
>>
>>         Regards
>>
>>
>>
>>         On 10/11/16 7:00 PM, Helge Voss wrote:
>>>         Hi,
>>>
>>>         what I said was for 'normalizing' the various background
>>>         sources relative to each other.
>>>         For the normalization of the signal vs your collective
>>>         backgrounds, you're right, it is
>>>         typically better to have them both normalized to the same
>>>         number of events..
>>>
>>>         You want to discriminate events distributed like your signal
>>>         events  from events that
>>>         are distributed according the sum of all your background events.
>>>
>>>         You want to make sure that the 'sum of background events'
>>>         are distributed like in the
>>>         data (i.e. all different sources weighted to the same
>>>         integrated luminosity generated),
>>>
>>>         Scaling the signal doesn't change the distribution .. so you
>>>         can happily scale the signal
>>>         to a different integrated luminosity .. and you should (e.g.
>>>         to the same number of events)
>>>
>>>         it's not that you would 'overtrain' otherwise .. but if your
>>>         signal is very small compared to the background,
>>>         the classifier would otherwise simply have to classify
>>>         everything as 'background' and already
>>>         perform very good... the classifier simply wouldn't get an
>>>         'incentive' to actually identify your
>>>         signal.
>>>
>>>         Cheers,
>>>
>>>         Helge
>>>
>>>         On 11 October 2016 at 17:11, Betty Calpas
>>>         <bet...@ce... <mailto:bet...@ce...>> wrote:
>>>
>>>             Hi Helge,
>>>
>>>             sure, but if I normalize to get the expected evt number,
>>>             for a Higgs signal
>>>
>>>             the number is very low, and we will have overtraining.
>>>             Am I wrong?
>>>
>>>             So I wonder how to normalize the sample btw them and
>>>             avoid low number (in signal sample) issue?
>>>
>>>             Regards
>>>
>>>             On 10/11/16 5:03 PM, Helge Voss wrote:
>>>>             Hi Betty,
>>>>
>>>>             well, obviously simply scaling by the cross section is
>>>>             'meaningless' if you don't take into account the
>>>>             number of events generated. Just think .. in another
>>>>             world, maybe the guy/girl responsible for the MC
>>>>             generation simply generated 2x more of one particular
>>>>             bkg-source just because he/she regarded it as more
>>>>             interesting ... if you simply scale by 'cross section'
>>>>             you'd get a different event sample distribution w/o
>>>>             changing
>>>>             any physics..
>>>>
>>>>             So you'd probably want to scale them such that the
>>>>             generated integrated luminosity for all bkg sources is
>>>>             the same. Assuming you don't
>>>>             have any 'preselection cuts' in the MC generation
>>>>             (which is probably a wrong assumption), then scaling
>>>>             each bkg
>>>>             by weighting all bkg sources i, bkg(i) by  int_lum(i)
>>>>             is then proportional to  #events(i)/crosssection(i), so
>>>>             in that case you'd have to
>>>>             get a multiplicative event weight of
>>>>             weight(i)=1/int_lumi(i)=crosssection(i)/#events-generated(i)
>>>>              ..
>>>>
>>>>             that would make the distriution of the sum of the bkg
>>>>             events in your simulation look like that one expected
>>>>             in the data, which
>>>>             is probably a good way to go as default for any mva
>>>>             training (not, it's not a 'must' .. you can also
>>>>             somehow weigh the various
>>>>             types different, get a slightly different classifier...
>>>>             , you'd just have to watch out how to calculate backgr.
>>>>             rejection then ..)
>>>>
>>>>             Cheers,
>>>>
>>>>             Helge
>>>>
>>>>
>>>>             On 11 October 2016 at 14:27, Betty Calpas
>>>>             <bet...@ce... <mailto:bet...@ce...>> wrote:
>>>>
>>>>                 Dear,
>>>>
>>>>                 any idea?
>>>>
>>>>                 Regards
>>>>
>>>>
>>>>
>>>>                 -------- Forwarded Message --------
>>>>                 Subject: 	Event normalization in tmva training
>>>>                 Date: 	Tue, 11 Oct 2016 11:30:36 +0200
>>>>                 From: 	Betty Calpas <bet...@ce...>
>>>>                 <mailto:bet...@ce...>
>>>>                 To: 	tmv...@li...
>>>>                 <mailto:tmv...@li...>
>>>>                 <tmv...@li...>
>>>>                 <mailto:tmv...@li...>
>>>>
>>>>
>>>>
>>>>                 Dear experts,
>>>>
>>>>                 to normalize my bkg btw them, I multiplyed each event by
>>>>
>>>>                 their cross section. But the bkg samples have different
>>>>
>>>>                 initial number of event, so I wonder if applying the cross
>>>>
>>>>                 section as a weight is enough? Should I take into account
>>>>
>>>>                 the initial number of event?
>>>>
>>>>                 Regards
>>>>
>>>>
>>>>                 ------------------------------------------------------------------------------
>>>>                 Check out the vibrant tech community on one of the
>>>>                 world's most
>>>>                 engaging tech sites, SlashDot.org!
>>>>                 http://sdm.link/slashdot
>>>>                 _______________________________________________
>>>>                 TMVA-users mailing list
>>>>                 TMV...@li...
>>>>                 <mailto:TMV...@li...>
>>>>                 https://lists.sourceforge.net/lists/listinfo/tmva-users
>>>>                 <https://lists.sourceforge.net/lists/listinfo/tmva-users>
>>>>
>>>>
>>>
>>>
>>>             -- 
>>>
>>>             Cheers,
>>>             Betty
>>>
>>>
>>
>>
>>         -- 
>>
>>         Cheers,
>>         Betty
>>
>>
>
>
>     -- 
>
>     Cheers,
>     Betty
>
>


-- 

Cheers,
Betty

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Helge V. <Hel...@ce...>]

Hi,

>
> ok, thank you. I still wonder if it makes sense to think that
>
> we may gain in sensitivity if we train the MVA with
>
> a number of signal evt very high compare to the evt of bkg?
>
>
​sure, using the same (effective/weighted) number of signal and background
for the training is just a 'reasonable default' and one could play with
other
relative weightings. That​'s what the 'NormMode=None' and the possibility to
apply your own tree weights is for.

In principle the 'thought' was that the more the signal is weighted in the
training
the larger the 'a-prioro' or 'prior' probability of an event being a signal
would be
for the classifier, hence it would be more easily classify s.th. as signal
--> focusing
the classifier to have 'high efficience".

On the other hand, as small weight on signal would mean a smaller prior for
signal
and should result in classifiers more focused on 'high background
rejection' ..

However, on a (small) test I did on that, I couldn't really find this
behaviour that I expected...
but you could try  (I only made one very small test) !

Helge








> Regards
>
> On 10/12/16 11:54 AM, Helge Voss wrote:
>
> Yes, you got it :)
>
> Helge
>
>
> On 12 October 2016 at 10:49, Betty Calpas <bet...@ce...> wrote:
>
>> Hi Helge,
>>
>> so I can either:
>>
>> - normalize by hand the signal and the bkgs to a luminosity (use
>> NormMode=None)
>>
>> - or normalize only the bkgs to a luminosity, and do not normalize
>>
>> the signal (use NormMode=NumEvents). In this case it will use the same
>> number
>>
>> of evt for the bkgs and the signal.
>>
>> - Is the second point correct?
>>
>> Cheers,
>> Betty
>>
>>
>>
>>
>>
>> On 10/12/16 11:24 AM, Helge Voss wrote:
>>
>> Exactly !
>>
>> And if you do this 'by hand' (i.e. setting the accoring 'tree weights')
>> just make sure that you don't have a 'NormMode=NumEvents' but
>> 'NormMode=None' ) in the
>> factory->PrepareTrainingAndTestTree(..) call ..
>>
>> (the option: NormMode=NumEvents  would otherwise overwrite your relative
>> weighting between the total of your background and the total of your
>> signal, by scaling them again such that the total (scaled) number of
>> background events is the same a s teh total (scaled) number of signal
>> events.)
>>
>> Of course, you could also 'forget' completely about the relative
>> weighting between signal and background and simply use "NormMode=NumEvents"
>> :)
>> (you only need to make sure you have the relative weighting of the
>> different background sources worked out correctly ... which is why my first
>> email only treated that part ...)
>>
>> Helge
>>
>>
>>
>> On 12 October 2016 at 10:03, Betty Calpas <bet...@ce...> wrote:
>>
>>> Hi Helge,
>>>
>>> so you mean that I can scale the bkg and the signal in to different way?
>>>
>>> - for the bkg1, bkg2 ... I can apply for each evt the weight w1, w2 ...
>>>
>>> with the same luminosity:
>>>
>>> w1 = cs1 * lumi / ngenerated_evt_1
>>>
>>> w2 = cs2 * lumi / ngenerated_evt_2
>>>
>>> ...
>>>
>>> - and for the signal I can use (any luminosity):
>>>
>>> ws = css * lumi*100 / ngenerated_evt_s
>>>
>>> Regards
>>>
>>>
>>>
>>> On 10/11/16 7:00 PM, Helge Voss wrote:
>>>
>>> Hi,
>>>
>>> what I said was for 'normalizing' the various background sources
>>> relative to each other.
>>> For the normalization of the signal vs your collective backgrounds,
>>> you're right, it is
>>> typically better to have them both normalized to the same number of
>>> events..
>>>
>>> You want to discriminate events distributed like your signal events
>>>  from events that
>>> are distributed according the sum of all your background events.
>>>
>>> You want to make sure that the 'sum of background events' are
>>> distributed like in the
>>> data (i.e. all different sources weighted to the same integrated
>>> luminosity generated),
>>>
>>> Scaling the signal doesn't change the distribution .. so you can happily
>>> scale the signal
>>> to a different integrated luminosity .. and you should (e.g. to the same
>>> number of events)
>>>
>>> it's not that you would 'overtrain' otherwise .. but if your signal is
>>> very small compared to the background,
>>> the classifier would otherwise simply have to classify everything as
>>> 'background' and already
>>> perform very good... the classifier simply wouldn't get an 'incentive'
>>> to actually identify your
>>> signal.
>>>
>>> Cheers,
>>>
>>> Helge
>>>
>>>
>>> On 11 October 2016 at 17:11, Betty Calpas <bet...@ce...> wrote:
>>>
>>>> Hi Helge,
>>>>
>>>> sure, but if I normalize to get the expected evt number, for a Higgs
>>>> signal
>>>>
>>>> the number is very low, and we will have overtraining. Am I wrong?
>>>>
>>>> So I wonder how to normalize the sample btw them and avoid low number
>>>> (in signal sample) issue?
>>>>
>>>> Regards
>>>>
>>>> On 10/11/16 5:03 PM, Helge Voss wrote:
>>>>
>>>> Hi Betty,
>>>>
>>>> well, obviously simply scaling by the cross section is 'meaningless' if
>>>> you don't take into account the
>>>> number of events generated. Just think .. in another world, maybe the
>>>> guy/girl responsible for the MC
>>>> generation simply generated 2x more of one particular bkg-source just
>>>> because he/she regarded it as more
>>>> interesting ... if you simply scale by 'cross section' you'd get a
>>>> different event sample distribution w/o changing
>>>> any physics..
>>>>
>>>> So you'd probably want to scale them such that the generated integrated
>>>> luminosity for all bkg sources is the same. Assuming you don't
>>>> have any 'preselection cuts' in the MC generation (which is probably a
>>>> wrong assumption), then scaling each bkg
>>>> by weighting all bkg sources i, bkg(i) by  int_lum(i) is then
>>>> proportional to  #events(i)/crosssection(i), so in that case you'd have to
>>>> get a multiplicative event weight of weight(i)=1/int_lumi(i)=crosssection(i)/#events-generated(i)
>>>>  ..
>>>>
>>>> that would make the distriution of the sum of the bkg events in your
>>>> simulation look like that one expected in the data, which
>>>> is probably a good way to go as default for any mva training (not, it's
>>>> not a 'must' .. you can also somehow weigh the various
>>>> types different, get a slightly different classifier... , you'd just
>>>> have to watch out how to calculate backgr. rejection then ..)
>>>>
>>>> Cheers,
>>>>
>>>> Helge
>>>>
>>>>
>>>> On 11 October 2016 at 14:27, Betty Calpas <bet...@ce...> wrote:
>>>>
>>>>> Dear,
>>>>>
>>>>> any idea?
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>> -------- Forwarded Message --------
>>>>> Subject: Event normalization in tmva training
>>>>> Date: Tue, 11 Oct 2016 11:30:36 +0200
>>>>> From: Betty Calpas <bet...@ce...> <bet...@ce...>
>>>>> To: tmv...@li... <tmv...@li...urceforge.
>>>>> net> <tmv...@li...>
>>>>>
>>>>> Dear experts,
>>>>>
>>>>> to normalize my bkg btw them, I multiplyed each event by
>>>>>
>>>>> their cross section. But the bkg samples have different
>>>>>
>>>>> initial number of event, so I wonder if applying the cross
>>>>>
>>>>> section as a weight is enough? Should I take into account
>>>>>
>>>>> the initial number of event?
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> TMVA-users mailing list
>>>>> TMV...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Cheers,
>>>> Betty
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Cheers,
>>> Betty
>>>
>>
>>
>>
>> --
>>
>> Cheers,
>> Betty
>>
>
>
>
> --
>
> Cheers,
> Betty
>

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Helge V. <Hel...@ce...>]

Yes, you got it :)

Helge


On 12 October 2016 at 10:49, Betty Calpas <bet...@ce...> wrote:

> Hi Helge,
>
> so I can either:
>
> - normalize by hand the signal and the bkgs to a luminosity (use
> NormMode=None)
>
> - or normalize only the bkgs to a luminosity, and do not normalize
>
> the signal (use NormMode=NumEvents). In this case it will use the same
> number
>
> of evt for the bkgs and the signal.
>
> - Is the second point correct?
>
> Cheers,
> Betty
>
>
>
>
>
> On 10/12/16 11:24 AM, Helge Voss wrote:
>
> Exactly !
>
> And if you do this 'by hand' (i.e. setting the accoring 'tree weights')
> just make sure that you don't have a 'NormMode=NumEvents' but
> 'NormMode=None' ) in the
> factory->PrepareTrainingAndTestTree(..) call ..
>
> (the option: NormMode=NumEvents  would otherwise overwrite your relative
> weighting between the total of your background and the total of your
> signal, by scaling them again such that the total (scaled) number of
> background events is the same a s teh total (scaled) number of signal
> events.)
>
> Of course, you could also 'forget' completely about the relative weighting
> between signal and background and simply use "NormMode=NumEvents" :)
> (you only need to make sure you have the relative weighting of the
> different background sources worked out correctly ... which is why my first
> email only treated that part ...)
>
> Helge
>
>
>
> On 12 October 2016 at 10:03, Betty Calpas <bet...@ce...> wrote:
>
>> Hi Helge,
>>
>> so you mean that I can scale the bkg and the signal in to different way?
>>
>> - for the bkg1, bkg2 ... I can apply for each evt the weight w1, w2 ...
>>
>> with the same luminosity:
>>
>> w1 = cs1 * lumi / ngenerated_evt_1
>>
>> w2 = cs2 * lumi / ngenerated_evt_2
>>
>> ...
>>
>> - and for the signal I can use (any luminosity):
>>
>> ws = css * lumi*100 / ngenerated_evt_s
>>
>> Regards
>>
>>
>>
>> On 10/11/16 7:00 PM, Helge Voss wrote:
>>
>> Hi,
>>
>> what I said was for 'normalizing' the various background sources relative
>> to each other.
>> For the normalization of the signal vs your collective backgrounds,
>> you're right, it is
>> typically better to have them both normalized to the same number of
>> events..
>>
>> You want to discriminate events distributed like your signal events  from
>> events that
>> are distributed according the sum of all your background events.
>>
>> You want to make sure that the 'sum of background events' are distributed
>> like in the
>> data (i.e. all different sources weighted to the same integrated
>> luminosity generated),
>>
>> Scaling the signal doesn't change the distribution .. so you can happily
>> scale the signal
>> to a different integrated luminosity .. and you should (e.g. to the same
>> number of events)
>>
>> it's not that you would 'overtrain' otherwise .. but if your signal is
>> very small compared to the background,
>> the classifier would otherwise simply have to classify everything as
>> 'background' and already
>> perform very good... the classifier simply wouldn't get an 'incentive' to
>> actually identify your
>> signal.
>>
>> Cheers,
>>
>> Helge
>>
>>
>> On 11 October 2016 at 17:11, Betty Calpas <bet...@ce...> wrote:
>>
>>> Hi Helge,
>>>
>>> sure, but if I normalize to get the expected evt number, for a Higgs
>>> signal
>>>
>>> the number is very low, and we will have overtraining. Am I wrong?
>>>
>>> So I wonder how to normalize the sample btw them and avoid low number
>>> (in signal sample) issue?
>>>
>>> Regards
>>>
>>> On 10/11/16 5:03 PM, Helge Voss wrote:
>>>
>>> Hi Betty,
>>>
>>> well, obviously simply scaling by the cross section is 'meaningless' if
>>> you don't take into account the
>>> number of events generated. Just think .. in another world, maybe the
>>> guy/girl responsible for the MC
>>> generation simply generated 2x more of one particular bkg-source just
>>> because he/she regarded it as more
>>> interesting ... if you simply scale by 'cross section' you'd get a
>>> different event sample distribution w/o changing
>>> any physics..
>>>
>>> So you'd probably want to scale them such that the generated integrated
>>> luminosity for all bkg sources is the same. Assuming you don't
>>> have any 'preselection cuts' in the MC generation (which is probably a
>>> wrong assumption), then scaling each bkg
>>> by weighting all bkg sources i, bkg(i) by  int_lum(i) is then
>>> proportional to  #events(i)/crosssection(i), so in that case you'd have to
>>> get a multiplicative event weight of weight(i)=1/int_lumi(i)=crosssection(i)/#events-generated(i)
>>>  ..
>>>
>>> that would make the distriution of the sum of the bkg events in your
>>> simulation look like that one expected in the data, which
>>> is probably a good way to go as default for any mva training (not, it's
>>> not a 'must' .. you can also somehow weigh the various
>>> types different, get a slightly different classifier... , you'd just
>>> have to watch out how to calculate backgr. rejection then ..)
>>>
>>> Cheers,
>>>
>>> Helge
>>>
>>>
>>> On 11 October 2016 at 14:27, Betty Calpas <bet...@ce...> wrote:
>>>
>>>> Dear,
>>>>
>>>> any idea?
>>>>
>>>> Regards
>>>>
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: Event normalization in tmva training
>>>> Date: Tue, 11 Oct 2016 11:30:36 +0200
>>>> From: Betty Calpas <bet...@ce...> <bet...@ce...>
>>>> To: tmv...@li... <tmv...@li...>
>>>> <tmv...@li...>
>>>>
>>>> Dear experts,
>>>>
>>>> to normalize my bkg btw them, I multiplyed each event by
>>>>
>>>> their cross section. But the bkg samples have different
>>>>
>>>> initial number of event, so I wonder if applying the cross
>>>>
>>>> section as a weight is enough? Should I take into account
>>>>
>>>> the initial number of event?
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> TMVA-users mailing list
>>>> TMV...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Cheers,
>>> Betty
>>>
>>
>>
>>
>> --
>>
>> Cheers,
>> Betty
>>
>
>
>
> --
>
> Cheers,
> Betty
>

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Betty C. <bet...@ce...>]

Hi Helge,

so I can either:

- normalize by hand the signal and the bkgs to a luminosity (use 
NormMode=None)

- or normalize only the bkgs to a luminosity, and do not normalize

the signal (use NormMode=NumEvents). In this case it will use the same 
number

of evt for the bkgs and the signal.

- Is the second point correct?

Cheers,
Betty




On 10/12/16 11:24 AM, Helge Voss wrote:
> Exactly !
>
> And if you do this 'by hand' (i.e. setting the accoring 'tree 
> weights') just make sure that you don't have a 'NormMode=NumEvents' 
> but 'NormMode=None' ) in the
> factory->PrepareTrainingAndTestTree(..) call ..
>
> (the option: NormMode=NumEvents  would otherwise overwrite your 
> relative weighting between the total of your background and the total 
> of your signal, by scaling them again such that the total (scaled) 
> number of background events is the same a s teh total (scaled) number 
> of signal events.)
>
> Of course, you could also 'forget' completely about the relative 
> weighting between signal and background and simply use 
> "NormMode=NumEvents" :)
> (you only need to make sure you have the relative weighting of the 
> different background sources worked out correctly ... which is why my 
> first email only treated that part ...)
>
> Helge
>
>
>
> On 12 October 2016 at 10:03, Betty Calpas <bet...@ce... 
> <mailto:bet...@ce...>> wrote:
>
>     Hi Helge,
>
>     so you mean that I can scale the bkg and the signal in to
>     different way?
>
>     - for the bkg1, bkg2 ... I can apply for each evt the weight w1,
>     w2 ...
>
>     with the same luminosity:
>
>     w1 = cs1 * lumi / ngenerated_evt_1
>
>     w2 = cs2 * lumi / ngenerated_evt_2
>
>     ...
>
>     - and for the signal I can use (any luminosity):
>
>     ws = css * lumi*100 / ngenerated_evt_s
>
>     Regards
>
>
>
>     On 10/11/16 7:00 PM, Helge Voss wrote:
>>     Hi,
>>
>>     what I said was for 'normalizing' the various background sources
>>     relative to each other.
>>     For the normalization of the signal vs your collective
>>     backgrounds, you're right, it is
>>     typically better to have them both normalized to the same number
>>     of events..
>>
>>     You want to discriminate events distributed like your signal
>>     events  from events that
>>     are distributed according the sum of all your background events.
>>
>>     You want to make sure that the 'sum of background events' are
>>     distributed like in the
>>     data (i.e. all different sources weighted to the same integrated
>>     luminosity generated),
>>
>>     Scaling the signal doesn't change the distribution .. so you can
>>     happily scale the signal
>>     to a different integrated luminosity .. and you should (e.g. to
>>     the same number of events)
>>
>>     it's not that you would 'overtrain' otherwise .. but if your
>>     signal is very small compared to the background,
>>     the classifier would otherwise simply have to classify everything
>>     as 'background' and already
>>     perform very good... the classifier simply wouldn't get an
>>     'incentive' to actually identify your
>>     signal.
>>
>>     Cheers,
>>
>>     Helge
>>
>>     On 11 October 2016 at 17:11, Betty Calpas <bet...@ce...
>>     <mailto:bet...@ce...>> wrote:
>>
>>         Hi Helge,
>>
>>         sure, but if I normalize to get the expected evt number, for
>>         a Higgs signal
>>
>>         the number is very low, and we will have overtraining. Am I
>>         wrong?
>>
>>         So I wonder how to normalize the sample btw them and avoid
>>         low number (in signal sample) issue?
>>
>>         Regards
>>
>>         On 10/11/16 5:03 PM, Helge Voss wrote:
>>>         Hi Betty,
>>>
>>>         well, obviously simply scaling by the cross section is
>>>         'meaningless' if you don't take into account the
>>>         number of events generated. Just think .. in another world,
>>>         maybe the guy/girl responsible for the MC
>>>         generation simply generated 2x more of one particular
>>>         bkg-source just because he/she regarded it as more
>>>         interesting ... if you simply scale by 'cross section' you'd
>>>         get a different event sample distribution w/o changing
>>>         any physics..
>>>
>>>         So you'd probably want to scale them such that the generated
>>>         integrated luminosity for all bkg sources is the same.
>>>         Assuming you don't
>>>         have any 'preselection cuts' in the MC generation (which is
>>>         probably a wrong assumption), then scaling each bkg
>>>         by weighting all bkg sources i, bkg(i) by  int_lum(i) is
>>>         then proportional to  #events(i)/crosssection(i), so in that
>>>         case you'd have to
>>>         get a multiplicative event weight of
>>>         weight(i)=1/int_lumi(i)=crosssection(i)/#events-generated(i)  ..
>>>
>>>         that would make the distriution of the sum of the bkg events
>>>         in your simulation look like that one expected in the data,
>>>         which
>>>         is probably a good way to go as default for any mva training
>>>         (not, it's not a 'must' .. you can also somehow weigh the
>>>         various
>>>         types different, get a slightly different classifier... ,
>>>         you'd just have to watch out how to calculate backgr.
>>>         rejection then ..)
>>>
>>>         Cheers,
>>>
>>>         Helge
>>>
>>>
>>>         On 11 October 2016 at 14:27, Betty Calpas
>>>         <bet...@ce... <mailto:bet...@ce...>> wrote:
>>>
>>>             Dear,
>>>
>>>             any idea?
>>>
>>>             Regards
>>>
>>>
>>>
>>>             -------- Forwarded Message --------
>>>             Subject: 	Event normalization in tmva training
>>>             Date: 	Tue, 11 Oct 2016 11:30:36 +0200
>>>             From: 	Betty Calpas <bet...@ce...>
>>>             <mailto:bet...@ce...>
>>>             To: 	tmv...@li...
>>>             <mailto:tmv...@li...>
>>>             <tmv...@li...>
>>>             <mailto:tmv...@li...>
>>>
>>>
>>>
>>>             Dear experts,
>>>
>>>             to normalize my bkg btw them, I multiplyed each event by
>>>
>>>             their cross section. But the bkg samples have different
>>>
>>>             initial number of event, so I wonder if applying the cross
>>>
>>>             section as a weight is enough? Should I take into account
>>>
>>>             the initial number of event?
>>>
>>>             Regards
>>>
>>>
>>>             ------------------------------------------------------------------------------
>>>             Check out the vibrant tech community on one of the
>>>             world's most
>>>             engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>             _______________________________________________
>>>             TMVA-users mailing list
>>>             TMV...@li...
>>>             <mailto:TMV...@li...>
>>>             https://lists.sourceforge.net/lists/listinfo/tmva-users
>>>             <https://lists.sourceforge.net/lists/listinfo/tmva-users>
>>>
>>>
>>
>>
>>         -- 
>>
>>         Cheers,
>>         Betty
>>
>>
>
>
>     -- 
>
>     Cheers,
>     Betty
>
>


-- 

Cheers,
Betty

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Helge V. <Hel...@ce...>]

Exactly !

And if you do this 'by hand' (i.e. setting the accoring 'tree weights')
just make sure that you don't have a 'NormMode=NumEvents' but
'NormMode=None' ) in the
factory->PrepareTrainingAndTestTree(..) call ..

(the option: NormMode=NumEvents  would otherwise overwrite your relative
weighting between the total of your background and the total of your
signal, by scaling them again such that the total (scaled) number of
background events is the same a s teh total (scaled) number of signal
events.)

Of course, you could also 'forget' completely about the relative weighting
between signal and background and simply use "NormMode=NumEvents" :)
(you only need to make sure you have the relative weighting of the
different background sources worked out correctly ... which is why my first
email only treated that part ...)

Helge



On 12 October 2016 at 10:03, Betty Calpas <bet...@ce...> wrote:

> Hi Helge,
>
> so you mean that I can scale the bkg and the signal in to different way?
>
> - for the bkg1, bkg2 ... I can apply for each evt the weight w1, w2 ...
>
> with the same luminosity:
>
> w1 = cs1 * lumi / ngenerated_evt_1
>
> w2 = cs2 * lumi / ngenerated_evt_2
>
> ...
>
> - and for the signal I can use (any luminosity):
>
> ws = css * lumi*100 / ngenerated_evt_s
>
> Regards
>
>
>
> On 10/11/16 7:00 PM, Helge Voss wrote:
>
> Hi,
>
> what I said was for 'normalizing' the various background sources relative
> to each other.
> For the normalization of the signal vs your collective backgrounds, you're
> right, it is
> typically better to have them both normalized to the same number of
> events..
>
> You want to discriminate events distributed like your signal events  from
> events that
> are distributed according the sum of all your background events.
>
> You want to make sure that the 'sum of background events' are distributed
> like in the
> data (i.e. all different sources weighted to the same integrated
> luminosity generated),
>
> Scaling the signal doesn't change the distribution .. so you can happily
> scale the signal
> to a different integrated luminosity .. and you should (e.g. to the same
> number of events)
>
> it's not that you would 'overtrain' otherwise .. but if your signal is
> very small compared to the background,
> the classifier would otherwise simply have to classify everything as
> 'background' and already
> perform very good... the classifier simply wouldn't get an 'incentive' to
> actually identify your
> signal.
>
> Cheers,
>
> Helge
>
>
> On 11 October 2016 at 17:11, Betty Calpas <bet...@ce...> wrote:
>
>> Hi Helge,
>>
>> sure, but if I normalize to get the expected evt number, for a Higgs
>> signal
>>
>> the number is very low, and we will have overtraining. Am I wrong?
>>
>> So I wonder how to normalize the sample btw them and avoid low number (in
>> signal sample) issue?
>>
>> Regards
>>
>> On 10/11/16 5:03 PM, Helge Voss wrote:
>>
>> Hi Betty,
>>
>> well, obviously simply scaling by the cross section is 'meaningless' if
>> you don't take into account the
>> number of events generated. Just think .. in another world, maybe the
>> guy/girl responsible for the MC
>> generation simply generated 2x more of one particular bkg-source just
>> because he/she regarded it as more
>> interesting ... if you simply scale by 'cross section' you'd get a
>> different event sample distribution w/o changing
>> any physics..
>>
>> So you'd probably want to scale them such that the generated integrated
>> luminosity for all bkg sources is the same. Assuming you don't
>> have any 'preselection cuts' in the MC generation (which is probably a
>> wrong assumption), then scaling each bkg
>> by weighting all bkg sources i, bkg(i) by  int_lum(i) is then
>> proportional to  #events(i)/crosssection(i), so in that case you'd have to
>> get a multiplicative event weight of weight(i)=1/int_lumi(i)=crosssection(i)/#events-generated(i)
>>  ..
>>
>> that would make the distriution of the sum of the bkg events in your
>> simulation look like that one expected in the data, which
>> is probably a good way to go as default for any mva training (not, it's
>> not a 'must' .. you can also somehow weigh the various
>> types different, get a slightly different classifier... , you'd just have
>> to watch out how to calculate backgr. rejection then ..)
>>
>> Cheers,
>>
>> Helge
>>
>>
>> On 11 October 2016 at 14:27, Betty Calpas <bet...@ce...> wrote:
>>
>>> Dear,
>>>
>>> any idea?
>>>
>>> Regards
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: Event normalization in tmva training
>>> Date: Tue, 11 Oct 2016 11:30:36 +0200
>>> From: Betty Calpas <bet...@ce...> <bet...@ce...>
>>> To: tmv...@li... <tmv...@li...>
>>> <tmv...@li...>
>>>
>>> Dear experts,
>>>
>>> to normalize my bkg btw them, I multiplyed each event by
>>>
>>> their cross section. But the bkg samples have different
>>>
>>> initial number of event, so I wonder if applying the cross
>>>
>>> section as a weight is enough? Should I take into account
>>>
>>> the initial number of event?
>>>
>>> Regards
>>>
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TMVA-users mailing list
>>> TMV...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>>
>>>
>>
>>
>> --
>>
>> Cheers,
>> Betty
>>
>
>
>
> --
>
> Cheers,
> Betty
>

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Betty C. <bet...@ce...>]

Hi Helge,

so you mean that I can scale the bkg and the signal in to different way?

- for the bkg1, bkg2 ... I can apply for each evt the weight w1, w2 ...

with the same luminosity:

w1 = cs1 * lumi / ngenerated_evt_1

w2 = cs2 * lumi / ngenerated_evt_2

...

- and for the signal I can use (any luminosity):

ws = css * lumi*100 / ngenerated_evt_s

Regards


On 10/11/16 7:00 PM, Helge Voss wrote:
> Hi,
>
> what I said was for 'normalizing' the various background sources 
> relative to each other.
> For the normalization of the signal vs your collective backgrounds, 
> you're right, it is
> typically better to have them both normalized to the same number of 
> events..
>
> You want to discriminate events distributed like your signal events 
>  from events that
> are distributed according the sum of all your background events.
>
> You want to make sure that the 'sum of background events' are 
> distributed like in the
> data (i.e. all different sources weighted to the same integrated 
> luminosity generated),
>
> Scaling the signal doesn't change the distribution .. so you can 
> happily scale the signal
> to a different integrated luminosity .. and you should (e.g. to the 
> same number of events)
>
> it's not that you would 'overtrain' otherwise .. but if your signal is 
> very small compared to the background,
> the classifier would otherwise simply have to classify everything as 
> 'background' and already
> perform very good... the classifier simply wouldn't get an 'incentive' 
> to actually identify your
> signal.
>
> Cheers,
>
> Helge
>
> On 11 October 2016 at 17:11, Betty Calpas <bet...@ce... 
> <mailto:bet...@ce...>> wrote:
>
>     Hi Helge,
>
>     sure, but if I normalize to get the expected evt number, for a
>     Higgs signal
>
>     the number is very low, and we will have overtraining. Am I wrong?
>
>     So I wonder how to normalize the sample btw them and avoid low
>     number (in signal sample) issue?
>
>     Regards
>
>     On 10/11/16 5:03 PM, Helge Voss wrote:
>>     Hi Betty,
>>
>>     well, obviously simply scaling by the cross section is
>>     'meaningless' if you don't take into account the
>>     number of events generated. Just think .. in another world, maybe
>>     the guy/girl responsible for the MC
>>     generation simply generated 2x more of one particular bkg-source
>>     just because he/she regarded it as more
>>     interesting ... if you simply scale by 'cross section' you'd get
>>     a different event sample distribution w/o changing
>>     any physics..
>>
>>     So you'd probably want to scale them such that the generated
>>     integrated luminosity for all bkg sources is the same. Assuming
>>     you don't
>>     have any 'preselection cuts' in the MC generation (which is
>>     probably a wrong assumption), then scaling each bkg
>>     by weighting all bkg sources i, bkg(i) by  int_lum(i) is then
>>     proportional to  #events(i)/crosssection(i), so in that case
>>     you'd have to
>>     get a multiplicative event weight of
>>     weight(i)=1/int_lumi(i)=crosssection(i)/#events-generated(i)  ..
>>
>>     that would make the distriution of the sum of the bkg events in
>>     your simulation look like that one expected in the data, which
>>     is probably a good way to go as default for any mva training
>>     (not, it's not a 'must' .. you can also somehow weigh the various
>>     types different, get a slightly different classifier... , you'd
>>     just have to watch out how to calculate backgr. rejection then ..)
>>
>>     Cheers,
>>
>>     Helge
>>
>>
>>     On 11 October 2016 at 14:27, Betty Calpas <bet...@ce...
>>     <mailto:bet...@ce...>> wrote:
>>
>>         Dear,
>>
>>         any idea?
>>
>>         Regards
>>
>>
>>
>>         -------- Forwarded Message --------
>>         Subject: 	Event normalization in tmva training
>>         Date: 	Tue, 11 Oct 2016 11:30:36 +0200
>>         From: 	Betty Calpas <bet...@ce...>
>>         <mailto:bet...@ce...>
>>         To: 	tmv...@li...
>>         <mailto:tmv...@li...>
>>         <tmv...@li...>
>>         <mailto:tmv...@li...>
>>
>>
>>
>>         Dear experts,
>>
>>         to normalize my bkg btw them, I multiplyed each event by
>>
>>         their cross section. But the bkg samples have different
>>
>>         initial number of event, so I wonder if applying the cross
>>
>>         section as a weight is enough? Should I take into account
>>
>>         the initial number of event?
>>
>>         Regards
>>
>>
>>         ------------------------------------------------------------------------------
>>         Check out the vibrant tech community on one of the world's most
>>         engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>         _______________________________________________
>>         TMVA-users mailing list
>>         TMV...@li...
>>         <mailto:TMV...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/tmva-users
>>         <https://lists.sourceforge.net/lists/listinfo/tmva-users>
>>
>>
>
>
>     -- 
>
>     Cheers,
>     Betty
>
>


-- 

Cheers,
Betty

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Helge V. <Hel...@ce...>]

Hi,

what I said was for 'normalizing' the various background sources relative
to each other.
For the normalization of the signal vs your collective backgrounds, you're
right, it is
typically better to have them both normalized to the same number of events..

You want to discriminate events distributed like your signal events  from
events that
are distributed according the sum of all your background events.

You want to make sure that the 'sum of background events' are distributed
like in the
data (i.e. all different sources weighted to the same integrated luminosity
generated),

Scaling the signal doesn't change the distribution .. so you can happily
scale the signal
to a different integrated luminosity .. and you should (e.g. to the same
number of events)

it's not that you would 'overtrain' otherwise .. but if your signal is very
small compared to the background,
the classifier would otherwise simply have to classify everything as
'background' and already
perform very good... the classifier simply wouldn't get an 'incentive' to
actually identify your
signal.

Cheers,

Helge


On 11 October 2016 at 17:11, Betty Calpas <bet...@ce...> wrote:

> Hi Helge,
>
> sure, but if I normalize to get the expected evt number, for a Higgs signal
>
> the number is very low, and we will have overtraining. Am I wrong?
>
> So I wonder how to normalize the sample btw them and avoid low number (in
> signal sample) issue?
>
> Regards
>
> On 10/11/16 5:03 PM, Helge Voss wrote:
>
> Hi Betty,
>
> well, obviously simply scaling by the cross section is 'meaningless' if
> you don't take into account the
> number of events generated. Just think .. in another world, maybe the
> guy/girl responsible for the MC
> generation simply generated 2x more of one particular bkg-source just
> because he/she regarded it as more
> interesting ... if you simply scale by 'cross section' you'd get a
> different event sample distribution w/o changing
> any physics..
>
> So you'd probably want to scale them such that the generated integrated
> luminosity for all bkg sources is the same. Assuming you don't
> have any 'preselection cuts' in the MC generation (which is probably a
> wrong assumption), then scaling each bkg
> by weighting all bkg sources i, bkg(i) by  int_lum(i) is then proportional
> to  #events(i)/crosssection(i), so in that case you'd have to
> get a multiplicative event weight of weight(i)=1/int_lumi(i)=
> crosssection(i)/#events-generated(i)  ..
>
> that would make the distriution of the sum of the bkg events in your
> simulation look like that one expected in the data, which
> is probably a good way to go as default for any mva training (not, it's
> not a 'must' .. you can also somehow weigh the various
> types different, get a slightly different classifier... , you'd just have
> to watch out how to calculate backgr. rejection then ..)
>
> Cheers,
>
> Helge
>
>
> On 11 October 2016 at 14:27, Betty Calpas <bet...@ce...> wrote:
>
>> Dear,
>>
>> any idea?
>>
>> Regards
>>
>>
>> -------- Forwarded Message --------
>> Subject: Event normalization in tmva training
>> Date: Tue, 11 Oct 2016 11:30:36 +0200
>> From: Betty Calpas <bet...@ce...> <bet...@ce...>
>> To: tmv...@li... <tmv...@li...>
>> <tmv...@li...>
>>
>> Dear experts,
>>
>> to normalize my bkg btw them, I multiplyed each event by
>>
>> their cross section. But the bkg samples have different
>>
>> initial number of event, so I wonder if applying the cross
>>
>> section as a weight is enough? Should I take into account
>>
>> the initial number of event?
>>
>> Regards
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TMVA-users mailing list
>> TMV...@li...
>> https://lists.sourceforge.net/lists/listinfo/tmva-users
>>
>>
>
>
> --
>
> Cheers,
> Betty
>

Re: [TMVA-users] Fwd: Event normalization in tmva training

[Betty C. <bet...@ce...>]

Hi Helge,

sure, but if I normalize to get the expected evt number, for a Higgs signal

the number is very low, and we will have overtraining. Am I wrong?

So I wonder how to normalize the sample btw them and avoid low number 
(in signal sample) issue?

Regards

On 10/11/16 5:03 PM, Helge Voss wrote:
> Hi Betty,
>
> well, obviously simply scaling by the cross section is 'meaningless' 
> if you don't take into account the
> number of events generated. Just think .. in another world, maybe the 
> guy/girl responsible for the MC
> generation simply generated 2x more of one particular bkg-source just 
> because he/she regarded it as more
> interesting ... if you simply scale by 'cross section' you'd get a 
> different event sample distribution w/o changing
> any physics..
>
> So you'd probably want to scale them such that the generated 
> integrated luminosity for all bkg sources is the same. Assuming you don't
> have any 'preselection cuts' in the MC generation (which is probably a 
> wrong assumption), then scaling each bkg
> by weighting all bkg sources i, bkg(i) by  int_lum(i) is then 
> proportional to  #events(i)/crosssection(i), so in that case you'd have to
> get a multiplicative event weight of 
> weight(i)=1/int_lumi(i)=crosssection(i)/#events-generated(i)  ..
>
> that would make the distriution of the sum of the bkg events in your 
> simulation look like that one expected in the data, which
> is probably a good way to go as default for any mva training (not, 
> it's not a 'must' .. you can also somehow weigh the various
> types different, get a slightly different classifier... , you'd just 
> have to watch out how to calculate backgr. rejection then ..)
>
> Cheers,
>
> Helge
>
>
> On 11 October 2016 at 14:27, Betty Calpas <bet...@ce... 
> <mailto:bet...@ce...>> wrote:
>
>     Dear,
>
>     any idea?
>
>     Regards
>
>
>
>     -------- Forwarded Message --------
>     Subject: 	Event normalization in tmva training
>     Date: 	Tue, 11 Oct 2016 11:30:36 +0200
>     From: 	Betty Calpas <bet...@ce...>
>     <mailto:bet...@ce...>
>     To: 	tmv...@li...
>     <mailto:tmv...@li...>
>     <tmv...@li...>
>     <mailto:tmv...@li...>
>
>
>
>     Dear experts,
>
>     to normalize my bkg btw them, I multiplyed each event by
>
>     their cross section. But the bkg samples have different
>
>     initial number of event, so I wonder if applying the cross
>
>     section as a weight is enough? Should I take into account
>
>     the initial number of event?
>
>     Regards
>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>     _______________________________________________
>     TMVA-users mailing list
>     TMV...@li...
>     <mailto:TMV...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tmva-users
>     <https://lists.sourceforge.net/lists/listinfo/tmva-users>
>
>


-- 

Cheers,
Betty