rtree: possibility to implement buildIndex() ?

[rmadar]

I was just wondering how difficult would be to implement the t->BuildIndex("br1", "br2") function and the corresponding t->GetEntryWithIndex(v2, v2) function? I might need it in my analysis, but I can also probably find a work around if that's a lot of work

[sbinet]

probably not too complicated. (famous last words)

do you have an example or use case for this?

the rtree.Reader interface is "batch oriented".
what the TTreeIndex class provides is something more akin to a random access cursor into entries. (so there might be some impedance mismatch)

[rmadar]

Hum ok ... It is still a bit of work then. The use case is exactly the one discussed here: https://root-forum.cern.ch/t/size-limit-in-t-buildindex-function/42318. I can provide a small example later (tomorrow, probably). But I think it might be reasonable to postpone it to later (I am not even sure to really need it at the end).

[sbinet]

from that little snippet, it seems what you are aiming at is a way to "add columns" to a tree, from another tree, aligned with some column values of the first tree.

ie: a way to modify rtree.Join so the rows of the other tree are in some user-defined order.

• https://godoc.org/go-hep.org/x/hep/groot/rtree#Join

a possible API:

var (
    recTree = ...
    mcTree  = ...
)

r, err := rtree.Join(recTree, rtree.IndexedTree(mcTree, "branch1", "branch2").OrderBy(recTree))

(well, something along these lines, I guess.)

[rmadar]

It is indeed something similar to adding column, except that the number of entries in the two trees can be different, and then not a perfect match beteween the two sets of events. Some events can be only in the first tree, while other can be only in the second.