14

I'm working on a project, that relies assigning users random (nothing fancy, just uniformly) subsets of a larger set. Each user has a unique identifier from a set isomorphic to integers. There are two approaches to doing this, as far as I can see.

  1. Create a database junction table between users and keyed elements of the aforementioned larger set with some function once for each user. This can be somewhat impractical for my needs, so I would rather do...
  2. At run-time determine the subset by a similar function but use the unique user id as seed value, and just have the set in memory. Next time it's needed it's created again, from a larger set.

So my question is, if I use the .NET Random object to create the second function using user-id as a seed value, does Microsoft guarantee not to change the Random algorithm in the future? I.e. will all new Random(n)'s Next() sequences be the same forever on all machines?

Alternatively I could create my own random generator, and package it with my code. In fact, this is what I'll probably do, but I'm still curious to know the answer.

Gleno
  • 16,621
  • 12
  • 64
  • 85

4 Answers4

14

No, it is explicitly not guaranteed to be compatible across versions:

The implementation of the random number generator in the Random class is not guaranteed to remain the same across major versions of the .NET Framework. As a result, your application code should not assume that the same seed will result in the same pseudo-random sequence in different versions of the .NET Framework.

Mark Brackett
  • 84,552
  • 17
  • 108
  • 152
8

Microsoft cannot guarantee you that their code will never change as code improvement happens on identified vulnerabilities, issues or commodities-lack but, so far, the code hasn't changed and if you do not change frameworks on-course you should always have the same functionality.

So take it as if it won't change... but when you decide to upgrade your framework, make sure it still works the same.

PedroC88
  • 3,708
  • 7
  • 43
  • 77
  • 2
    Just before posting, I skimmed through that same MSDN article, and found nothing! Boy is my face red. :) Well, thank you very much for pointig it out. Although, I will not heed your advice, as I prefer to code and forget - I'll just implement my own uniform random integer generator. Shouldn't be too hard. – Gleno Jun 18 '11 at 06:10
  • 1
    Well, that's what I'm getting at. If I implement my own Random, it probably will just work until our monkey overlords change the meaning of integers. – Gleno Jun 18 '11 at 06:15
  • 3
    Have faith in the holy Integer type. It is... so... integer! – Miguel Angelo Jun 18 '11 at 06:21
4

You can use a very large prime number to generate a sequence of numbers that seems quite random, and it will always be the same sequence:

p = VeryLargePrimeNumber q = any number smaller than p (but not too small)

iteration is like this:

n = (n * q) % p

first n is the seed.

May be some cryptography method will be better suited... that is, each iteration you make a signature of the seed bits, and the next iteration you sign the previous signature, and so on.

Miguel Angelo
  • 23,796
  • 16
  • 59
  • 82
  • +1 That's what I first thought of doing. Simple and efficient. But I found a shaky MT19937 implementation, and after tinkering a bit with it... well, quite frankly it seems to work. Although I'll probably end up using something simpler like you suggest. – Gleno Jun 18 '11 at 06:44
  • I ended up using n = ((n * 1103515245) + 12345) & 0x7fffffff; which works well for my needs, and is ultra fast. :) – Gleno Jun 18 '11 at 06:58
0

Given that the context remains the same — that is, the underlying code is unchanged — seeding a pseudorandom number generator with a fixed value n should cause the generator to generate exactly the same pseudorandom sequence each time.

The vendor — in this case Microsoft — could warrant that the implementation of the PRSG will never change. However, they do not: why should they? They point of a PRNG is something resembling the generation of entropy.

If you're using a PRNG to generate repeatable, unique identifiers, you're barking up the wrong tree.

Nicholas Carey
  • 71,308
  • 16
  • 93
  • 135
  • I disagree. First - it doesn't follow that "something that resembles generation of entropy" should be allowed or not allowed to change. Then, secondly, given that the implementation does not change, then using a random number generator to produce predictable sequences is fair game. I explained my problem - I was going to use a random generator in the first place, why not re-use it instead of storing the results? That's what Von Neumann did! – Gleno Jun 18 '11 at 06:49
  • Actually makes a fun read => http://en.wikipedia.org/wiki/Pseudorandom_number_generator#Early_approaches – Gleno Jun 18 '11 at 06:50