Hi Sue,
Thanks you for reporting these problems. I solved most of them
and this will be uploaded soon in the CVS repository. The
problem I was able to fix were related to the fact that you have
a (conceptual) array with 2 varying dimensions that the 2nd dimensions
is sometimes 0 (aka fNShower==0) and a fixed index is used.
However there is an issue for which I can not find an elegant
solution. The issue is at the level of the 'syntax' of the formula.
When you write
tree->Scan("fShowers[fEvents[].fShwInd[0]].fEnergy","fEvents[].fNShower > 0");
The result to be expected is (albeit annoyingly in __this__ case, see further
down for a justification on why it is the way it is).
***********************************
* Row * Instance * fShowers[ *
***********************************
* 0 * 0 * 10 *
***********************************
The reason for that is that the 'iterators' for an array used as an index
for another array (fEvents[].fShwInd[0] in your example) are independent
of the outer iterators. In essence the above formula is equivalent to
for i=0; i< size of fEvents; ++i)
if (fEvents[i].fNshower>0) {
return fShowers( func(i) );
}
}
where func(n) is defined as
return nth element in the list of (fEvents[j].fShwInd[0] for all j)
and hence it does
if (fEvents[0].fNShower>0) then print fShowers[fEvents[0].fShwInd[0]]
if (fEvents[1].fNShower>0) then print fShowers[fEvents[2].fShwInd[0]]
(this is because there is only 3 fShwInd; fEvents[0].fShwInd[0],
fEvents[0].fShwInd[1] and fEvents[1].fShwInd[0])
Now it turns out that simply using
tree->Scan("fShowers[fEvents[].fShwInd[0]].fEnergy","");
get how what you need
***********************************
* Row * Instance * fShowers[ *
***********************************
* 0 * 0 * 10 *
* 0 * 1 * 30 *
***********************************
Also
tree->Scan("fEvents.fEventNo:fShowers[fEvents[].fShwInd[]].fEnergy","");
was corrected to print (the array are intentionally not synchronized,
see TTree::Scan documentation)
***********************************************
* Row * Instance * fEvents.f * fShowers[ *
***********************************************
* 0 * 0 * 0 * 10 *
* 0 * 1 * 1 * 20 *
* 0 * 2 * 2 * 30 *
* 0 * 3 * 3 * *
***********************************************
To properly synchronize the array use (the condition is used to properly
synchronize the iterators:
tree->Scan("fEvents.fEventNo:fShowers[fEvents[].fShwInd[]].fEnergy",
"fEvents[].fShwInd[]*0==0");
***********************************************
* Row * Instance * fEvents.f * fShowers[ *
***********************************************
* 0 * 0 * 0 * 10 *
* 0 * 1 * 0 * 20 *
* 0 * 2 * 2 * 30 *
***********************************************
Also I introduced a new interface where you can select longer columns:
tree->Scan("fEvents.fEventNo:fShowers[fEvents[].fShwInd[]].fEnergy",
"fEvents[].fShwInd[]*0==0",
"col=16:37");
**********************************************************************************
* Row * Instance * fEvents.fEventNo * fShowers[fEvents[].fShwInd[]].fEnergy *
**********************************************************************************
* 0 * 0 * 0 * 10 *
* 0 * 1 * 0 * 20 *
* 0 * 2 * 2 * 30 *
**********************************************************************************
The syntax in the Scan options is as follow:
// colsize=ss
// Where 'ss' will be used as the default size for all the column
// If this options is not specified, the default column size is 9
// precision=pp
// Where 'pp' will be used as the default 'precision' for the
// printing format.
// col=xxx
// Where 'xxx' is colon (:) delimited list of printing format for
// each column if no format is specified for a column, the default is
// used.
// For example:
// tree->Scan("a:b:c","","colsize=30 precision=3 col=::20.10");
// Will print 3 columns, the first 2 columns will be 30 characters long,
// the third columns will be 20 characters long. The printing format used
// for the columns (assuming they are numbers) will be respectively:
// %30.3g %30.3g %20.10g
Now I should explain why I can't really solve the iterator synchronization
problem. Let's assume a formula like:
a[i1][i2][i3] + b[i4][c[j1][j2]][i5]
If a,b and c are independent, it is clear that this should unwind to
for (i1)
for (i2)
for (i3)
i4 = i1;
i5 = i3;
j1 = func(i2 and size of c)
j2 = func(i2 and size of c)
However if a and c are related:
a[i1][i2].d[i3] + b[i4][a[j1][j2].e][i5]
it would seems clear :( that this should unwnd to
for (i1)
for (i2)
for (i3)
i4 = i1;
j1 = i1;
j2 = i2;
i5 = i3; // I am not even sure.
I have not found any straight-forward (read than wont
take me less than a week to implement) ways to detect
properly and safely those cases. An alternative
that was propose was to allow the use of the 'iterator'
for the user to express those connection. This is
not simple to implement either.
All in all my choice has been to spend the time I
would need to implement this feature in straightening
and improving the new proxy based replacement for
MakeSelector (aka Running a script for Draw and MakeProxy).
Cheers,
Philippe
-----Original Message-----
From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Sue Kasahara
Sent: Friday, August 06, 2004 3:54 PM
To: roottalk
Subject: [ROOT] Looping over array entries with TTree::Draw
Hi roottalk,
I'm having trouble looping over entries in array variables using
TTree::Draw under a specific circumstance.
I've placed an example in:
http://www.hep.umn.edu/~schubert/roottest/ntptest.tar.gz
The example consists of three simple classes:
class NtpShower : public TObject {
...
Float_t fEnergy; // shower energy
ClassDef(NtpShower,1) //A reconstructed shower
};
class NtpEvent: public TObject {
...
Int_t fEventNo; // event number
Int_t fNShower; // number of showers in this event
Int_t* fShwInd; //[fNShower] array of indices into shower TClonesArray
ClassDef(NtpEvent,1) //A reconstructed event
};
class NtpRecord:public TObject {
...
TClonesArray* fShowers; //~> Array of showers
TClonesArray* fEvents; //-> Array of events
ClassDef(NtpRecord,1) //A reconstructed spill record
};
These classes are set up so that the user can use the shower indices stored
in the NtpEvent class to map back to the NtpShower objects stored in the
fShowers
TClonesArray.
In the test program FillNtp, a tree is created with a single main branch
to hold NtpRecord objects,
split at level = 99, One NtpRecord is generated and the fShowers array
is filled with 3 NtpShowers:
// shower 0 has fEnergy 10
// shower 1 has fEnergy 20
// shower 2 has fEnergy 30
and 4 NtpEvents:
// event 0 has 2 showers with fShwInd values of 0 &1
// event 1 has 0 showers
// event 2 has 1 shower with fShwInd value of 2
// event 3 has 0 showers
Now I try to use the arrays in a Draw (or Scan loop) and I find that the
results aren't what I expect.
For example,
tree ->
Scan("fShowers[fEvents[].fShwInd[0]].fEnergy","fEvents[].fNShower > 0");
yields:
***********************************
* Row * Instance * fShowers[ *
***********************************
* 0 * 0 * 10 *
***********************************
==> 1 selected entry
instead of the expected 2 entries. I can get 2 entries if I leave off
the selection string, but I find
I need this selection string to avoid array out of bounds if the first
argument to Scan or Draw
becomes more complicated, e.g.:
tree -> Scan("fEvents[].fNShower:fShowers[fEvents[].fShwInd[0]].fEnergy");
causes a rather enormous list of array indexing errors.
Is this a bug or is there an error in the way I'm expressing the loop
over the arrays?
Thanks,
-Sue
Fixed
root [2] tree->Scan("fEvents.fEventNo:fShowers[fEvents[].fShwInd[]].fEnergy","")
***********************************************
* Row * Instance * fEvents.f * fShowers[ *
***********************************************
* 0 * 0 * 0 * 10 *
* 0 * 1 * 1 * 20 *
* 0 * 2 * 2 * 30 *
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 3560)]
0x4023dc03 in TStreamerInfo::GetValueAux(int, void*, int, int) (type=43, ladd=0x8ce1e34, k=3, len=0)
at meta/src/TStreamerInfo.cxx:1440
1440 case kOffsetP + kInt_t: READ_ARRAY(Int_t)
root [1] tree->Scan("fEvents.fEventNo:fShowers[fEvents[].fShwInd[]].fEnergy","fEvents[].fNShower > 0")
***********************************************
* Row * Instance * fEvents.f * fShowers[ *
***********************************************
* 0 * 0 * 0 * 10 *
* 0 * 2 * 2 * 30 *
***********************************************
==> 2 selected entries
root [5] tree->Scan("fEvents.fEventNo*100:fEvents[].fShwInd[]:fShowers[fEvents[].fShwInd[]].fEnergy","fEvents[].fNShower > 0")
***********************************************************
* Row * Instance * fEvents.f * fEvents[] * fShowers[ *
***********************************************************
* 0 * 0 * 0 * 0 * 10 *
* 0 * 1 * 0 * 1 * 20 *
* 0 * 2 * 200 * 2 * 30 *
***********************************************************
==> 3 selected entries
(long long)3
stills wrong:
root [4] tree->Scan("fEvents.fEventNo*100:fEvents[].fShwInd[]:fShowers[fEvents[].fShwInd[0]].fEnergy","fEvents[].fNShower > 0")
***********************************************************
* Row * Instance * fEvents.f * fEvents[] * fShowers[ *
***********************************************************
* 0 * 0 * 0 * 0 * 10 *
* 0 * 1 * 0 * 1 * 10 *
* 0 * 2 * 200 * 2 * 30 *
***********************************************************
OK: root [3] tree->Scan("fShowers[fEvents[].fShwInd[0]].fEnergy","fEvents[].fNShower > 0")
***********************************
* Row * Instance * fShowers[ *
***********************************
* 0 * 0 * 10 *
* 0 * 2 * 30 *
***********************************
==> 2 selected entries
OK : root [3] tree->Scan("fEvents.fEventNo*100:fEvents[].fShwInd[]:fShowers","fEvents[].fNShower > 0");
***********************************************************
* Row * Instance * fEvents.f * fEvents[] * fShowers *
***********************************************************
* 0 * 0 * 0 * 0 * 0 *
* 0 * 1 * 0 * 1 * 0 *
* 0 * 2 * 200 * 2 * 0 *
***********************************************************
==> 3 selected entries
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:09 MET