Baillehache Pascal's personal website

Pseudo-random floating-point numbers generation.

While adding the ELO ranking system to LibCapy I wanted to generate pseudo-random floating-point numbers to make the unit test. It's a subject I had until then overlooked, so I felt like learning a bit more about it. As one should expect it's just another never ending story and after spending a whole afternoon browsing Wikipedia's articles, without understanding one-tenth of them, it took me several days to escape from that black hole...

Integer random numbers

The ISO C srand() and rand() functions are implemented in the glibc library as a linear-feedback shift register, which gives better performances over the linear congruential generator suggested by the standard. Happy me, from reading Wikipedia articles that's the type of pseudo-random generators I thought would fit my needs: playing with procedural generation, generative art, machine learning, etc... (and not serious cryptographic stuff). In particular, the xorshift algorithm developped by Pr. George Marsaglia has the quality of being very simple and performant, so I decided to use it in LibCapy.

With the view to check my implementation of xorshift I've searched how to evaluate the performance of a generator. This is an overly complicated subject as one could expect, so I thought I would first look at one simple characteristic: these integers should be uniformly distributed. I.e. in the long run, every possible integer should be generated approximately the same number of time.

#include <LibCapy/capy.h>

// Number of buckets
// The number of all possible values is too large to keep statistics for each.
// Instead, split the whole range into buckets and keep the statistics per
// buckets.
#define NB_BUCKETS 2000

// Array to memorise the number of occurence per bucket
// 'NB_BUCKETS + 1' for the overflow on the maximum generated value
uint32_t statistics[NB_BUCKETS + 1];

// CapyRandom instance
CapyRandom capyRnd;

// Helper functions to commonalise the code in the Run() function
uint64_t TestRand(void) {
  return rand() / (RAND_MAX / NB_BUCKETS);
}

uint64_t TestCapy(void) {
  return $(&capyRnd, getUInt64)() / (UINT64_MAX / NB_BUCKETS);
}

// Run the test given the pseudo-random generator 'rnd' and save the result
// in 'filename'
void Run(
  uint64_t (*rnd)(void),
  char const* const filename) {

  // Reset the statistics
  loop (i, NB_BUCKETS + 1) statistics[i] = 0;

  // Variable to memorise the number of occurences in the most populated
  // bucket
  uint32_t nbOccurence = 0;

  // Loop until a bucket contains a given number of occurences
  uint32_t nbMaxOccurence = 1000000;
  while (nbOccurence < nbMaxOccurence) {

    // Pick a bucket at random
    uint64_t bucket = rnd();

    // Update the statistics
    ++(statistics[bucket]);

    // Update the number of occurences in the most populated bucket
    if (nbOccurence < statistics[bucket])
      nbOccurence = statistics[bucket];

  }

  // Get the number of occurences in the least populated bucket
  uint32_t nbMinOccurence = nbMaxOccurence;
  loop (i, NB_BUCKETS)
    if (nbMinOccurence > statistics[i])
      nbMinOccurence = statistics[i];


  // Save the results to the file
  FILE* stream = safeFOpen(filename, "w");
  uint32_t maxDiffOccurence = nbMaxOccurence - nbMinOccurence;
  safeFPrintf(stream, "# maxDiffOccurence %u\n", maxDiffOccurence);
  safeFPrintf(stream, "%s", "# bucket nbOccurence\n");
  loop (i, NB_BUCKETS)
    safeFPrintf(stream, "%d %d\n", i, statistics[i]);
  fclose(stream);

}

// Main function
int main() {

  // Print info for reference
  println("NB_BUCKETS: %d", NB_BUCKETS);
  println("RAND_MAX: %d, UINT64_MAX: %lu", RAND_MAX, UINT64_MAX);

  // Run the test with the standard rand function
  srand(time(NULL));
  Run(TestRand, "intRand.txt");

  // Run the test with the CapyRandom class
  capyRnd = CapyRandomCreate(time(NULL));
  Run(TestCapy, "intCapy.txt");
  CapyRandomDestruct(&capyRnd);

  return EXIT_SUCCESS;

}

The distribution produced looks like this: (buckets on the x-axis, number of occurence on the y-axis)

