GetRandom() and gRandom

ROOT
1

Hi,
There is one of useful methods under TH1 or TF1 called GetRandom(), if looking into this method, it is based on gRandom->Rndm() to generate random numbers. However, this is further based on the class TRandom addessed to have defects. I am wondering if any choice to use TRandom3 to generate random numbers obeying given histograms or functions.

Cheers,
Zhiyi.

2

[quote=“zhiyiliu”]Hi,
There is one of useful methods under TH1 or TF1 called GetRandom(), if looking into this method, it is based on gRandom->Rndm() to generate random numbers. However, this is further based on the class TRandom addessed to have defects. I am wondering if any choice to use TRandom3 to generate random numbers obeying given histograms or functions. [/quote]

Here’s what I do at the beginning of all of my programs that use random numbers (for exactly the reason you stated).

delete gRandom;
gRandom = new TRandom3;

Cheers,
Charles

3

delete gRandom; gRandom = new TRandom3;
This is a nop. The default random generator (pointed by gRandom) is TRandom3 (unless you use a very old version).

Rene

4

[quote=“brun”]delete gRandom; gRandom = new TRandom3;
This is a nop. The default random generator (pointed by gRandom) is TRandom3 (unless you use a very old version).
[/quote]

How old is old? CDF still uses 4.00.08…

5

your version is about 12 production releases old. ::slight_smile:
see the various announcements about random numbers in the successive release notes.

Rene

6

[quote=“brun”]your version is about 12 production releases old. ::slight_smile:
[/quote]

Yes, that’s what happens when you have (a lot of) data. It can be particularly painful to switch when a fair bit of the API has changed (as is the case with Root).

Seeing as that would be a sequential and not even a binary search, it hardly seems worthwhile. Without a it’s version xxx, it seems safer to just

delete gRandom; gRandom = new TRandom3;

Which is at worst a no-op and at best the right thing to do.

7

Really? Could you give some examples of API changes preventing you to move to newer versions?

Rene

8

Really? Could you give some examples of API changes preventing you to move to newer versions?

Rene[/quote]

One I can remember off the top of my head is changing what Branch() would accept. It used to assume (void*) was a TClonesArray

  treePtr->Branch ("electrons", (void*) elecCLPTcaPtr);

would work in Root 4, but not Root 5. It now needs to be

  treePtr->Branch ("electrons", "TClonesArray", (void*) elecCLPTcaPtr);

There are others that we found when trying to move to Root 5. If you are really interested, I can ask the people who spent the time porting the code.

Charles

p.s. One of our “favorites” is that we have no problem accessing data from our rootd servers from root 4, but it does not work if we run root 5. We still have no solution for this.

9

Charles,

There are no changes when creating a Tree branch for a TClonesArray. Note that you have to specify the address of the pointer and not its value.

The incompatibilities between successive versions that we try to avoid of course as much as possible are always documented in the release notes.

Let me know about not documented incompatibilities that you (or colleagues) found in your attempt to migrate.

Rene

10

Hi Rene,

To be blunt, it hardly matters at ALL if the changes are documented. CDF is a running experiment with literally millions of lines of code that were written by many hundreds of different people. Every time you change the API, you make it extremely difficult for an experiment to change versions of Root.

Changing underlying structure is fine. Adding new features is great. Changing the API is bad.

Cheers,
Charles

p.s. O.k. If you change the API and don’t document it, I agree that that is worse. But not by as much as you might think.

11

I agree with everything you say. Following your statement

I would like to know what this “fair bit” is.

Rene

12

[quote]p.s. One of our “favorites” is that we have no problem accessing data from our rootd servers from root 4, but it does not work if we run root 5. We still have no solution for this.[/quote]Note that in this case, the rootd server has actually been customized by CDF. And CDF and the developer supporting rootd have not been able to close the loop on the cause of the issue (in our test rootd is backward compatible …).

Cheers,
Philippe.

13

[quote]would work in Root 4, but not Root 5. It now needs to be…
treePtr->Branch (“electrons”, (void*) elecCLPTcaPtr); [/quote]Actually better yet:treePtr->Branch ("electrons", elecCLPTcaPtr);which, if I remember correctly, was actually the recommend syntax in root v4 (as opposed to the explicitly void* cast).

My point being, that unfortunately this is a slightly corner case, where we do support the old interface as it was intended but some legal (but more or so unexpected) use are not :frowning:

Cheers,
Philippe.