Problem with curand

I have some trouble when using curand()
I am porting my code (which runs on CPU) into nvcc. I used the following random number generator
#define P1 16807
#define N 2147483647
int rand_naive(int xn){
return (xn*P1)%N;
Then I use rand_naive/N to give a float number in [0,1)
I use each random number only once, then drop it and find another. (I want to secure that the result is the same every time I run it).

However, it is a little difficult for me to find a similar function in curand. curand_init() gives a sequence, but I don’t know it maximum value (i.e., N) and I don’t want to store the whole sequence, I just want to find the next random number in each call.

I wonder if anyone could give some suggestions?

Thanks in advance

What you are using now is a PRNG of poor quality, i.e. the generated sequence is not very random. Avoid.

Last time I checked, the high-quality PRNGs in CURAND all return uniformly distributed unsigned 32-bit integers (unsigned int), i.e. in [0, 232-1], or alternatively a float uniformly distributed in (0, 1]. The relevant function is curand_uniform(). There are also functions for generating other distributions and other return types. If you call curand() with the same initial state, and don’t modify the state manually, the same sequence of random numbers will be generated.

The CURAND documentation should be your first-stop go-to document.

Thanks for reply.
The point here is that I want to obtain random number one by one via iteration rather than calculate the whole sequence, so that I can store the obtained random number into the shared memory.

Each call to curand_uniform() returns one random number. There is no way to “compute the whole sequence”, as the state of each PRNG is way too large for that, with the period of each generator generally > 2128 as I recall (check the documentation for the specifics of each generator).

̶S̶o̶r̶r̶y̶ ̶f̶o̶r̶ ̶m̶y̶ ̶m̶i̶s̶l̶e̶a̶d̶i̶n̶g̶ ̶e̶x̶p̶r̶e̶s̶s̶i̶o̶n̶.̶ ̶
̶I̶ ̶u̶n̶d̶e̶r̶s̶t̶a̶n̶d̶ ̶t̶h̶a̶t̶ ̶c̶u̶r̶a̶n̶d̶_̶u̶n̶i̶f̶o̶r̶m̶(̶)̶ ̶c̶o̶u̶l̶d̶ ̶r̶e̶t̶u̶r̶n̶ ̶a̶ ̶s̶i̶n̶g̶l̶e̶ ̶r̶a̶n̶d̶o̶m̶ ̶f̶l̶o̶a̶t̶ ̶n̶u̶m̶b̶e̶r̶ ̶i̶n̶ ̶0̶-̶-̶1̶.̶ ̶H̶o̶w̶e̶v̶e̶r̶,̶ ̶i̶t̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶g̶i̶v̶e̶ ̶t̶h̶e̶ ̶(̶u̶n̶s̶i̶g̶n̶e̶d̶ ̶l̶o̶n̶g̶ ̶l̶o̶n̶g̶ ̶s̶e̶e̶d̶)̶ ̶w̶h̶i̶c̶h̶ ̶i̶s̶ ̶r̶e̶q̶u̶i̶r̶e̶d̶ ̶f̶o̶r̶ ̶n̶e̶x̶t̶ ̶r̶a̶n̶d̶o̶m̶ ̶f̶l̶o̶a̶t̶,̶ ̶t̶h̶a̶t̶ ̶i̶s̶ ̶w̶h̶a̶t̶ ̶I̶ ̶m̶e̶a̶n̶t̶ ̶b̶y̶ ̶"̶i̶t̶e̶r̶a̶t̶i̶o̶n̶"̶.̶

I get it. The seed can be given via other methods.

The state of each CURAND random number generators is larger than what would fit into a single unsigned long long. I would suggest reading a bit more about modern PRNGs in general, and parallel random number generators in particular.

Thanks, I will check them out when I could spare some time from physics…

I don’t know how random numbers apply to your use case. Generally speaking, high-quality simulations of natural phenomena require high-quality PRNGs. The output of simple congruential PRNGs falls into easily identifiable planes:

George Marsaglia, “Random numbers fall mainly in the planes.” Proceedings of the National Academy of Sciences of the United States of America, Sep 1968;61(1):25-28 (online)

One would not want the structure of the random number sequence create artifacts in the simulation results that are merely of a numerical nature, with no counterpart in nature. For the same reason, it is important in a parallel computing environment to ensure that the sequences of random numbers used by each thread are not correlated.