Re: multiple histos with the same name

Hi Rene,

Rene Brun <brun_at_pcroot.cern.ch> writes:

> Thanks for sending a link to your code and presentation.
> I had a very quick look at your system and I have the following
> few immediate comments:
>
> -your interface to booking/filling is only a very small subset
> of the histogramming system. For example
> -you do not have support for variable bin width histograms
> -you do not support profile 1 and 2-D

Yes, this is very true. However, the Adopt() method allows one to store any histogram objects (any TObject, actually) that are created by hand.

> -you do not support 3-d histograms
> -you cannot fill with arrays
> -you cannot fill with strings
> .. just to mention a few

This is also correct. Although as above, you can still create the object yourself, store via Adopt and later retrieve them via Get<>().

> -Your Fill1d(const char* pathname function and Fill2d will be
> extremely inefficient.

Yes, indeed. If one needs to fill in a tight loop, it is better to call Get<>() outside the loop to get a pointer to the histogram, then use that pointer like normal.

> -In a real application, you will probably see a mixture of calls
> to HistMan and normal ROOT calls. This will be very confusing.

Yes, it would likely a mixture. HistMan by no means tries to supplant ROOT! Whether it is confusing or not depends, like anything, on how well the user programs with it.

> -people opening a normal ROOT histogram file and viewing it
> via TBrowser will automatically load in memory (a la ROOT)
> the histograms or other objects associated with the file.

Yes, that is correct. The only added feature in this regards is that one can create a HistMan instance attached to a previously written file and it will look the same as it did when it was initially filled. This feature is more of a policy enforcement than anything else.

The other feature is that a HistMan instance can be constructed such that it only sees a part of the hierachy. This is good to assure different parts of the code are forced to use different parts of the hierarchy to store their histograms.

> Sorry to list only these negative points. I understand the possible
> benefits of an histogram manager.

No problem at all. It is very useful to hear such criticism. And as you see, I agree with all of it!

HistMan isn't meant to be earth shattering. Its main goal was to provide this hierarchy to allow for identically named histograms to be tracked. Its secondary goal was to export a simpler API for booking/filling which can sometimes be convenient, while at the same time does not stop people from using the full expressive API of the TH classes if they needed it.

Thanks,
-Brett. Received on Thu Jun 09 2005 - 00:24:21 MEST