We can see that both distributions are relatively uniform as desired. Is that uniform 'enough' (I'll learn later it's the chi-squared test) ? Isn't grouping several values into one bucket hiding some bias ? It's just one run, would that repeat consistently ? Yes, such a simple test is very weak, but bear with me one second. At least, my implementation of xorshift giving similar results to rand suggests I haven't completely screwed it up.

Floating point random numbers

Pseudo random generators generate sequences of bits usually interpreted as integers. In ISO C it's a 2 or 4 bytes integer value between 0 and RAND_MAX for rand. For CapyRandom I'm using 8 bytes integer value, from 0 to UINT64_MAX. Now, I need to generate floating-point numbers too. The solution I've always used was too simply divide the pseudo-random integer value by it's maximum possible value to get a real in [0.0, 1.0] (and scale/translate it as needed). But thinking about it I wondered if there isn't a bias induced by the non uniformity of the representation of floating point values. Then I modified my test program as follow:

...
// Helper functions to commonalise the code in the Run() function
double TestRand(void) {
  return (double)rand() / (double)RAND_MAX;
}

double TestCapy(void) {
  return $(&capyRnd, getUInt64)() / (double)UINT64_MAX;
}
...
    // Pick a bucket at random
    uint64_t bucket = rnd() * (double)NB_BUCKETS;
...

which produced the following results:

There is still no obvious problem, however I kept skeptical. Then I searched on the subject and I came accross this paper by Pr Allen B. Downey. As he explains, generating floating point number by division is good enough for simple use case but it has the flaw to miss many possible floating point values (hidden inside the buckets). The exact number of missed values can be obtained with the following code for float:

union { float f; uint32_t i;} v, prev, low, high;
low.f = (float)0 / (float)UINT32_MAX;
high.f = (float)UINT32_MAX / (float)UINT32_MAX;
prev.f = low.f;
uint32_t nbMiss = 0;

for (uint32_t i = 1; i < UINT32_MAX; ++i) {

  v.f = (float)i / (float)UINT32_MAX;
  if (v.i > prev.i + 1)
    nbMiss += v.i - prev.i - 1;
  prev.i = v.i;

}

if (high.i > prev.i + 1)
  nbMiss += high.i - prev.i - 1;
uint32_t nbVal = high.i - low.i + 1;
println(
  "Nb missed values: %u/%u  %f%%",
  nbMiss, nbVal, (float)nbMiss / (float)nbVal);

It gives Nb missed values: 981467136/1065353217 92.1260%. Using RAND_MAX instead of UINT32_MAX makes things even worst of course: Nb missed values: 989855744/1065353217 92.9134%, and match the calculation of Pr Downey. The proportion of missed values is staggering! Doing the same for double would take around 2760 years on my machine, so I won't even try to parallelise it. But for the exact same reason we can expect the same problem.

This missing values were indeed one of my concern, but another one was about repeated values (when i/UINT32_MAX and (i+n)/UINT32_MAX,n>0 produce the same floating-point value). This can be checked with the code below:

union { float f; uint32_t i;} v, prev, low, high;
low.f = (float)0 / (float)RAND_MAX;
high.f = (float)RAND_MAX / (float)RAND_MAX;
prev.f = low.f;
uint32_t nbRepeat = 0;
uint32_t nbRepeatition = 0;

for (uint32_t i = 1; i < RAND_MAX; ++i) {

  v.f = (float)i / (float)RAND_MAX;

  if (v.i == prev.i) {
    ++nbRepeat;
    while (v.i == prev.i && i < RAND_MAX) {
      ++nbRepeatition;
      ++i;
      v.f = (float)i / (float)RAND_MAX;
    }
    if (i == RAND_MAX) --i;
  }
  
  prev.i = v.i;

}

uint32_t nbVal = high.i - low.i + 1;
println(
  "Nb repeated values: %u/%u  %f%%",
  nbRepeat, nbVal, (float)nbRepeat / (float)nbVal);
println(
  "Nb repeatition: %u/%u  %f%%",
  nbRepeatition, RAND_MAX, (float)nbRepeatition / (float)RAND_MAX);

The results are:

RAND_MAX:
Nb repeated values: 54525953/1065353217  5.1181%
Nb repeatition: 2071986174/2147483647  96.4844%
UINT32_MAX:
Nb repeated values: 62914561/1065353217  5.9055%
Nb repeatition: 4211081214/4294967295  98.0469%

