27

I would like some sort of method to create a fairly long sequence of random numbers that I can flip through backwards and forwards. Like a machine with "next" and "previous" buttons, that will give you random numbers.

Something like 10-bit resolution (i.e. positive integers in a range from 0 to 1023) is enough, and a sequence of >100k numbers. It's for a simple game-type app, I don't need encryption-strength randomness or anything, but I want it to feel fairly random. I have a limited amount of memory available though, so I can't just generate a chunk of random data and go through it. I need to get the numbers in "interactive time" - I can easily spend a few ms thinking about the next number, but not comfortably much more than that. Eventually it will run on some sort of microcontroller, probably just an Arduino.

I could do it with a simple linear congruential generator (LCG). Going forwards is simple, to go backwards I'd have to cache the most recent numbers and store some points at intervals so I can recreate the sequence from there.

But maybe there IS some pseudo-random generator that allows you to go both backwards and forwards? It should be possible to hook up two linear feedback shift registers (LFSRs) to roll in different directions, no?

Or maybe I can just get by with garbling the index number using a hash function of some sort? I'm going to try that first.

Any other ideas?

Dan Froberg
  • 168
  • 8
PapaFreud
  • 3,636
  • 4
  • 34
  • 45

7 Answers7

29

I asked a very similar question at the tigsource forums.

Hashing

At least in games, a hash function could probably do what you want. You could do it like this

class ReversibleRNG {
    int x;
public:
    ReversibleRNG(int seed) : x(seed) {}
    int next(){return yourFavoriteHash(++x);}
    int prev(){return yourFavoriteHash(--x);}
};

Reversible linear congruential generator (lcg)

As multiple people have pointed out, an lcg is indeed reversible. In an lcg, the next state is computed like this:

x = (a * prevx + c) mod m

We can reorder this:

x ≡ a * prevx + c (mod m)
x - c ≡ a * prevx (mod m)

Since a and m are chosen to be relatively prime in an lcg, we can find the inverse by using the extended euclid's algorithm.

ainverse = extEuclid(a, m).x;
ainverse * (x - c) ≡ ainverse * a * prevx (mod m)
ainverse * (x - c) ≡ prevx (mod m)

Which means

prevx = ainverse * (x - c) mod m

If you choose m and a carefully, the algorithm can have a period of 2^64

Implementation

I did a header-only implementation of this algorithm in case anyone's interested.

bobbaluba
  • 3,584
  • 2
  • 31
  • 45
  • thank you @bobbaluba - I found this information very helpful. I'm not very good at math, so i tried to create a little dummy's guide to inverting modular functions - in case someone like me comes across this in the future: http://stackoverflow.com/questions/29569927/pseudo-random-distribution-which-guarantees-all-possible-permutations-of-value-s – Jonathan Basile Apr 13 '15 at 00:35
  • I have the impression that hashing sequential integers will lead to subrandom sequences. See https://stackoverflow.com/a/41728178/225186 – alfC Dec 08 '17 at 21:32
  • Thanks @bobbaluba for sharing the code. I just tried executing it and calculating a backwards step takes about 1.4 seconds compared to the practically instantaneous forwards step. Is that true or am I doing something wrong? I assume it's the extended Euclid's algorithm that takes that much processing time, is it? – Bill Jan 02 '21 at 00:02
  • @Bill: Maybe you're compiling with optimizations disabled? ainverse is the result of a constexpr function executed with constant parameters, most compilers should be smart enough to precompute that if optimization is enabled (I use g++ with -O2 in the examples, which makes in instantaneous for me). In any case, I bumped the requirement in the repo above to C++17, which allows constexpr variables, which I think should enforce the compile time computation also in debug mode. – bobbaluba Jan 03 '21 at 11:48
11

Using a really simple symmetric encryption algorithm is one of the easiest ways to do this. Each random number is formed by just encrypt the previous one with some fixed key and to go backwards you just decrypt.

You might look at the RC4 - Code at http://en.wikipedia.org/wiki/RC4. You could use a much smaller key schedule to get it to all fit on an arduino.

6

Encrypt the sequence 1, 2, 3, ... with any cipher and any key.

AES is available on just about every recent system out there, and is lightning fast.

BlueRaja - Danny Pflughoeft
  • 84,206
  • 33
  • 197
  • 283
3

Just reverse the order of the bits in an increasing sequence of integers. For example (with 8 bit resolution):

  • 0 <=> 0
  • 1 <=> 128
  • 2 <=> 64
  • 3 <=> 192
  • 4 <=> 32
  • etc

It's very easy to move forward and backward in the sequence, and is much much faster than invoking encryption or hash functions. It also has the benefit of generating the longest-possible sequence.

It's definitely not cryptographically-secure. Here's a scatter plot of the generated values (again with 8 bit resolution):

Scatter plot of "randomly" generated values

You can readily see patterns, although it might be "random" enough for you.

