Below an attempt to answer some Jacek's questions
Rene Brun
.......................................................................
===>answer to Jacek questions about Drawing a subrange of an histogram
>Could you, please, tell me how can I Draw part of a histogram ( NOT FIT,
>JUST DRAW ). I would like to do this from a root c-source code line
>( something like EventLength.Zoom(10.,20.) which should draw the
>part of the EventLength histogram in x-axis-subrange from 10. to 20. ),
>and graphically - assume I have drawn the whole histogram using
>EventLength.Draw(), and then I would like to see a part of it, so I would
>like to "klick" at the left-edge-of-required-zoom, then "klick" at the
>right-edge-of-required-zoom and ... that should be all.
I had no time to implement this facility in version 0.9.
I know that you have been confused by the fact that I put a slider
in the DrawPanel. This slider is inactive as it is.
Unfortunately, I cannot promise to activate this slider for the coming
release. We are very busy preparing our parallel version for NA49.
I am hoping to give this job to a summer student together with many
other
developments in the graphics area.
.......................................................................
===>answer to Jacek questions about FindObject.
>>Now, Fons'es advice was :
>> Use pointers to the objects instead of trying to find them by name
>> everytime.
>
>I can't. Each of my histograms may disappear/reappear between any two
>adjacent calls to the function which fills them ( if they exist ).
>Sounds strange ? Assume we have the multithreaded root. Now assume one
>thread gets events from acquisition, unpacks them using my "function"
>( shared library, of course ) which fills histograms - IF THEY EXIST. The
>"main" thread is used to look into these histograms on the fly. I would
>like to be able to interactively delete histograms ( which I don't want to
>watch any more ), create new histograms, ..., without breaking the thread
>that gets/unpacks events. The whole "inteligence" should be placed in the
>fool-proof unpacking function. I don't like the idea to additionaly have
>( and maintain ) a set of global-histogram-pointers SHARED between
>compiled library and interpreted code ( apart from the histogram-objects
>themselves ).
>Some time ago I was adviced to use :
> if (hist=(TH1F*)gDirectory->GetList()->FindObject("EventLength"))
> { ... }
>as a replacement for
> if ( hexist(9999) ) ...
>Now I tried to use it ... having some 100 histograms in directory ... .
>Seems that the root FindObject is order(s) of magnitude slower then paw's
>hexist ( used with the same amount of histograms ).
>Jacek.
root FindObject must be much slower than hbook hexist. It is not
designed
as a replacement for this function. It is based on string search.
hbook identifiers are stored in a table in increasing order. A binary
search
can be performed on this table very quickly. I checked on my HP that
in case of 300 histograms, hexist takes about 2 microseconds.
Doing the samething with ROOT takes around 200 microseconds with my new
version
using a HashList. So it is hopeless for you.
But, I believe you have better solutions.
In principle, we assume that most people will create histograms and fill
them
in different member functions of the same class. In this case you
declare
your pointers at the beginning of the file and you can share them
between
booking and filling. Doing that ROOT is between 2 to 3 times faster than
Hbook.
In your case, however, you cannot give "nice" names to your pointers
because you want to be general. You can create one (or more) array of
pointers instead
eg TH1F *histos[1000]
and you use the histogram index like you were using the hbook
identifier.
When you delete the histogram, you must reset the pointer to null.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:26:18 MET