[ROOT] Treatment of uncertainties from the TFractionFitter

Hello,
     I am using TFractionFitter to fit the data distribution with the 
templates from Monte Carlo simulation to extract their respective 
fractions.  The Fitter gives us the fractions with the errors. The 
problem is how to disentangle the  error into statistics and systematics 
parts. The error must have some part as statistical, but, clearly it has 
systematics too since it varies the shape of the templates while 
fitting. Can you please help me with this?

Thanks.
Ashish

Re: [ROOT] Treatment of uncertainties from the TFractionFitter

Hi Ashish,

|TFraction| fitter will only give you statistical error. If, e.g., your MC 
is less than perfect model for the shapes in data that error will 
not/cannot be included by fitter. If you look at some goodness-of-fit 
(like chisq) systematics from wrong shapes may show up as a bad fit.

To get systematic error you need to do something external to fit. E.g., 
vary the shapes and see how much results change. |TFractionFitter| does
provide a way to apply weights to each histogram your fitting to so 
you can vary there shapes.

If your shape variations make goodness-of-fit get too bad, you can 
plausible argue that that variation was too big and use something smaller.

Beyond that there's nothing much in the way of a systematics way to 
estimate systematic uncertainties; the variations people use tend to be 
pretty arbitary ...

-Art S.

A.E. Snyder, Group EC                        \!c*p?/
SLAC Mail Stop #95                          ((.   .))
Box 4349                                        |
Stanford, Ca, USA, 94309                      '\|/`
e-mail:snyder <at> slac.stanford.edu                 o
phone:650-926-2701                              _
http://www.slac.stanford.edu/~snyder          BaBar
FAX:650-926-2657                          Collaboration

[ROOT] change to include path handling broke ACLiC

Re: [ROOT] change to include path handling broke ACLiC

[ROOT] More problems with CINT

Hello (again), as if I had made no progress I'm back at that very simple 
file parser that made me contact this mailing list for the first time 
but which I eventually dropped for other reasons. Again, ISO compliant 
code (I know, in terms of CINT that holds no relevance at all) and again 
an error which I dont understand, attached code, error message:

Error: Can't call deque<double,allocator<double> >::deque<double >() in 
current scope auswertung.cpp:9:
Possible candidates are...
(in deque<double,allocator<double> >)
*** Interpreter error recovered ***

Re: [ROOT] More problems with CINT

Hello Cedric,

Seems to work if you do this instead

  std::deque< double > * result;
  result = new std::deque< double >;

I can't explain why.  Can you try see if it works for you ?

John

On Thu, 2010-04-01 at 23:36 +0200, Cedric Sodhi wrote:
> Hello (again), as if I had made no progress I'm back at that very simple 
> file parser that made me contact this mailing list for the first time 
> but which I eventually dropped for other reasons. Again, ISO compliant 
> code (I know, in terms of CINT that holds no relevance at all) and again 
> an error which I dont understand, attached code, error message:
> 
> Error: Can't call deque<double,allocator<double> >::deque<double >() in 
> current scope auswertung.cpp:9:
> Possible candidates are...
> (in deque<double,allocator<double> >)
> *** Interpreter error recovered ***

Re: [ROOT] More problems with CINT

Re: [ROOT] More problems with CINT

Ah, really, come on. I never approach CINT with any preconceptions but 
it's very frustrating - very often. Just as for this very code: After I 
sent the email I tried for 45minutes now to make CINT swallow it. No 
results! I tried every possible trick, dumbed it down to the purest and 
simplest things I could think of, all fully ISO compliant with 
decreasing complexity. That's what I ended up with (I cannot verify the 
code in gcc anymore as I tried to make CINT like it). Took out deque. 
Made the vector a string. Took out algorith. Iostream even. A 5 year old 
could interpret that. CINT however: Segfault!

I'll try what John suggested and I'm confident that if it worked for him 
it will for me. But I can compare the "CINT-experience" only to the 
frustration a web-developer encountered when trying to make webpages for 
the Internet Explorer still a few years ago. I'm really hoping this 
awful thing gets a replacement soon because it spoils the actually great 
   program ROOT.

