Arrays of Double32_t not recognized as arrays?

[sbinet]

While trying to implement TLeafD32 for groot, I stumbled on this:

// run.C
void run() {
	auto f = TFile::Open("d32.root", "RECREATE");
	auto t = new TTree("tree", "tree");
	
	Double32_t v1;
	t->Branch("v1", &v1, "v1/d");

	Double32_t v2;
	t->Branch("v2", &v2, "v2/d[ 0 , 100 ]");

	Double32_t v3;
	t->Branch("v3", &v3, "v3/d[0 , 0, 14]");

	Double32_t v4;
	t->Branch("v4", &v4, "v4/d[ -pi , twopi, 14]");

	Double32_t v5[3];
	t->Branch("v5", v5, "v5[3]/d[ 0, 100]");

	double d5[3];
	t->Branch("d5", d5, "d5[3]/D");

	for (Int_t i = 0; i < 10; i++) {
		v1 = i+0.1;
		v2 = i+0.1;
		v3 = i+0.1;
		v4 = i+0.1;
		v5[0] = i+0.1;
		v5[1] = i+0.2;
		v5[2] = i+0.3;

		d5[0] = i+0.1;
		d5[1] = i+0.2;
		d5[2] = i+0.3;
		t->Fill();
	}
	t->Write();
	f->Close();
}

running this:

$> root -b -q ./run.C
$> root ./d32.root 
   ------------------------------------------------------------
  | Welcome to ROOT 6.18/04                  https://root.cern |
  |                               (c) 1995-2019, The ROOT Team |
  | Built for linuxx8664gcc on Sep 11 2019, 15:38:23           |
  | From tags/v6-18-04@v6-18-04                                |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
   ------------------------------------------------------------

root [0] 
Attaching file ./d32.root as _file0...
(TFile *) 0x564692ac64e0
root [1] ((TTree*)_file0->Get("tree"))->Scan("v2:v5:d5");
***********************************************************
*    Row   * Instance *        v2 *        v5 *        d5 *
***********************************************************
*        0 *        0 * 0.0999999 * 0.0999999 *       0.1 *
*        0 *        1 *           *           *       0.2 *
*        0 *        2 *           *           *       0.3 *
*        1 *        0 * 1.0999999 * 1.0999999 *       1.1 *
*        1 *        1 *           *           *       1.2 *
*        1 *        2 *           *           *       1.3 *
*        2 *        0 *       2.1 *       2.1 *       2.1 *
*        2 *        1 *           *           *       2.2 *
*        2 *        2 *           *           *       2.3 *
*        3 *        0 *       3.1 *       3.1 *       3.1 *
*        3 *        1 *           *           *       3.2 *
*        3 *        2 *           *           *       3.3 *
*        4 *        0 *       4.1 *       4.1 *       4.1 *
*        4 *        1 *           *           *       4.2 *
*        4 *        2 *           *           *       4.3 *
*        5 *        0 *       5.1 *       5.1 *       5.1 *
*        5 *        1 *           *           *       5.2 *
*        5 *        2 *           *           *       5.3 *
*        6 *        0 *       6.1 *       6.1 *       6.1 *
*        6 *        1 *           *           *       6.2 *
*        6 *        2 *           *           *       6.3 *
*        7 *        0 *       7.1 *       7.1 *       7.1 *
*        7 *        1 *           *           *       7.2 *
*        7 *        2 *           *           *       7.3 *
*        8 *        0 *       8.1 *       8.1 *       8.1 *
Type <CR> to continue or q to quit ==> q
***********************************************************

ie: it seems the v5 branch/leaf isn’t recognized as an array.

indeed, looking at its GetTitle() value, I get (for v5 and for d5 (which is correctly recognized as an array)):

root [3] ((TTree*)_file0->Get("tree"))->GetLeaf("v5")->GetTitle()
(const char *) "d[ 0, 100]"
root [4] ((TTree*)_file0->Get("tree"))->GetLeaf("d5")->GetTitle()
(const char *) "d5[3]"

the arrays values are, of course correctly written out (and can be read back):

root [7] auto t = (TTree*)_file0->Get("tree")
(TTree *) @0x7ffcf94aa800
root [8] t->GetEntry(0)
(int) 51
root [9] t->GetLeaf("d5")->GetValue(0)
(double) 0.10000000
root [10] t->GetLeaf("d5")->GetValue(1)
(double) 0.20000000
root [11] t->GetLeaf("v5")->GetValue(0)
(double) 0.099999993
root [12] t->GetLeaf("v5")->GetValue(1)
(double) 0.20000001

but ISTM the machinery to decide whether a leaf is n-dim or not is broken by the borked title.
is this a known limitation of TLeafD32 (and probably TLeafF16 as well) ?

---

Please read tips for efficient and successful posting and posting code

ROOT Version: 6.18/04
Platform: linux8664gcc
Compiler: gcc 9.2.0

---

[pcanal]

This is ‘known’, see https://sft.its.cern.ch/jira/browse/ROOT-10149.
RDataFrame worked around it: https://github.com/root-project/root/pull/3863/commits/9c9fa34ec95e5768f9133e3dfab5a8f7add3f7dc

Cheers,
Philippe.

[sbinet]

thanks.

IIUC, that workaround won’t completely work for n-dim arrays:

auto t = new TTree("t", "t");
Double32_t v1[10][10];
Double32_t v2[100];
double     v3[10][10];

auto b1 = t->Branch("v1", v1, "v1[10][10]/d");
auto b2 = t->Branch("v2", v2, "v2[100]/d");
auto b3 = t->Branch("v3", v3, "v3[10][10]/D");

b1->GetLeaf("v1")->GetLenStatic(); // (int) 100
b2->GetLeaf("v2")->GetLenStatic(); // (int) 100
b3->GetLeaf("v3")->GetLenStatic(); // (int) 100

b1->GetLeaf("v1")->GetTitle(); // (const char *) "d"
b2->GetLeaf("v2")->GetTitle(); // (const char *) "d"
b3->GetLeaf("v3")->GetTitle(); // (const char *) "v3[10][10]"