Looks like they have a <random> compatible generator in their source. I wonder if they've made any proposals to ISOCPP.

Alvaro: I think I understand you correctly now, but to clarify, do you mean that for each number I want to generate, if I start with a different seed, it will give me a similar number, but if for each one, I generate say 10 numbers in a row, instead of just 1, then then 10th will seem more random?

Bacterius: Well that's something to take into consideration, but keep in mind that the efficiency of time and memory are both fairly significant.

To everyone: In a nutshell, I'm in an unusual circumstance in which each time I move on from one number to the next, I can't possibly store the previous value and then generate the next one from it (hence the necessity for using different seeds). I can however, make the generation of each number happen however I want, so for each single number, I can generate a sequence and keep the nth number if necessary (as long as it's not too slow).

But I need not only efficiency but also pseudo-randomness. It doesn't have to be actually random or cryptographically secure; it only needs to seem as random as possible (and as close to uniformly distributed as possible).

For each of your numbers, do you need a sequence of random numbers, or just a single random number (essentially hide the pattern in your initial set of numbers)?

For example in a game like minecraft, you might need to produce a random number given an x,y,z integer coordinate. For this, a hash function should produce a random-enough value, without needing to "warm up" a PRNG or whatever (since theyre designed to be random in a scenario like this, unlike prngs for which this would not be the primary use case)

Theres plenty to choose from, just search for an integer hash function.

If you do need a sequence of random numbers, hashing the seed first might produce better results than using sequential integers as seeds directly.

To everyone: In a nutshell, I'm in an unusual circumstance in which each time I move on from one number to the next, I can't possibly store the previous value and then generate the next one from it (hence the necessity for using different seeds). I can however, make the generation of each number happen however I want, so for each single number, I can generate a sequence and keep the nth number if necessary (as long as it's not too slow).

But I need not only efficiency but also pseudo-randomness. It doesn't have to be actually random or cryptographically secure; it only needs to seem as random as possible (and as close to uniformly distributed as possible).

So the main difference between a PRNG and an hash function is that the former needs to store some state (which is not necessarily just the previous random number), while the latter does not need to store any state. You're implying that you cannot store any state, hence the difficulty of using a traditional PRNG.

But how do you know what the seed is? It seems that somewhere, somehow, you're confident that you can store an incrementing integer value, so that you know that the first seed is 1, the next is 2, followed by 3, et cetera. However you store this state, you should probably be able to replace it with the state of a PRNG, and thereby be capable of generating a completely normal sequence of pseudo-random numbers.

Can you give us details about what puts you in the odd situation that you believe you're in? What specifically makes it impossible for you to get the second number in a random sequence after having already computed and used the first number? (Note that I'm asking for specifics because this sounds suspiciously like an XY problem: You want to do X, and think that Y is the best way to do so, and thus you ask about Y. But although there might be better ways to do X, we can't help you very well if we don't know what X is.)

Andy: Trust me, it's not what you're calling an XY problem. There's no way to get each number from a previous one, but there is a way to get an index of which number I want (so I could use the index as the seed).

For the sake of argument, if it makes it easier to imagine, assume that each number has an inherent index, but they must all be computed in parallel. Because of that, I can't get the result of one before the result of another. Basically they're being kept isolated.

In any case, people keep suggesting that I use one number to get the next one, and I'm telling you, that is absolutely NOT an option for this, sorry. I know it might make it easier, but it's not happening.

Waterlimon: Are you suggesting that I should hash each index, and then use the result of the hash as an input into a PRNG? That might work alright, but it's essentially like using 2 different PRNG algorithms in a row. I suppose that would make it more random than just using one though, so I guess it's a good idea, and I'll look into it.

Are you suggesting that I should hash each index, and then use the result of the hash as an input into a PRNG?

Only if you need to generate multiple numbers from a single seed (if you need just one, the hash alone should be enough). But yeah it should improve the randomness compared to just using sequential seeds, depending on PRNG. Of course if the prng itself already gives you good results, then it would be kind of unnecessary.