Matt Thomas
  • 5,279
  • 4
  • 27
  • 59
  • 1
    I don't have mathematical proof, but the resulting sequence looks like it is "subrandom". https://en.wikipedia.org/wiki/Low-discrepancy_sequence . Still can be useful in many applications. – alfC Dec 08 '17 at 06:59
  • 1
    @alfC My picture certainly looks like the [Hammersley set](https://en.wikipedia.org/wiki/Low-discrepancy_sequence#Hammersley_set), and [Wolfram says](http://mathworld.wolfram.com/HammersleyPointSet.html) you can generate that set by reversing the order of bits--I think that's the proof that you're right. Thanks for the link! – Matt Thomas Dec 08 '17 at 14:41
  • Exactly, in fact even if it were random, it would be more than reversible/bi-directional, it would be random sequence with "random access". I always wondered if such thing exists. That is skip N random number (in any diretion) in O(1). – alfC Dec 08 '17 at 19:03
  • @alfC If all you want is O(1) generation of the i'th number in a pseudorandom sequence, and you care nothing about its reversibility, then r(i, seed) = hash(i + seed) would do the trick; just pick your favorite hash function – Matt Thomas Dec 09 '17 at 18:09
  • Yes, but it is going to be subrandom, not random. I don't question that subrandom are random-access (O(1) jumps). The question I have is if there are random sequences with random-access. – alfC Dec 09 '17 at 19:01
  • @alfC I'm not understanding how hash(i + seed) produces a low-discrepancy sequence (with an appropriate hash function e.g. SHA256)? – Matt Thomas Dec 11 '17 at 12:42
  • Me neither. It is intuition, if random number could be generated that way it would not require any memory and that would be odd. If it were not subrandom it would be a bad hash. My conclusion is that hashes produce subrandom sequences when applied to programmatic sequences. – alfC Dec 11 '17 at 16:44
  • @alfC Allow me to restate more assertively: [A cryptographically secure hash of a counter might also act as a good CSPRNG in some cases](https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator#Designs_based_on_cryptographic_primitives) (CSPRNG = cryptographically-secure pseudorandom number generator). Note that it seems more common to use an encryption function instead of a hash function, but the principle is the same. – Matt Thomas Dec 11 '17 at 18:53
  • @alfC Perhaps this will help intuition: it's usually easy to refactor a function's internal state into a parameter. In other words, there's no magic that comes from a function having internal state. In the case of using a hash/encryption function to accomplish PRNG, all the state that is necessary is encapsulated in those two parameters ("i" and "seed"). Similarly, you could refactor your favorite PRNG function so that all state comes in as parameters and all descriptions of side-effects are returned from it. – Matt Thomas Dec 11 '17 at 19:13
  • @alfC As a toy example for my [previous comment](https://stackoverflow.com/questions/2911432/reversible-pseudo-random-sequence-generator/41728178?noredirect=1#comment82480760_41728178), consider this [Linear Congruential Generator](https://en.wikipedia.org/wiki/Linear_congruential_generator) (a PRNG): ```{int seed = 1337; int rand() { seed = (4321 * seed + 2345) % 53; return seed; }```. This function does the exact same thing: ```int rand(int seed) { return (4321 * seed + 2345) % 53; }``` – Matt Thomas Dec 11 '17 at 19:23
  • they will do the same thing if the seed is stored. Which means that there is no easy jumps. In other words, `for(int i = 0; i != 1000; ++i) print(rand());` and `for(int i = 0; i != 1000; ++i) print(rand(i));` will not do the same thing. I would claim that the first is random (i.e. quasi-random) and the second is subrandom. Do you agree? – alfC Dec 11 '17 at 20:12
  • @alfC See my reply in https://chat.stackoverflow.com/transcript/160976 (you have edit access) – Matt Thomas Dec 11 '17 at 23:37
  • `revINCrev( revDECrev(x) ) === x` – Dan Froberg Aug 12 '23 at 01:07
2

If a linear congruential generator is good enough use it. They are easily reversible. The point is that the reverse generator is also an LCG. LCGs can also skip in any direction (forward and backwards) very fast.

The details can be found in The Art of Computer Programming - Volume 2

In particular section 3.2.1 Page 10 Equations 6-8 of TAOCP and also exercise 5 give the desired results. In case you can not solve the exercise you can find solutions to it easily, e.g. here

Udo Klein
  • 6,784
  • 1
  • 36
  • 61
0

Although I agree with @BlueRaja that you should just use AES in "Counter mode", with a random or time-based start for your sequence, AES might not be available or feasible in your embedded situation.

I did find this interesting paper that discusses how to build a reversible PRNG; it's only 10 pages and has plenty of code samples. Give that at try if AES doesn't work for ya.

Randolpho
  • 55,384
  • 17
  • 145
  • 179
0

You can also go backwards with an LCG, it is just another LCG using the inverse of the multiplier modulo the modulus, together with a suitable increment.

For your small numbers you can just use brute force to search for the inverse, in general it can be computed with an extended GCD algorithm.

Unless your game is strictly for fun, with no stakes of whatever kind involved, I would choose something cryptographically secure, such as the AES approach suggested by others. LCGs and other linear random number generators cannot withstand an intelligent adversary.

starblue
  • 55,348
  • 14
  • 97
  • 151