Re: Re: Bug or feature?

From: Arthur E. Snyder <snyder_at_slac.stanford.edu>
Date: Wed, 28 Jan 2009 15:08:44 -0800


Ok I guess GetObject would be better .. it presumable works regardless of object's type

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, 28 Jan 2009, Philippe Canal wrote:

>
>> which is ok I guess, but I don't need to do that for histograms and the
> need for casting is a bad interface.
>
> GetObjectUnchecked is a low level interface, don't use it directly :) (...
> well unless you need to the 'Unchecked' behavior).
>
> Instead use:
>
> TF1 *sigmaPar; A->GetObject("sigmaPar",sigmaPar);
>
> sigmaPar will be zero if the object does not exist or is of the wrong type.
>
> Cheers,
> Philippe.
>
> Arthur E. Snyder wrote:
>> I find I can recover my funtcions by being very explicit:
>>
>> root [16] ((TF1*)A->GetObjectUnchecked("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 [17] ((TF1*)B->GetObjectUnchecked("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.0205642
>> Par 2 #alpha_{2} = -0.00493408
>> Par 3 #alpha_{3} = 0.00143038
>> Par 4 #alpha_{4} = -0.000135192
>>
>> which is ok I guess, but I don't need to do that for histograms and the
>> need for casting is a bad interface.
>>
>> -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
>>
>>
>>
>> On Wed, 28 Jan 2009, 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:08:53 CET

This archive was generated by hypermail 2.2.0 : Thu Jan 29 2009 - 05:50:02 CET