In conclusion, the generated values using integer division are a very small and highly repeated subsets of the representable floating-point values. That's really far from satisfactory...

To avoid these two problems, I first thought of using the random sequence of bits directly as a double value. Of course this generates all possible floating point values but the distribution also get overwhemingly condensed near 0.0 where most of the representable values are. You also have to take care of the sign bit and scale it to bring it to [0.0, 1.0]. Pr. Downey gives a very nice solution to that problem in his paper: use a random mantissa and calculate the exponent in such a way that the probability for a given number to be choosen is proportional to the distance to his neighbours. His algorithm works on float values, while I was interesting in double values, so I've made a double version of it:

// Return one random bit
uint8_t GetOneRandomBit(void) {

  uint8_t randomBit;
  // Use static variables to produce 64 bits at once and use them one at
  // a time at each call of 
  static uint8_t nbRemainingBits = 0;
  static uint64_t randomBits;

  // If there are no more random bits available
  if (!nbRemainingBits) {

    // Produce 64 new random bits
    randomBits = $(&capyRand, getUInt64)();
    nbRemainingBits = 64;

  }

  // Get the next random bit and shift the remaining bits for the next call
  randomBit = randomBits & 1;
  randomBits = randomBits >> 1;
  nbRemainingBits--;
  return randomBit;

}

// Return a random double value in [0.0, 1.0]
// All possible values are generated and the distribution of values over
// [0.0, 1.0] is guaranteed to be uniform
// cf. https://allendowney.com/research/rand/downey07randfloat.pdf
double RandDowneyDouble(void) {

  // Get the exponent of the result
  union { double f; uint64_t i;} low, high, result;
  low.f = 0.0;
  high.f = 1.0;
  uint64_t low_exp = (low.i >> 52) & 0x07FF;
  uint64_t high_exp = (high.i >> 52) & 0x07FF;
  uint64_t exp = high_exp - 1;
  while (exp > low_exp && !GetOneRandomBit())
    exp--;

  // Get the mantissa of the result
  uint64_t mant = $(&capyRand, getUInt64)() & 0xFFFFFFFFFFFFF;
  if (mant == 0 && GetOneRandomBit())
    exp++;

  // Create the result and return it
  result.i = (exp << 52) | mant;
  return result.f;

}

Of course, it still passes my crappy test:

Better tests

Excited by Pr Downey's algorithm, I got a bit more motivated and tried again to find some more serious ways to check the generated numbers. I've found in particular this utility program called ent and developped by John Walker to check sequences of pseudo-random bytes. I've generated some data files as follow:

#include <LibCapy/capy.h>

// CapyRandom instance
CapyRandom capyRnd;

uint64_t TestRand(void) {
  return rand();
}

uint64_t TestCapy(void) {
  return $(&capyRnd, getUInt64)();
}

// Run the test given the pseudo-random generator 'rnd' and save the result
// in 'filename'
void Run(
  uint64_t (*rnd)(void),
  char const* const filedata,
  int nbByte) {

  // Open the stream for data recording
  FILE* streamData = safeFOpen(filedata, "wb");

  // Record the data
  loop (i, 500000) {
    uint64_t r = rnd();
    fwrite(&r, 1, nbByte, streamData);
  }

  // Close the data stream
  fclose(streamData);

}

// Main function
int main() {

  // Run the test with the standard rand function
  srand(time(NULL));
  Run(TestRand, "intRand.dat", sizeof(int));

  // Run the test with the CapyRandom class
  capyRnd = CapyRandomCreate(time(NULL));
  Run(TestCapy, "intCapy.dat", sizeof(uint64_t));
  CapyRandomDestruct(&capyRnd);

  return EXIT_SUCCESS;

}

The output of the ent utility on these data are given below.

Int - rand

Entropy = 7.954474 bits per byte.

Optimum compression would reduce the size
of this 2000000 byte file by 0 percent.

Chi square distribution for 2000000 samples is 124893.71, and randomly
would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 111.5584 (127.5 = random).
Monte Carlo value for Pi is 3.481023481 (error 10.80 percent).
Serial correlation coefficient is -0.049146 (totally uncorrelated = 0.0).

Int - Capy (xorshift)

Entropy = 7.999949 bits per byte.

Optimum compression would reduce the size
of this 4000000 byte file by 0 percent.

