You're wrong about the RNG, and if you've been reading this thread for a while I'm surprised you think like that
There is no pool of results.. it just simply returns a random number in a range in which the game asks for.
For example, it might ask for five random numbers between 0 and 120 because all five reels are 120 long...
I'd like to build on this a little if I may. First though, for the 'hot and cold' streaks, this is purely psychological. It's the way the human brain works. It remembers patterns, emotional responses etc, and these kinds of things happening elicit that, and so they are memorable. If you actually totalled up all your play, you'd probably be surprised how different it was to your interpretation.
Anyway, on to RNG. It's not entirely wrong to say that there is a pool, it depends on the implementation. I'll describe the implementation we had on the platform I used to run as an example. First some definitions. There are 2 types of RNG.
1. True RNG - Is truly random, but is also computationally slow and expensive
2. Pseudo RNG - Is not truly random, eventually it will become predictable. However it is very quick and computationally inexpensive.
An example of a Pseudo RNG is the Mersenne Twister (
). This implementation is a bit outdated now, but was what we used >10 years ago. It was quick and efficient, but had the drawback that if you knew 624 of the preceding numbers, you could predict the result. Slightly problematic for an RNG. So what we actually had was 1 True RNG and then something like 24 Mersenne Twisters. The True RNG would seed one of the twisters which would then generate ~500 numbers (less than the 624 needed for prediction) before seeding the next Twister. All of the twisters would generate 500 numbers, so you actually had a pool of about 12500 numbers generated.
When a game needed a number, it would request it. Whichever Twister was currently in the queue would return one of it's numbers. The next request would then get a number from the next twister and so on and so on until the pool was depleted. Then the true RNG would run and reseed everything and the whole process repeats.
This has the benefit of meaning you are not hitting the True RNG every single time, which as I said, is very slow, and would mean your slot spin times would be vastly increased. Also having the numbers already in a pool makes the request for a number very rapid.
The numbers themselves are taken into a game 'engine' (where the slot logic is) and converted into the required range (say 0-120) either via a mathematical process or by seeding a Pseudo RNG local to the game engine (again, this makes it computationally very quick, so it ensures the spin time is kept low).
As a collective system, this passes an audit and certification for true randomness, because at its heart, it has that True RNG.
Now, as for the pool effecting your 'hot or cold' streaks. It makes no difference for the following reasons
1. It is no different than asking the RNG for numbers one at a time. They are still random numbers
2. The random number generated by the RNG means different things to different games (in this scenario). If one game needs a number between 0-120 and another needs one between 0-200, the mathematical process that converts the core number into the required number produce different results in each case.
3. The pool is used by ALL players, so if there are 1000's of players all spinning slots, everyone is drawing from that pool all the time. There is no way you are using it alone so it cannot account for a cold or hot streak.
Now this is just a description of the implementation we used to use, but it's not uncommon due to the requirement for computational efficiency to keep spin times down. Hopefully it provides some insight though.