Re: Bug or feature?

From: Philippe Canal <pcanal_at_fnal.gov>
Date: Wed, 28 Jan 2009 17:55:09 -0600


Hi Art,

The TF1 are different because they held in memory in a single global list (to allow for a simpler fitting interface). For this reason any subsequent access will first find the TF1 in the global list (gROOT->GetListOfFunctions()) before looking in the current directory. By definition, they should only be one TF1 the same name and hence
we should not automatically replace the previous one (in addition since TF1 are not connected/attached to
a TFile, we have no way to know how the TF1 came to being (at the time of the lookup of the 2nd one)).

To get the type of functionality, you can write a same wrapper function:

TF1 GetTF1(const char *name) {

     TF1 *func; gDirectory->GetObject(name,func);
     return func;

}

and use as:

A=new TFile("Res_funsT.root");

GetTF1("sigmaPar")->Print();
B=new TFile("testTF1.root");
GetTF1("sigmaPar")->Print();

but then again, it is probably better to use it as:

TF1 *func;
A=new TFile("Res_funsT.root");
A->GetObject("sigmaPar",func);
func->Print();
B=new TFile("testTF1.root");
B->GetObject("sigmaPar",func);
func->Print();

Cheers,
Philippe.

Arthur E. Snyder wrote:
>
> Hello RootWorld:
>
> I'm having an odd problem saving TF1's in files. I have two versions
> of the same function with the same name. I save them in two different
> files, call them A and B. The functions differ only in the values
> assigned the parameters.
>
> If I open file A, look at it (Draw or Print), then file B, I get the
> function with the A-parameters. If I open in the other order I get the
> B-paramters. If I cd to one of them, I still get function with the
> parameters of the file 1st openned.
>
> This is completely unlike the behavoir of n-tuples or histograms where
> if I open multiple files I get the one I'm currently cd into. I use
> this all the time to track, e.g., what histogram I want to fit at a
> given time.
>
> But TF1's don't behave the same way even though they all inherit from
> TObject and should I think behave the same way.
>
> Is this a bug or a feature? Is this a well known problem?
>
> I can certainly kuldge my way around it -- by assign some differing
> names that I'll have to keep track of, but it does add another layer
> of possibley buggy bookkeeping that I thought root was doing for me.
>
> -Art S
>
> Example:
>
> A as parameter 1 = 0.0171368; B has par1=0.0205642
>
> root [0] A=new TFile("Res_funsT.root")
> (class TFile*)0x8db4540
> root [1] .ls
> TFile** Res_funsT.root
> TFile* Res_funsT.root
> KEY: TF1 sigmaPar;1 pol4
> KEY: TF1 apar;1 pol0
> KEY: TF1 npar;1 pol0
> KEY: TF1 mupar;1 pol3
> KEY: TF1 power;1
> [0]*([3]*TMath::Gaus(x,[1],[2],1)+(1.0-[3])*TMath::Gaus(x,[4],[5],1))
> KEY: TF1 pnorm;1 [0]*(1-TMath::Exp(-[1]*x))*(1-TMath::Exp(-[1]*x))
> root [2] sigmaPar->Print()
> sigmaPar : pol4 Ndim= 1, Npar= 5, Noper= 1
> fExpr[0] = pol4 action = 130 action param = 401
> Optimized expression
> fExpr[0] = pol4 action = 130 action param = 401
> Par 0 #alpha_{0} = 0.00493591
> Par 1 #alpha_{1} = 0.0171368
> Par 2 #alpha_{2} = -0.00493408
> Par 3 #alpha_{3} = 0.00143038
> Par 4 #alpha_{4} = -0.000135192
> root [3] B=new TFile("testTF1.root")
> (class TFile*)0x8df5f58
> root [4] B->cd()
> (Bool_t)1
> root [5] sigmaPar->Print()
> sigmaPar : pol4 Ndim= 1, Npar= 5, Noper= 1
> fExpr[0] = pol4 action = 130 action param = 401
> Optimized expression
> fExpr[0] = pol4 action = 130 action param = 401
> Par 0 #alpha_{0} = 0.00493591
> Par 1 #alpha_{1} = 0.0171368
> Par 2 #alpha_{2} = -0.00493408
> Par 3 #alpha_{3} = 0.00143038
> Par 4 #alpha_{4} = -0.000135192
>
> --actually it seems to be more a question of which version of function
> I look at 1st; if open A, don't look at it, then open B, I'll get B
> values, but A->cd() will not get me the A values.
>
>
>
> 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
>
>
>
> On Wed, 4 Apr 2007, Philippe Canal wrote:
>
>> Hi Arthur,
>>
>> I can not reproduce the problem (or do not understand your
>> description :) ).
>>
>> Can you send me a complete running example (and the output as you see
>> it)
>> as well as the version of ROOT where it fails for you).
>>
>> Cheers,
>> Philippe.
>>
>> -----Original Message-----
>> From: owner-roottalk_at_pcroot.cern.ch
>> [mailto:owner-roottalk_at_pcroot.cern.ch]
>> On Behalf Of Arthur E. Snyder
>> Sent: Monday, April 02, 2007 4:43 PM
>> To: Rene Brun
>> Cc: 'roottalk (Mailing list discussing all aspects of the ROOT system)'
>> Subject: [ROOT] TString bug (or feature)?
>>
>> Hi Rene et al.,
>>
>> I find that when I try to read the blank separated charachters in a line
>> into TString from an istringstream it has a strange behavior. If the
>> last
>> character is followed directly by a line-feed it gets skipped.
>> Apparently
>> eof or something is set by reading it and the loop ends w.o. giving
>> you a
>> chance at the characters just read. The result is you lose the last
>> character string. If I use std::string instead, it works as I expect it
>> too.
>>
>> The code is as follows:
>>
>> #include "readCard.hh"
>> #include <TString.h>
>> #include <iostream>
>> #include <vector>
>> #include <string>
>>
>> using std::istream;
>> using std::endl;
>> using std::cout;
>>
>> //read strings till "eol" marker or natural end; if nread!=0 read nread
>> string (no marker)
>> Int_t readCard(istream& card,std::vector<TString>& list,Int_t nread) {
>> Int_t count=0;
>>
>> TString temp;
>> // std::string temp;
>> while(card >> temp) {
>>
>> cout << "count:" << count << " temp:" << temp << endl;
>>
>> if(nread==0 && temp=="eol") break;
>> if(nread==0 && temp=="*eol") break;
>> if(nread==0 && temp=="!eol") break;
>> count++;
>>
>> list.push_back(temp);
>> if(count==nread) break;
>>
>> } // loop
>>
>> return count;
>> }
>>
>> -Art S.
>>
>>
>>
>
Received on Thu Jan 29 2009 - 00:55:15 CET

This archive was generated by hypermail 2.2.0 : Thu Jan 29 2009 - 17:50:01 CET