Chi square distribution for 4000000 samples is 284.84, and randomly
would exceed this value 9.64 percent of the times.

Arithmetic mean value of data bytes is 127.5447 (127.5 = random).
Monte Carlo value for Pi is 3.142833143 (error 0.04 percent).
Serial correlation coefficient is 0.000013 (totally uncorrelated = 0.0).

Check the page of the ent utility for the explanation of each value. I get the same poor results for the rand function, and much better results for xorshift. However, it is important to understand that the rand function returns a value in the range [0, RAND_MAX] as a signed int. Excluding the negative values implies that half the values of the high-order byte aren't used, inducing a bias. This is unfair to compare it to my xorshift implementation which generates all the possible values. Excluding the high-order byte in the data for rand (Run(TestRand, "intRand.dat", sizeof(int) - 1);, as I'm on a little endian architecture, i.e. the high order byte is the last byte), I get:

Int - rand (without high-order byte)

Entropy = 7.999868 bits per byte.

Optimum compression would reduce the size
of this 1500000 byte file by 0 percent.

Chi square distribution for 1500000 samples is 273.78, and randomly
would exceed this value 20.01 percent of the times.

Arithmetic mean value of data bytes is 127.4904 (127.5 = random).
Monte Carlo value for Pi is 3.134880000 (error 0.21 percent).
Serial correlation coefficient is -0.000128 (totally uncorrelated = 0.0).

Results are immediately much better. The exact results vary from one run to the other, so to get a better appreciation I've ran them a thousand times and counted how many times the percentage of the chi-squared test fall into the 10%-90% zone.

for i in `seq 1000`; do
  data;
  ~/Desktop/Random/ent intRand.dat | grep exceed | cut -d' ' -f 5 >> entRand.txt;
  sleep 1;
done;
awk '$0 >= 10.0 && $0 <= 90.0 { count++ } END { print count ? count : 0 }' entRand.txt

for i in `seq 1000`; do
  data;
  ~/Desktop/Random/ent intCapy.dat | grep exceed | cut -d' ' -f 5 >> entCapy.txt;
  sleep 1;
done;
awk '$0 >= 10.0 && $0 <= 90.0 { count++ } END { print count ? count : 0 }' entCapy.txt

The results were: 796 for rand without the high-order byte, 781 for xorshift, and ... 0 for rand with the high-order byte! That makes xorshift and rand as good as each other, with the big downside for rand generating numbers in a very small range of values compared to my 64 bits implementation of xorshift.

To evaluate the quality of the floating-point numbers generation, I reused the Monte Carlo calculation of Pi and compared the combinations of rand/xorshift and scaling/Downey.

#include <LibCapy/capy.h>

// Number of runs
#define NB_RUN 1000

// Number of measures in the Monte Carlo algorithm
#define NB_MEASURE 1000000

// Number of hits expected in the Monte Carlo algorithm
#define NB_HIT 785398   // (3141592 / 4)

// CapyRandom instance
CapyRandom capyRnd;

// Helper functions to commonalise the code in the Run() function
double TestRandScale(void) {
  return (double)rand() / (double)RAND_MAX;
}

uint8_t GetOneRandomBitRand(void) {
  uint8_t randomBit;
  static int8_t nbRemainingBits = 0;
  static int randomBits;
  if (!nbRemainingBits) {
    // Produce new random bits
    randomBits = rand();
    nbRemainingBits = 8 * (sizeof(int) - 1);
  }
  randomBit = randomBits & 1;
  randomBits = randomBits >> 1;
  nbRemainingBits--;
  return randomBit;
}

uint8_t GetOneRandomBitCapy(void) {
  return $(&capyRnd, getBool)();
}

double TestRandDowney(void) {

  union { double f; uint64_t i;} low, high, result;
  low.f = 0.0;
  high.f = 1.0;
  uint64_t low_exp = (low.i >> 52) & 0x07FF;
  uint64_t high_exp = (high.i >> 52) & 0x07FF;
  uint64_t exp = high_exp - 1;
  while (exp > low_exp && !GetOneRandomBitRand()) exp--;
  uint64_t mant = 0;
  loop (i, 51) {
    mant |= GetOneRandomBitRand();
    mant <<= 1;
  }
  mant |= GetOneRandomBitRand();
  if (mant == 0 && GetOneRandomBitRand()) exp++;
  result.i = (exp << 52) | mant;
  return result.f;

}

