Factorio Forums

Selector Combinator can do random input, but we don't have enough different signals to turn that into a random number.

Can we get a "random number" option, or is there a design call to only do things you can't do otherwise?

It is already possible to build a pseudorandom number generator, see e.g. viewtopic.php?p=610098.

I second this. It would be really great if selector combinator had a [0,N) random option with N being an input signal or a constant. It could also support the Each wildcard giving one roll per input signal.

Illiander42 wrote: Sat Feb 08, 2025 2:00 ambut we don't have enough different signals to turn that into a random number.

Copy blueprint
You can chain multiple of these together to get arbitrarily random numbers from 0-99; 0-9,999; 0-999,999; or you can remove signals to get a smaller range. Or you can add "Quality" variants of each signal to expand the range even further while maintaining an even Numerical distribution.

If you want to dynamically set the Random range (example: between 10 and 90), use a Decider Combinator to "Filter" the signals according to their Values before feeding them to the Selector.

Good Luck!

eugenekay wrote: Thu Apr 03, 2025 9:44 pm You can chain multiple of these together to get arbitrarily random numbers from 0-99; 0-9,999; 0-999,999; or you can remove signals to get a smaller range. Or you can add "Quality" variants of each signal to expand the range even further while maintaining an even Numerical distribution.

There are two practical problems here:

• Cannot actually roll zero
• Cannot use a large signal as the input range

Suppose I want to get a random value in [0,N) where N can be large, say 10k or even 100k. Eventually we simply run out of signals to use.

If we do not have access to an N numbered dice, the next best thing is to find a list of rollable integers >1 that multiply to N, do a roll with each which totals N possible outcomes, and map each unique outcome to a value in [0,N).

For example
if N is exactly 1000 then our list could be [10, 10, 10] and we can use the formula R = random(10) * 100 + random(10) * 10 + random(10).
If N is exactly 1024 then our list could be [32, 32] and the formula R = random(32) * 32 + random(32).

However, if N is given by an input signal we are out of luck.

Gergely wrote: Sun May 18, 2025 12:17 pm There are two practical problems here:

• Cannot actually roll zero
• Cannot use a large signal as the input range

Yup, you're correct - this setup was built for a Forum Post to prove it could be done; I have not found a "Use" for this setup, so I did not spend any time at all checking for bugs....

You can trivially use an Arithmetic Combinator to transform a Random Value {1-N} into {0-m} by just subtracting 1 from the Output.

Getting a larger value can be done easily by extending the Constant Combinator's range 5X using Quality Signals.... you would need to setup another set of Virtual Signals to get a range all the way up to 1,024 - I think there are enough Intermediates to achieve this, I just don't feel like creating the Setup myself .

I would love to see a proper RNG implementation (Mersenne Twister maybe?) using Combinator primitives. Anybody up to the challenge?

eugenekay wrote: Sun May 18, 2025 2:34 pm I would love to see a proper RNG implementation (Mersenne Twister maybe?) using Combinator primitives. Anybody up to the challenge?

How would that compare with this one i made this one before the selector combinator using bit shifting and xor operation from seed :
I don't know how to test quality of randomness but i used it to generate music just fine.
Someone also made one with the least square method, if i recall the name properly, i can find it back if you're interested.

Copy blueprint

For simulations, and Factorio is a simulation, requirements for randomness of a pseudorandom number isn't that high. Important is equal distribution instead.
A common widely used efficient and sufficient algorithm for this is the Linear congruential generator.

Continuously create pseudorandom numbers from 0..N-1: Copy blueprint
1st combinator creates random number 0..2^32-1. Initial seed=0.
2nd combinator truncates sign bit
3rd combinator truncates to % N.

The "magic" numbers within (1013904223 as increment and 1664525 as multiplier) are result from mathematical research and best practice, for example from Knuth[1]. It results in a good period length.

