Permuted congruential generator

From HandWiki
Revision as of 15:57, 6 February 2024 by Smart bot editor (talk | contribs) (correction)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

A permuted congruential generator (PCG) is a pseudorandom number generation algorithm developed in 2014 by Dr. M.E. O'Neill which applies an output permutation function to improve the statistical properties of a modulo-2n linear congruential generator. It achieves excellent statistical performance[1][2][3][4] with small and fast code, and small state size.[5]

A PCG differs from a classical linear congruential generator (LCG) in three ways:

  • the LCG modulus and state is larger, usually twice the size of the desired output,
  • it uses a power-of-2 modulus, which results in a particularly efficient implementation with a full period generator and unbiased output bits, and
  • the state is not output directly, but rather the most significant bits of the state are used to select a bitwise rotation or shift which is applied to the state to produce the output.

It is the variable rotation which eliminates the problem of a short period in the low-order bits that power-of-2 LCGs suffer from.[5]:31–34

Variants

The PCG family includes a number of variants. The core LCG is defined for widths from 8 to 128 bits, although only 64 and 128 bits are recommended for practical use; smaller sizes are for statistical tests of the technique.

The additive constant in the LCG can be varied to produce different streams. The constant is an arbitrary odd integer,[6] so it does not need to be stored explicitly; the address of the state variable itself (with the low bit set) can be used.

There are several different output transformations defined. All perform well, but some have a larger margin than others.[5]:39 They are built from the following components:

  • RR: A random (input-dependent) rotation, with output half the size of input. Given a 2b-bit input word, the top b−1 bits are used for the rotate amount, the next-most-significant 2b−1 bits are rotated right and used as the output, and the low 2b−1+1−b bits are discarded.
  • RS: A random (input-dependent) shift, for cases where rotates are more expensive. Again, the output is half the size of the input. Beginning with a 2b-bit input word, the top b−3 bits are used for a shift amount, which is applied to the next-most-significant 2b−1+2b−3−1 bits, and the least significant 2b−1 bits of the result are output. The low 2b−1−2b−3b+4 bits are discarded.
  • XSH: An xorshift operation, x ^= x >> constant. The constant is chosen to be half of the bits not discarded by the next operation (rounded down).
  • XSL: A simplified version of xorshift, folding the value in half by XORing the high half into the low. The folded value is used for subsequent rotations.
  • RXS: An xorshift by a random (input-dependent) amount.
  • M: A multiply by a fixed constant.

These are combined into the following recommended output transformations, illustrated here in their most common sizes:

  • XSH-RR: An xorshift mixes some high-order bits down, then bits 63–59 select a rotate amount to be applied to bits 27–58.
    (64→32 bits) count = (int)(x >> 59); x ^= x >> 18; return rotr32((uint32_t)(x >> 27), count);.
  • XSH-RS: Similar, but fewer bits select the shift amount.
    (64→32 bits) count = (int)(x >> 61); x ^= x >> 22; return (uint32_t)(x >> (29 - count));.
  • XSL-RR: A simplified version of XSH-RR, this is optimized for 128-bit states implemented using two words on 64-bit machines.
    (128→64 bits) count = (int)(x >> 122); x64 = (uint64_t)(x ^ (x >> 64)); return rotr64(x64, count);
  • RXS-M-XS: The slowest and strongest output transformation when used to produce half-size output, this becomes the weakest when used as intended, to produce an output the same size as the state. For use when the state size must be limited to 32 or 64 bits.
    (32→32 bits) count=(int)(x >> 28); x ^= x >> (4 + count); x *= 277803737u; return x ^ (x >> 22);
    (64→64 bits) count=(int)(x >> 59); x ^= x >> (5 + count); x *= 12605985483714917081u; return x ^ (x >> 43);
  • XSL-RR-RR: Similar to the preceding, this turns 128 bits of state into 128 bits of output, when the application demands it.
    (128→128 bits) count = (int)(x >> 122); low64 = rotr64((uint64_t)(x ^ (x >> 64)), count); high64 = rotr64((uint64_t)(x >> 64), low64 & 63); return (uint128_t)high64 << 64 | low64;

Each step of these output transformations is either invertible (and thus one-to-one) or a truncation, so their composition maps the same fixed number of input states to each output value. This preserves the equidistribution of the underlying LCG.

Finally, if a cycle length longer than 2128 is required, the generator can be extended with an array of sub-generators. One is chosen (in rotation) to be added to the main generator's output, and every time the main generator's state reaches zero, the sub-generators are cycled in a pattern which provides a period exponential in the total state size.

Example code

The generator recommended for most users[5]:43 is PCG-XSH-RR with 64-bit state and 32-bit output. It can be implemented as:

#include <stdint.h>
static uint64_t       state      = 0x4d595df4d0f33173;		// Or something seed-dependent
static uint64_t const multiplier = 6364136223846793005u;
static uint64_t const increment  = 1442695040888963407u;	// Or an arbitrary odd constant

static uint32_t rotr32(uint32_t x, unsigned r)
{
	return x >> r | x << (-r & 31);
}