double TestCapyDowney(void) {

  return $(&capyRnd, getDouble)();

}

double TestCapyScale(void) {
  return $(&capyRnd, getUInt64)() / (double)UINT64_MAX;
}

// Calculate the value of PI using the Monte Carlo method
void Run(int64_t* err, double (*rnd)(void)) {

  loop (iMeasure, (uint64_t)NB_MEASURE) {

    double x = rnd();
    double y = rnd();
    double r = x * x + y * y;
    if (r <= 1.0) ++(*err);

  }

  *err -= NB_HIT;
  if (*err < 0) *err *= -1;

}

void Analyse(int64_t* err, char* generatorName) {

  int64_t sum = 0;
  loop (iRun, NB_RUN) sum += err[iRun];
  double avg = ((double)sum / (double)NB_RUN);
  double sigma = 0.0;
  loop (iRun, NB_RUN) sigma += pow(err[iRun] - avg, 2.0);
  sigma = sqrt(sigma / (double)NB_RUN);
  println("Mean/Standard deviation for %s is %lf/%lf", generatorName, avg, sigma);

}

// Main function
int main() {

  // Initialise the pseudo random generators
  srand(time(NULL));
  capyRnd = CapyRandomCreate(time(NULL));

  // Variable to memorise results of the runs
  int64_t errRandScale[NB_RUN] = {0};
  int64_t errRandDowney[NB_RUN] = {0};
  int64_t errCapyScale[NB_RUN] = {0};
  int64_t errCapyDowney[NB_RUN] = {0};

  // Loop on the runs
  loop (iRun, NB_RUN) {

    printf("%04u/%04u \r", iRun, NB_RUN);
    fflush(stdout);

    // Run the Monte Carlo algorithm for each type of generator
    Run(errRandScale + iRun, TestRandScale);
    Run(errRandDowney + iRun, TestRandDowney);
    Run(errCapyScale + iRun, TestCapyScale);
    Run(errCapyDowney + iRun, TestCapyDowney);

  }
  printf("\n");

  // Calculate the average error
  Analyse(errRandScale, "RandScale");
  Analyse(errCapyScale, "CapyScale");
  Analyse(errRandDowney, "RandDowney");
  Analyse(errCapyDowney, "CapyDowney");

  // Free memory
  CapyRandomDestruct(&capyRnd);

  return EXIT_SUCCESS;

}

The results were:

Mean/Standard deviation for RandScale is 331.281000/248.390040
Mean/Standard deviation for CapyScale is 312.847000/238.543324
Mean/Standard deviation for RandDowney is 329.357000/251.623921
Mean/Standard deviation for CapyDowney is 339.051000/252.565778

The value itself is not very important and vary slightly for each run, but the smaller the better. These results show no significant difference between the different algorithms. That's a bummer! Why is there no difference? In fact, in that test the missing values have no influence. Whatever the values, we only care of there ratio inside the circle/outside the circle. And thinking of it carefully, the repeated values too. Being repeated the values near 1.0 will be more often generated than the values near 0.0, but they equally represent a larger interval. Hence, the ratio is not affected by them neither.

What would be a better test then? It should be sensitive to these missing and repeated values. My thoughts went toward some visualisation of a chaotic system but I wasn't able to come up with anything useful. Or, using the Monte Carlo method to calculate something sensitive to values near 0.0, where most of the missing values are? Or, the test of a system for which the generated subset of all double input values by division woud be a poor design choice? Pr Downey himself leaves opened the question of finding a real application were his algorithm brings an advantage.

Performance

In term of execution time, generating 64 bits at once and using buffer gives a boost in performance which can be measured as follow:

#include <LibCapy/capy.h>

// Number of runs
#define NB_RUN 1000000

// CapyRandom instance
CapyRandom capyRnd;

uint8_t GetOneRandomBitRand(void) {
  uint8_t randomBit;
  static int8_t nbRemainingBits = 0;
  static int randomBits;
  if (!nbRemainingBits) {
    // Produce new random bits
    randomBits = rand();
    nbRemainingBits = 8 * (sizeof(int) - 1);
  }
  randomBit = randomBits & 1;
  randomBits = randomBits >> 1;
  nbRemainingBits--;
  return randomBit;
}