[1] A reference to Knuth gives this post the illusion of competence. However, all this is the result of research with Copilot and the remains of my mathematical skills from computer science study from 30 years ago.

Tertius wrote: Tue May 20, 2025 9:43 am For simulations, and Factorio is a simulation, requirements for randomness of a pseudorandom number isn't that high. Important is equal distribution instead.

Can you indicate the theorical differences in distribution between the one you show and the other one based on
Linear shift back register. ?
What's the difference between the 2 notions ?

Tertius wrote: Tue May 20, 2025 9:43 am A common widely used efficient and sufficient algorithm for this is the Linear congruential generator.

Nice !

Tertius wrote: Tue May 20, 2025 9:43 am The "magic" numbers within (1013904223 as increment and 1664525 as multiplier) are result from mathematical research and best practice, for example from Knuth[1]. It results in a good period length.

[1] A reference to Knuth gives this post the illusion of competence. However, all this is the result of research with Copilot and the remains of my mathematical skills from computer science study from 30 years ago.

Hey Mr Knuth also appeared in videos much easier to understand than the papers where his name shows up ! Pretty sure this mention an algorithm to generate pseudo random train network accessible for everyone https://www.youtube.com/watch?v=v678Em6qyzk

mmmPI wrote: Tue May 20, 2025 10:58 am Can you indicate the theorical differences in distribution between the one you show and the other one based on
Linear shift back register. ?
What's the difference between the 2 notions ?

Unfortunately, that's beyond my current mathematical knowledge. In this script, skip the text and scroll down to the dot graphics visualizing the distribution for the lcg:
https://www.mathematik.uni-ulm.de/stoch ... ode26.html
If there is a dense cloud of dots somewhere and parts with thinner distribution, the overall distribution of the generator is bad. Ideally, there is a uniform equally distributed image. You also see many positions (numbers) will never be the result of the generator. The more dots, the longer the period, the more different numbers are returned. Ideally, the graph is completely black. The one with a=65 and c=1 looks very distributed and dense.

For the lfsr, I didn't find such graph. The lfsr is slightly younger (but not much), however this doesn't mean it results in better distribution or period.
I guess the major difference between the two is due to practical reasons.
The lcg is an extremely simple algorithm and provides very good distribution and period with proper increment and multiplier, however it contains a multiplication. A very expensive complex operation at the time that includes a loop and needs a register for intermediate results. The lfsr works with bit shift and xor operation instead, which are more simple to implement in hardware and are just logic operations without a loop.

In Factorio, a multiplication is as simple and atomic as any other arithmetic operation, so this doesn't apply to us.

Tertius wrote: Tue May 20, 2025 11:33 am Unfortunately, that's beyond my current mathematical knowledge. In this script, skip the text and scroll down to the dot graphics visualizing the distribution for the lcg:

That's what you say but your explanations are helpful.

I meant in one part what is the difference between "equal distribution" and "randomness of pseudorandom generator", because i said "quality of the randomness" but i though you corrected with what i imagine is the proper term. ( the 2 notions the more theorical differences )

I also meant what is the difference between the 2 setups in the other question, but i wasn't sure i understood your first remark and thought it may be necessary to understand the answer i could receive in the 2nd question which i understand has less precise answer, because in practice my contraption may have additional flaws or quirks that makes it very hard to compare with the another one just from looking at it.

Now that's a lot of german x), but the picture and your explanations i can understand or at least make sense of some of the things, it reminded me some toying around.

Tertius wrote: Tue May 20, 2025 11:33 am In Factorio, a multiplication is as simple and atomic as any other arithmetic operation, so this doesn't apply to us.

That makes total sense. I had searched on internet for "quick" or "cheap" or "fast" RNG, when attempting to make the other one, and i thought i had identified one that was very minimal, ( i could understand it ! ) but yours is so lite ! making it even easier to embed everywhere !

I wonder if the smaller number of combinator would make it more efficient, even if you are using couple hundred thousand of those and you try to optimize for how the factorio game deals with the combinator logic in behind players eyes

