ActsExamples::RandomNumbers is not random for continuous run seed

[Corentin-Allaire]

Hello everybody !

As some of you might know, I have been generating ttbar events using the OOD for a while now to train the Seeding Transformer I have been developing.
Today I realised that the ActsExamples::RandomNumbers we use to generate event-based seed is not random at all...

It uses hash_combine (https://www.boost.org/doc/libs/1_36_0/doc/html/hash/reference.html#boost.hash_combine) to combine the global run seed with the event number to create a unique event seed. Unfortunately, this is not unique at all if you perform multiple simulation runs with an adjacent seed. So what is the issue with the hash_combine implementation?

seed ^= hash_value(v) + 0x9e3779b9 + (seed << 6) + (seed >> 2);

If v (for us, the event number) is an int, then hash_value is the identity. What this means is that the new seed can be written (for seed>0):

seed ^= event_id + cte + seed*64 + int(seed / 4);

Which will lead to many collisions, for example, the 3 following seed-event pairs will result in seed 2655077414 : (10110, 64), (10111, 1), (10112, 13)

Right now, to avoid the issue, I try to make sure my seeds are not consecutive (using seed^2 works nicely). But I think we should either use something other than hash_combine (I didn't check what approaches exist) or maybe use a type for which hash_value is not the identity.

To loop back to what I am doing right now, I simulated 50k ttbar events (500 runs of 100 events) with a seed from 1000 to 1500. Results: 37% seed collision and only 30k unique events. More probematic my training and testing events are all mixed :(

If people want to recreate the issue, I am joining a small Python script that shows this exact effect.

test_seed.py

[paulgessinger]

Ok so we either move away from boost::hash_combine, or we use some hash function on the event number and seed inputs that distributes them in case they are consecutive ints.

[Corentin-Allaire]

I fully agree ! I don't know if people have any preference for either method

[andiwand]

the other option is to have a main RNG and to pull random numbers that are then used as seeds for the distributed RNGs for individual algorithms and events. I guess we want this to be stable so order would matter

the other option is https://en.cppreference.com/w/cpp/numeric/random/seed_seq/generate.html

also: I guess it makes sense be able to write out the seeds somewhere? so one can easily check if there are collisions and how many

[Corentin-Allaire]

Since we want ro generate a 32bit seed in the end a solution could be:

using RandomSeed = std::uint32_t;
size_t seed = (RandomSeed(m_cfg.seed)<<32) + (RandomSeed(context.eventNumber))
seed *= big_int
seed ^= (seed>>32)
return RandomSeed(seed)

If we want to do @andiwand route the advantage is that it would let us decorelated the random seed of the different algorithm in a job. Which we might be slightly better than the current setup where the seed of all algorithm in an event are the same (but maybe that doesn't really matter)

[paulgessinger]

But can we get this stable with MT event execution? That was the main reason to use the event number to initialize the seed. For that matter, it would also be possible to use the algorithm index or even name as an additional seed to make the sequences different for each algorithm.

I think if we replace the hash combine with a custom function that pre-hashes the inputs with non-identity we should already improve this by a lot.

[dhrou]

What about : seed => initialise rnd generator, generate one 32 bit integer => seed_rndm ; ievent => initialise rnd generator, generate one 32 bit integer => event_rndm, and finally hash_combine seed_rndm and event_rndm.
The risk of duplicate would become minimal, whatever choice for seed

[dhrou]

OK forget it, I see the discussion as moved to #5325