Remove current RHist prototype #18191
Conversation
|
There is significant peace of code in JSROOT. Do we want to keep it? |
Yes, I saw it but I'm not expert enough in that code. We may want to remove it as well, I'm not sure how much could (or even should) be reused with a future prototype |
Test Results 18 files 18 suites 4d 4h 1m 47s ⏱️ Results for commit a608dde. ♻️ This comment has been updated with latest results. |
It is very much depends how future prototype will looks like. |
Indeed. The code can still be found and checked out and adapted after removal. We would only lose the ability to Edit: I see you approved already. 🙂 |
For a number of reasons, it is not what we want for the future generation of histogram classes in ROOT: * It is templated on the DIMENSIONS, the PRECISION, and optional bin statistics. This makes it hard(er) to use for IO. * The RHist interface has a pointer to an abstract, polymorphic RHistImplBase. * The concrete RHistImpl is templated on the processed axis types. * The polymorphic pointer makes the current prototype incompatible with RNTuple (unless using streamer fields). * It also takes minutes to compile for higher dimensions because concrete RHistImpl have to be generated for all combinations of axis types, which grows exponentially. The plan is to remove the current prototype now, in time for the next ROOT release v6.36, and then add a new implementation after.
|
Build failure on |
It was removed in root-project/root#18191 and prevents compilation.
It was removed in root-project/root#18191 and prevents compilation.
4 participants
For a number of reasons, it is not what we want for the future generation of histogram classes in ROOT:
DIMENSIONS, thePRECISION, and optional bin statistics. This makes it hard(er) to use for IO.RHistinterface has a pointer to an abstract, polymorphicRHistImplBase.RHistImplis templated on the processed axis types.RHistImplhave to be generated for all combinations of axis types, which grows exponentially.The plan is to remove the current prototype now, in time for the next ROOT release v6.36, and then add a new implementation after.