Tertius wrote: Tue May 20, 2025 9:43 am 1st combinator creates random number 0..2^32-1. Initial seed=0.
2nd combinator truncates sign bit
3rd combinator truncates to % N.

LCGs are a good default when you don't need security and want it to be fast and simple, yeah. However, note that using % N for the final step introduces the "modulo bias" - the resulting numbers are only uniformly distributed if N is a power of two, and for other values of N you are more likely to get the lower values in the range. How big the bias is depends on how far N is from the previous power of two and how big N is; for small values it's probably not going to be noticable unless you generate many values and plot the results.

Getting uniformly distributed integers in an arbitrary range when starting with an integer value for entropy is quite annoying and not constant-time (you just throw away any values that are out of range and try again; taking it modulo the next highest power of two first reduces the *average* number of tries to <2 but is still unbounded), so implementing that in combinators is probably more trouble than it's worth unless you really need a perfectly uniform distribution for some reason. But, in case anyone cares, just pointing it out

edit: originally said "divide by the next highest power of two" which is backwards; fixed to modulo

torne wrote: Tue May 20, 2025 6:40 pm LCGs are a good default when you don't need security and want it to be fast and simple, yeah. However, note that using % N for the final step introduces the "modulo bias" - the resulting numbers are only uniformly distributed if N is a power of two, and for other values of N you are more likely to get the lower values in the range. How big the bias is depends on how far N is from the previous power of two and how big N is; for small values it's probably not going to be noticable unless you generate many values and plot the results.

If i understand properly, you talk only about the last step in the logic, the one where a very large number in the order of magnitude of the seed// 32 bits is made into one in a range that would be the user end result ? by doing %N operation on it, if 0-N is the desired range for RNG in user's mind ?

This would be the same for both posted setup i think; because that's also the math i used to cap the randomly generated number in a range, that's why i'm curious, and don't want to miss a nuance. I don't understand when using %8 or %10 would yield a result that is "not correct" when using %2 would. like could you pick a few number to illustrate the modulo bias ( for dummy ? ).

I had thought of machine to test the randomness "visually" some time ago 112735 , you could potentially "see" the pattern in which bits are on or off,( test thought for LSBR) i was reminded of that by the picture from Tertius' link, i would like to make another one to specifically test for "the modulo bias" in a way that would validate my understanding.

I had thought of trying to generate many numbers from 1 to 10 ( using %10 as the last step) and using 10 "counter" made of lamps column in vertical lane where a lamp would lit every 10 or 100 or 1000 times its digit was randomly picked, supposedly to test the uniformity of the distribution, would that be a correct test ? In that it could highlight discrepancies between digits based on wether or not "N" is a power of 2 ?

That may be "beyond my current mathematical understanding" but it seem that just test "frequencies of occurences" and is not the same as "uniformly distributed" in that if you just do x+1 => x, it would "pass" the test and show every digit being choosen the same amount of time on average, like "fair dice", but it would be "bad randomness" , because of strong corellation between a number and the next one ? Was that what i'd missed earlier ?

torne wrote: Tue May 20, 2025 6:40 pm Getting uniformly distributed integers in an arbitrary range when starting with an integer value for entropy is quite annoying and not constant-time (you just throw away any values that are out of range and try again; taking it modulo the next highest power of two first reduces the *average* number of tries to <2 but is still unbounded), so implementing that in combinators is probably more trouble than it's worth unless you really need a perfectly uniform distribution for some reason. But, in case anyone cares, just pointing it out

I care ! this is a suggestion for random number on selector combinator, i want to understand what's possible to do in game and what's not currently, what are the shortcomings of the current methods in theory and in practice and when do they work well.

