Thanks @pcanal . Is there any way to get Draw or Scan to treat them as integers instead? It seems to me that that use case would be far more common than using it to store strings…
However this will not work when clicking on a branch when inspecting a file in a TBrowser… Why can’t int8_t be interpreted as a number by default? I don’t see why anyone in HEP would want to make a histogram of characters, whereas storing small integers as int8_t seems like a common use case.
TTree does NOT know “int8_t” or “uint8_t” as variables’ “fundamental types”.
It only knows “Char_t” (“signed char”) and “UChar_t” (unsigned char), where “char” is assumed to be 8-bits wide.
BTW. I think, ROOT unconditionally expects that a “char” is a “signed char”.
Error in <TTreeReaderArrayBase::CreateContentProxy()>: The branch Jet_idx contains data of type float. It cannot be accessed by a TTreeReaderArray<signed char>
TTree::Draw does not like it, I suppose it interprets the branch as float:
This is how branches are filled in the CMS NanoAODs, and I don’t think we can easily change that… I was simply looking into replacing the 32-bit integers currently used to store collection sizes, indices, charges, discrete IDs, …, by 8-bit integers, as it seemed like we could gain a few % on disk by doing that (despite compression). However I don’t want people using those files to have to do tricks like Jet_idx+0 when drawing branches… If it’s not possible, so be it, but it’s really unfortunate.
If you define the branch using the “t.Branch("Jet_idx", &(temp.front()), "Jet_idx[nJet]")” syntax then you are again limited to the predefined variables’ “fundamental types”. The default is “Float_t” (i.e., ROOT thinks it’s a "Jet_idx[nJet]/F", so you get the error).
BTW. Why don’t you simply try (no need for the “nJet” at all): auto br = t.Branch("Jet_idx", &temp);
Yes, I know this problem since years ago here.
It’s time you fix it.
The current statement is clear: The leaf referred to by nelem **MUST** be an int (/I)
Or you ask @pcanal and/or @Axel to finally support “unsigned integers” as [nelem] variable-size lengths.
A “std::vector” is by definition “variable-size”, too.
I’m only now learning about this… I’ll put it on the my list. Why is it such a problem if it’s been working fine for years?
Ah yes, OK. That means changing from arrays to STL vectors, this is really a change in the NanoAOD format which would potentially break many things downstream, so it’s not something we would do lightly.