Robert Hatcher wrote:
> 
> On Apr 1, 2010, at 4:36 PM, Cedric Sodhi wrote:
> 
>> Hello (again), as if I had made no progress I'm back at that very 
>> simple file parser that made me contact this mailing list for the 
>> first time but which I eventually dropped for other reasons. Again, 
>> ISO compliant code (I know, in terms of CINT that holds no relevance 
>> at all) 
> 
> Ah, not really fair.  Yes, CINT plays fast-and-loose a bit.  But in
> general actual standard C++ *will* run.  I'm not sure CINT is
> necessarily exactly ISO compliant in this case, but I have a simple fix...
> 
>> and again an error which I dont understand, attached code, error message:
>>
>> Error: Can't call deque<double,allocator<double> >::deque<double >() 
>> in current scope auswertung.cpp:9:
>> Possible candidates are...
>> (in deque<double,allocator<double> >)
> 
> Read this error message.  Count to 9.
> 
>> *** Interpreter error recovered ***
>> #include <vector>
>> #include <deque>
>> #include <iostream>
>> #include <fstream>
>> #include <sstream>
>> #include <algorithm>
>>
>> std::deque< double >* readCassy( const char *filePath,const 
>> std::vector< char > &columns ) {
>> std::deque< double > *result = new std::deque< double >;
> 
> There is the offending line.  Try:
> 
> std::deque< double > * result = new std::deque< double >();
> 
>  From a simple root session:
> 
> root [0] #include <deque>
> root [1] std::deque< double > * result = new std::deque< double >;
> Error: Can't call deque<double,allocator<double> >::deque<double >() in 
> current scope (tmpfile):1:
> Possible candidates are...
> (in deque<double,allocator<double> >)
> *** Interpreter error recovered ***
> root [2] std::deque< double > * result = new std::deque< double >();
> 
> Hmmm, looks like a CINT issue since both, I believe, should be valid.
> If you compiled your macro w/ ACLiC you could test whether the
> compiler thinks your code is on the up-and-up.  I.e.
> 
>  $ root -b -q auswertung.C++
> 
> and run with that to avoid any CINT, ah, peculiarities...
> 
>> std::ifstream inFile( filePath );
>> if( inFile.bad( ) )
>> std::cout << "readCassy: Could not open file '" << filePath << "'" << 
>> std::endl;
>> std::string lastLine = "";
>> std::string lastField = "";
>> double fieldValue = 0.0;
>> while( lastLine.find( "\t" )== std::string::npos )
>> std::getline( inFile,lastLine );
>> while( lastLine.find( "\t" )!= std::string::npos ) {
>> std::istringstream lineData( lastLine );
>> for( char field = 0; std::getline( lineData,lastField,'\t' ); field++ )
>> if( find( columns.begin( ),columns.end( ),field )!= columns.end( ) ) {
>> std::istringstream fieldData( lastField );
>> fieldData >> fieldValue;
>> std::cout << fieldValue << " ";
>> result->push_back( fieldValue );
>> }
>> std::cout << std::endl;
>> std::getline( inFile,lastLine );
>> }
>> return result;
>> }
>>
>> void auswertung( ) {
>> std::vector< char > cols;
>> cols.push_back( 1 );
>> cols.push_back( 2 );
>> std::deque< double >* data = readCassy( 
>> "/home/manday/Documents/University/Physik 
>> Praktikum/Akustik/cassy/sync2.lab",cols );
>> }
> 
> Robert W. Hatcher   | rhatcher <at> fnal.gov 
> <mailto:rhatcher <at> fnal.gov>   630-840-3102
> FNAL CD/REX (MINOS) | MS 220, PO Box 500, Batavia IL 60510
> 
> 
> 
> 

Re: [ROOT] More problems with CINT

Hey John, ok I tried that and no errors, puh! But now there is a even 
stranger problem:

It's AW-FULLY slow. You wouldn't believe how slow that is, did you try 
it? If run as a binary it runs at just fair speed but in root every 
getline appears to take a whole second! I'm now going to bed so I will 
not reply for a while, thanks for your help - i would certainly be 
screwed without you guys 

John Idarraga wrote:
> Hello Cedric,
> 
> Seems to work if you do this instead
> 
>   std::deque< double > * result;
>   result = new std::deque< double >;
> 
> I can't explain why.  Can you try see if it works for you ?
> 
> John
> 
> On Thu, 2010-04-01 at 23:36 +0200, Cedric Sodhi wrote:
>> Hello (again), as if I had made no progress I'm back at that very simple 
>> file parser that made me contact this mailing list for the first time 
>> but which I eventually dropped for other reasons. Again, ISO compliant 
>> code (I know, in terms of CINT that holds no relevance at all) and again 
>> an error which I dont understand, attached code, error message:
>>
>> Error: Can't call deque<double,allocator<double> >::deque<double >() in 
>> current scope auswertung.cpp:9:
>> Possible candidates are...
>> (in deque<double,allocator<double> >)
>> *** Interpreter error recovered ***
> 

Re: [ROOT] More problems with CINT

Just a remark on your question and in particular the style of your question:
We have never pretended that CINT is an ISO compliant C++ interpreter. 
CINT is fulfilling its role as interpreter
for the vast majority of tasks that it is supposed to do.
All CINT users know that we have a trivial, simple, C++ compatible 
option for CINT scripts by using
the ACLIC interface to the native compiler. To use it (as explained in 
the very first pages of the ROOT Users Guide) do
   root > .x myscript.C+
instead of
   root > .x myscript.C

It is our hope that in the not too distant future, we can upgrade ROOT 
to use the LLVM compiler and its Just In Time features
as a better solution. ACLIC has been found simple to use, you do not 
have to rewrite your scripts into another language,
you can compile your scripts directly with a native compiler providing 
that your script is written in valid C++. The transition
to LLVM should be transparent to our users.

Rene Brun

Cedric Sodhi wrote:
> Hey John, ok I tried that and no errors, puh! But now there is a even 
> stranger problem:
>
> It's AW-FULLY slow. You wouldn't believe how slow that is, did you try 
> it? If run as a binary it runs at just fair speed but in root every 
> getline appears to take a whole second! I'm now going to bed so I will 
> not reply for a while, thanks for your help - i would certainly be 
> screwed without you guys 
>
>
> John Idarraga wrote:
>> Hello Cedric,
>>
>> Seems to work if you do this instead
>>
>>   std::deque< double > * result;
>>   result = new std::deque< double >;
>>
>> I can't explain why.  Can you try see if it works for you ?
>>
>> John
>>
>> On Thu, 2010-04-01 at 23:36 +0200, Cedric Sodhi wrote:
>>> Hello (again), as if I had made no progress I'm back at that very 
>>> simple file parser that made me contact this mailing list for the 
>>> first time but which I eventually dropped for other reasons. Again, 
>>> ISO compliant code (I know, in terms of CINT that holds no relevance 
>>> at all) and again an error which I dont understand, attached code, 
>>> error message:
>>>
>>> Error: Can't call deque<double,allocator<double> >::deque<double >() 
>>> in current scope auswertung.cpp:9:
>>> Possible candidates are...
>>> (in deque<double,allocator<double> >)
>>> *** Interpreter error recovered ***
>>
>