Time-constant is important for circuit ! That's why the idea of doing % at the end is felt so appealing, you don't "throw away" any value, you just "remove" the extra bits that were generated randomly that you don't want to look at "ideally". With the modulo 10 to keep only the last digit, but extended to arbitrary range. That was my reasonning, so if i made a mistake i want to understand it, that's another reason i care !

I found there is a gap between documentation available about that from fields like crypto security and my understanding, which require less abstract example like things in casino or even better "in factorio" , i praise game design that can be support for learning, stuff like "i need to find the proper math to this problem, and then you go to the rabbit hole" so if you can help or point to some ressources, i'd be digging ! and i imagine anyone who cares could too

Don't put too much effort into a "better" random number generator. Simply use the lcg. It's really random enough for almost everything except for cryptographic uses. Visual C/C++ for example uses it for the stdlib rand() function. Even glibc rand() uses the lcg if the internal state buffer is initialized with less than 32 bytes with initstate().

Tertius wrote: Thu May 22, 2025 3:49 pm Don't put too much effort into a "better" random number generator. Simply use the lcg. It's really random enough for almost everything except for cryptographic uses. Visual C/C++ for example uses it for the stdlib rand() function. Even glibc rand() uses the lcg if the internal state buffer is initialized with less than 32 bytes with initstate().

What do you call better ?

I think what torne mentionned is not about "how good is the randomness in the 32 bit number ", but rather, "are you not introducing a bias after the "good randomness ?".

According to this article : https://research.kudelskisecurity.com/2 ... -avoid-it/ it look like the pictures that illustrate the distribution is what i thought would measure frequency of number occurences. it clearly shows a discrepancies that look like similar to what torne mentionned , a bias toward the lower part of the range, and intuitively, they explain it as : "when you try to cut a large piece of rope in equal segment following an already existing smaller measurement, you will end up with a shorter end, unless the smaller piece's lengh was a multiple of the longer one to begin with".

I was doing research ! And it look like the discrepencies between the "favoured value" and "not favoured" can be quite significant, almost 50% as much occurences of 1 2 3 vs 4 5 6 in a dice is really bad dice, even if the numbers are not correlated to each other and you can't see pattern.

Tertius wrote: Tue May 20, 2025 9:43 am 3rd combinator truncates to % N.

This would be the problematic step, not the the lcg itself from what i understand from the article, but i'm not sure i'm getting it because to me if you do modulo 10 on a random number, you get a random digit , there is no bias, i don't think this is wrong, i think it's more subtle, it depend on the relation between the numbers when it's not "10", i'm not sure yet what i should test but i welcome hypothesis.

I think it's possible to use the lcg or even the lsbr just fine, i mean i did ! but in my purposes i may have missed some things on the distribution or math that would proove problematic if i share those RNG and recommend their use instead of one based on the system eugenekay mentionned.

That article talks about cryptography, where the bias is definitely significant. But for our purposes within Factorio, where at most 60 random numbers per second can be generated, and we usually just want to pick some value from a variety of values, that's not significant.

The script from the article, with modulo 6, results in this: The bias is between 3 and 4, and it's very small.
It gets more significant the greater the divisor gets. In that article, the biggest random number is 255. With our divisor 6 it's barely visible, with 10 it's visible, with 107 quite significant. In our case, the biggest random number is 2^31-1. We will probably create with divisors up to 1000 - that's still small compared to the biggest numbers.

Tertius wrote: Thu May 22, 2025 5:37 pm That article talks about cryptography, where the bias is definitely significant. But for our purposes within Factorio, where at most 60 random numbers per second can be generated, and we usually just want to pick some value from a variety of values, that's not significant.

I disagree, for my purpose of generating music notes , that's fine, but if your purpose is to use a RNG to select between 6 receipe thinking the law of large numbers will take care of the ratio for you, then you could be in a bad a time because there will be material from receipe 1 2 3 4 in excess over 5 and 6 and it will build up.