uint8_t GetOneRandomBitCapy(void) {
  return $(&capyRnd, getBool)();
}

double TestRandDowney(void) {

  union { double f; uint64_t i;} low, high, result;
  low.f = 0.0;
  high.f = 1.0;
  uint64_t low_exp = (low.i >> 52) & 0x07FF;
  uint64_t high_exp = (high.i >> 52) & 0x07FF;
  uint64_t exp = high_exp - 1;
  while (exp > low_exp && !GetOneRandomBitRand()) exp--;
  uint64_t mant = 0;
  loop (i, 51) {
    mant |= GetOneRandomBitRand();
    mant <<= 1;
  }
  mant |= GetOneRandomBitRand();
  if (mant == 0 && GetOneRandomBitRand()) exp++;
  result.i = (exp << 52) | mant;
  return result.f;

}

double TestCapyDowney(void) {
  return $(&capyRnd, getDouble)();
}

double TestCapyScale(void) {
  return $(&capyRnd, getUInt64)() / (double)UINT64_MAX;
}

// Main function
int main() {

  int ret = 0;

  // Initialise the pseudo random generators
  srand(time(NULL));
  capyRnd = CapyRandomCreate(time(NULL));

  // Calculate a bunch of random double using rand and xorshift and
  // measure time
  clock_t timeStartRand = clock();
  loop (i, NB_RUN) ret += TestRandDowney();
  clock_t timeEndRand = clock();
  double delayRand =
    (double)(timeEndRand - timeStartRand) / CLOCKS_PER_SEC;

  clock_t timeStartCapy = clock();
  loop (i, NB_RUN) ret += TestCapyDowney();
  clock_t timeEndCapy = clock();
  double delayCapy =
    (double)(timeEndCapy - timeStartCapy) / CLOCKS_PER_SEC;

  clock_t timeStartScale = clock();
  loop (i, NB_RUN) ret += TestCapyScale();
  clock_t timeEndScale = clock();
  double delayScale =
    (double)(timeEndScale - timeStartScale) / CLOCKS_PER_SEC;

  double ratio = delayRand / delayCapy;
  println("Using 64bits xorshift is %lf times faster than rand", ratio);
  ratio = delayScale / delayCapy;
  println("Using Downey algorithm is %lf times faster than scaling", ratio);

  // Free memory
  CapyRandomDestruct(&capyRnd);

  return ret;

}

which gives:

Using 64bits xorshift is 6.581148 times faster than rand
Using Downey algorithm is 0.569900 times faster than scaling

Here too, the value itself is not very important because it will vary depending on how many bits you use at once (one bit at a time, or one byte at a time, or two bytes, etc...). The point is that 64 bits xorshift is clearly faster than rand. For the comparison between the Downey algorithm and scaling, as one would expect a single integer division is faster than the bits manipulation in the Downey algorithm.

Conclusion

In conclusion, to generate integer numbers, rand and xorshift are as good (or bad depending on what you do with them) as each other, but an implementation of xorshift generating 64 bits values and buffering ensure better performance in term of execution time. Then, I decided to use 64 bits xorshift in LibCapy for integer generation. About floating-point numbers, even if I couldn't prove the advantage of Pr Downey's algorithm, I can't help but thinking that the richness and uniformity it provides will prove helpful one day. The cost in time is not terrible, and it looks so cool! Then I decided to use it in LibCapy for double generation as default, but added also the division method, in case I want to compare them again one day, or need a bit more of speed.

If you know/think about an application which could prove/disprove the advantage/disadvantage of Pr Downey's algorithm, please let me know, I'll be happy to try it, and if it does provide good result Pr Downey will surely be happy to here about it!

Edit on 2022/02/02: I came across that excellent video of Pr Squirrel Eiserloh speaching about random number generation. A definite must see.

Edit on 2022/12/06: I've learnt more about Permuted Congruential Generator described by Pr Melissa O'Neill in this paper. Given the simplicity of that algorithm and its performance it became the default one in LibCapy. I invite you to read her paper.

Edit on 2023/07/26: correction of typos in the percentages.

Edit on 2023/10/21: Another interesting article on corsix.org.

Edit on 2024/04/06: An analysis of the performance of Lemire's algorithm for generation of random integers here.

2021-12-12
in All, C programming,
130 views