Re: multiple histos with the same name

Hi Brett,

If you go on with Histman, keeps us posted with its evolution.

Rene Brun

On Wed, 8
Jun 2005, Brett Viren wrote:

> 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 - 07:05:42 MEST