Tertius wrote: Thu May 22, 2025 5:37 pm It gets more significant the greater the divisor gets. In that article, the biggest random number is 255. With our divisor 6 it's barely visible, with 10 it's visible, with 107 quite significant. In our case, the biggest random number is 2^31-1. We will probably create with divisors up to 1000 - that's still small compared to the biggest numbers.

In that article in the second part after they explain why it's important in cryptography ( which is not our purpose i agree ) , but they also mention ways and bound condition to avoid bias that i believe is important to understand when using those RNG "with the % step" at the end. Although i may be wrong and i'm not sure i understand it, i just "think" it would be useful to explain alongside the RNGs.

With "10" it's somewhat easier to understand intuitively i found when it work and when not, if you have a random number between 0 and 100 and you try to remap between 0 and 10 it works, each digit is remapped with the same amount of original potential input

But if you have a random number between 0 and 105. Then it's like for 0 and 100, but with 101 102 103 104 and 105 that will be transformed into 1 2 3 4 5 and will cause those number to occur more frequently than if there was also 106 107 108 109 110. and the range was from 0 and 110.

It's one extra copy of 1 2 3 4 5 , but there's already 10 set of "1 2 3 4 5 6 7 8 9 0" if that make sense, if it was 1000005 the biais would be even smaller. with 2^31 even smalller would take billions of attempt to identifiy the bias with certainty, or as long as you divide by a small number, the build up for the "extra annoying material" could take years or more ( 60 roll per second will require many occurence for the bias to be significant). I'm seeing it the other way as you explained i think, but that woud have gone unnoticed otherwise.

in my head it was always working with modulo 10 because i was always picking up my random number from 0 to 100 even automated test ... 1000 or 10000 but never 128 or 1024 as in the game duuuuuuh, when you don't know what to test .... x)

" if the number is random its last digit too" is not correct thinking, if the random number is equally distributed between 1 and 25, then its last digit is between 1 to 5 much more often than between 6 and 9, i think it's the easiest way to explain x).

Now i feel i understand better when i should or could use which kind of RNG ( why it works) ! I think it's doable in game, but quite tricky, i can understand why people would want a selector combinator allowing to avoid this kind of reasonning, but i also feel it would be a shame to avoid digging into this when using a RNG yourself as a player.

mmmPI wrote: Thu May 22, 2025 6:27 pm but if your purpose is to use a RNG to select between 6 receipe thinking the law of large numbers will take care of the ratio for you, then you could be in a bad a time because there will be material from receipe 1 2 3 4 in excess over 5 and 6 and it will build up.

Ok, that's a strong argument. However, I wouldn't rely on a rng alone for that, because of such possible bias. I would always add some kind of active feedback to delay the producer of surplus material, so it isn't surplus any more. This is robust and error-resistant. I rather create a robust factory as a whole than to fiddle with every tiny inconsistency on its own. If the factory is actively balanced, it would also balance out any other mysterious sources of inconsistency, for example if some inserter is stalled from time to time.

Tertius wrote: Thu May 22, 2025 6:45 pm Ok, that's a strong argument. However, I wouldn't rely on a rng alone for that, because of such possible bias. I would always add some kind of active feedback to delay the producer of surplus material, so it isn't surplus any more. This is robust and error-resistant. I rather create a robust factory as a whole than to fiddle with every tiny inconsistency on its own. If the factory is actively balanced, it would also balance out any other mysterious sources of inconsistency, for example if some inserter is stalled from time to time.

That make sense to have extra safety for sure ! but you could also try different math methods as safety or hope to have identified properly the bias and its cause in order to rely on a RNG x) !

If you make 2 RNG, each of them producing number A and B with a bias toward 12345 over 67890, maybe you can use one with 10-A and the other one as regular B and pick one or the other using a third rng that uses %2 since there is no modulo bias there ? or similar idea.

Another way would be to calculate how much time it would take for the bias to accumulate in a significant way, as you said in the context of factorio, 60 roll only per second, you may very well end up with a machine that will clog in 20000 years with a 80% probability or something that means not a problem in a real game.