uint32_t pcg32(void)
{
	uint64_t x = state;
	unsigned count = (unsigned)(x >> 59);		// 59 = 64 - 5

	state = x * multiplier + increment;
	x ^= x >> 18;								// 18 = (64 - 27)/2
	return rotr32((uint32_t)(x >> 27), count);	// 27 = 32 - 5
}

void pcg32_init(uint64_t seed)
{
	state = seed + increment;
	(void)pcg32();
}

The generator applies the output transformation to the initial state rather than the final state in order to increase the available instruction-level parallelism to maximize performance on modern superscalar processors.[5]:43

A slightly faster version eliminates the increment, reducing the LCG to a multiplicative (Lehmer-style) generator with a period of only 262, and uses the weaker XSH-RS output function:

static uint64_t mcg_state = 0xcafef00dd15ea5e5u;	// Must be odd
static uint64_t const multiplier = 6364136223846793005u;

uint32_t pcg32_fast(void)
{
	uint64_t x = mcg_state;
	unsigned count = (unsigned)(x >> 61);	// 61 = 64 - 3

	mcg_state = x * multiplier;
	x ^= x >> 22;
	return (uint32_t)(x >> (22 + count));	// 22 = 32 - 3 - 7
}

void pcg32_fast_init(uint64_t seed)
{
	mcg_state = 2*seed + 1;
	(void)pcg32_fast();
}

The time saving is minimal, as the most expensive operation (the 64×64-bit multiply) remains, so the normal version is preferred except in extremis. Still, this faster version also passes statistical tests.[4]

When executing on a 32-bit processor, the 64×64-bit multiply must be implemented using three 32×32→64-bit multiply operations. To reduce that to two, there are 32-bit multipliers which perform almost as well as the 64-bit one, such as 0xf13283ad[6], 0xffffffff0e703b65 or 0xf2fc5985.

Comparison with other pseudorandom number generators

Melissa O'Neill proposes testing PRNGs by applying statistical tests to their reduced-size variants and determining the minimum number of internal state bits required to pass.[7] TestU01's BigCrush examines enough data to detect a period of 235, so even an ideal generator requires 36 bits of state to pass it. Some very poor generators can pass if given a large enough state;[8] passing despite a small state is a measure of an algorithm's quality, and shows how large a safety margin exists between that lower limit and the state size used in practical applications.

PCG-RXS-M-XS (with 32-bit output) passes BigCrush with 36 bits of state (the minimum possible), PCG-XSH-RR (pcg32() above) requires 39, and PCG-XSH-RS (pcg32_fast() above) requires 49 bits of state. For comparison, xorshift*, one of the best of the alternatives, requires 40 bits of state,[5]:19 and Mersenne twister fails despite 19937 bits of state.[9]

Prediction and seed-recovery

It has been shown that it is practically possible (with a large computation) to recover the seed of the pseudo-random generator given 512 consecutive output bytes.[10] This implies that it is practically possible to predict the rest of the pseudo-random stream given 512 bytes.

See also

References

  1. Lemire, Daniel (22 August 2017). "Testing non-cryptographic random number generators: my results". https://lemire.me/blog/2017/08/22/testing-non-cryptographic-random-number-generators-my-results/. Retrieved 2017-10-03. 
  2. Cook, John D. (7 July 2017). "Testing the PCG random number generator". https://www.johndcook.com/blog/2017/07/07/testing-the-pcg-random-number-generator/. Retrieved 2017-10-03. 
  3. Cook, John D. (14 August 2017). "Testing RNGs with PractRand". https://www.johndcook.com/blog/2017/08/14/testing-rngs-with-practrand/. Retrieved 2017-10-03. 
  4. 4.0 4.1 O'Neill, M.E. (29 July 2017). "PCG Passes PractRand". http://www.pcg-random.org/posts/pcg-passes-practrand.html. Retrieved 2017-11-03. 
  5. 5.0 5.1 5.2 5.3 5.4 5.5 Template:Cite tech report
  6. 6.0 6.1 O'Neill, M.E. (10 August 2017). "Critiquing PCG's streams (and SplitMix's too)". http://www.pcg-random.org/posts/critiquing-pcg-streams.html. Retrieved 2017-11-03. 
  7. O'Neill, M.E. (20 August 2017). "Visualizing the Heart of Some PRNGs". http://www.pcg-random.org/posts/visualizing-the-heart-of-some-prngs.html. Retrieved 2017-11-03. 
  8. O'Neill, M.E. (20 August 2017). "Too Big to Fail". http://www.pcg-random.org/posts/too-big-to-fail.html. Retrieved 2017-11-03. 
  9. L'Ecuyer, Pierre; Simard, Richard (August 2007). "TestU01: A C library for empirical testing of random number generators". ACM Transactions on Mathematical Software 33 (4): 22-1–22-40. doi:10.1145/1268776.1268777. http://www.iro.umontreal.ca/~lecuyer/myftp/papers/testu01.pdf. 
  10. Bouillaguet, Charles; Martinez, Florette; Sauvage, Julia (28 September 2020). "Practical seed-recovery for the PCG Pseudo-Random Number Generator". IACR Transactions on Symmetric Cryptology 2020 (3): 175–196. doi:10.13154/tosc.v2020.i3.175-196. 

External links