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.
- 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...
- 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.
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.
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.
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.
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.