When the number is only 255 and modulo used is 107 as in the article's example, it's typically the case where it would fail fast and that need to be identified but i have no idea why player would use the RNG, it was only a conjecture.

mmmPI wrote: Thu May 22, 2025 12:50 pm If i understand properly, you talk only about the last step in the logic, the one where a very large number in the order of magnitude of the seed// 32 bits is made into one in a range that would be the user end result ? by doing %N operation on it, if 0-N is the desired range for RNG in user's mind ?

This would be the same for both posted setup i think; because that's also the math i used to cap the randomly generated number in a range, that's why i'm curious, and don't want to miss a nuance. I don't understand when using %8 or %10 would yield a result that is "not correct" when using %2 would. like could you pick a few number to illustrate the modulo bias ( for dummy ? ).

Yes, this is what I meant, and it seems like you understand that part pretty well from your own research now. Usually when generating random numbers on a computer we do think about it as two separate steps like this: getting "some randomness" from somewhere (e.g. our 32 bit output from the LCG), and then using that randomness to pick a specific value from the distribution that we actually want.

The second step isn't usually considered part of the random number generator itself because the same algorithms can be used with any source of randomness (as you mention here, we can do the same thing with the LFSR or the LCG, it doesn't matter) - this step is "just math", but if done incorrectly it can introduce new biases that weren't present in the original randomness, like the modulo bias.

%8 is fine though here, because 8 is a power of two: it's 2^3, and so divides evenly into our original 32-bit random value. But, yeah, if we want a value between 0 and 9, just using %10 is going to be slightly more likely to generate 0-5 and slightly less likely to generate 6-9.

We can get a uniformly distributed random value between 0 and 9 by first taking the value %16, which *does* give us a uniform random distribution between 0 and 15 since 16 is a power of two, and then if the result is 10-15 we just throw it away and start over. This will usually only take a couple of tries, but it might take longer if we get unlucky, and it's quite inconvenient to have a variable-time algorithm like this when using Factorio combinators, so unless we *really* care about the result being perfectly uniform we probably wouldn't bother.

That may be "beyond my current mathematical understanding" but it seem that just test "frequencies of occurences" and is not the same as "uniformly distributed" in that if you just do x+1 => x, it would "pass" the test and show every digit being choosen the same amount of time on average, like "fair dice", but it would be "bad randomness" , because of strong corellation between a number and the next one ? Was that what i'd missed earlier ?

You are correct that just testing how often each value occurs doesn't tell you that it is really random, but if the values *don't* occur equally often then it's definitely *not* a uniform random distribution - having them occur equally often is necessary but not sufficient. Correlations between the values in a supposedly-random sequence, as you say, is another important property, and this is where things get extremely complicated, because there's a pretty-much infinite number of possible ways that the values might be correlated with each other, and therefore also a pretty-much infinite number of tests we could try.

Your example here suggests one simple test: we could take the *difference* between consecutive values in the sequence and see if the differences look uniformly distributed. The "x+1 => x" generator would fail this test very quickly, since the difference would always be 1 - we wouldn't need much data to conclude that there's a correlation. But, other generators might pass this test but still fail other more complex tests. Which tests are most useful is a whole complex area of math that's beyond my expertise - I'm just a computer scientist, not a mathematician

There's also a separate property here that's important for security/cryptography/other cases where you have an adversary, though, which is "given some numbers from the random sequence, how easy is it to predict future values in the sequence". The LCG discussed here is terrible at this: if we know the specific parameters being used (the multiplicand and addend) then all we need to know is any one value from the sequence, and then we can predict *all* future values perfectly. And, since the algorithm here is a common, standard one, and the parameters used are well-known ones, we can easily guess all of this: if we have two values from the sequence, we can very quickly try a bunch of different common PRNG algorithms/parameters and see if any of them do in fact turn the first value into the second value.