rocrand_set_offset unexpected behaviour about rocrand

[neon60]

@Maetveis Please check the issue and try to reproduce.

[Maetveis]

The issue here is that the random number generation does not work the way you're thinking it works.
Lets call our random number generator g. Since g has internal state lets keep track of the number of calls to g by its superscript. There can be multiple generators so lets mark them with a subscript.
With this notation for example is the third generator with two prior applications.

What you are expecting is that the random numbers are generated like this:

I.e. the same generator (with the same seed) is used with seqential offsets.
But they are generated like this:

I.e. each output is generated by an independent generator. The next random numbers would be

With offset = n each generator is set to the same state as if has been used n times. So sticking with the same notation:

Your reproducer would pass with this code:

  ROCRAND_CALL(rocrand_create_generator(&gen, ROCRAND_RNG_PSEUDO_MRG32K3A));
  ROCRAND_CALL(rocrand_create_generator(&gen2, ROCRAND_RNG_PSEUDO_MRG32K3A));
  ROCRAND_CALL(rocrand_set_seed(gen, 1));
  ROCRAND_CALL(rocrand_set_seed(gen2, 1));
  ROCRAND_CALL(rocrand_set_offset(gen2, 1));

  // Two applications of gen, overwrite deviceA with second result
  ROCRAND_CALL(rocrand_generate(gen, deviceA, NUM));
  ROCRAND_CALL(rocrand_generate(gen, deviceA, NUM));
  
  ROCRAND_CALL(rocrand_generate(gen2, deviceB, NUM));
  // deviceA and deviceB now have the same values

[sbalint98]

Thank you for your quick response and your thorough explanation!

I think the snippet that you have provided does not cover the use case that we are interested in. Our primary goal is to reproduce the behaviour of curand, which generates two lists with an offset.

For example, given two lists original_ran_list, and ofsetted_ran_list generated by generators with the same seed but the generator of ofsetted_ran_list were applied the offset of n, the following property should hold: original_ran_list[i+n] == ofsetted_ran_list[i]. (for curand behaviour see this example:
curand_offset.txt )

if I understand your explanation correctly, with rocRAND one way to achieve the same semantics is to call rocrand_generate NUM+1 times and then discard the first n elements. I believe this approach would be rather cumbersome to implement, and very inefficient.

Could you suggest a better solution to achieve the semantics described above?

[Maetveis]

This is basically a continuity issue, the random numbers are not generated in a consistent order.
For example if one was to generate a 100 elements using two calls to the host API generating 50 elements each, then compare that with the same generator and the same seed generated with 20 then 80 elements, then the they differ after the first 20 elements.

My explanation was only for explaining what rocRAND does currently, but it wont have the same effect as setting the offset for cuRAND. The rocRAND behaviour is incorrect, I don't think there's a reasonable (as in using the host api) workaround until its fixed.

[Maetveis]

You can now try out the branch mrg32k3a_offset (#236) it should fix the mrg32k3a generator (used in your reproducer). Other generators are in separate branches.