Programming

29138 readers

180 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

why we never use modulus to produce random integer range (thelemmy.club)

submitted 2 months ago* (last edited 2 months ago) by bruh@thelemmy.club to c/programming@programming.dev

8 comments fedilink hide all child comments

I have been trying to understand how using modulus can be dangerous and can introduce nasty but into the software.

Here is an illustration: https://gist.github.com/anon7238593-create/5719c2ac8824650abbac4592ceee9408

in the notebook we can see that we used modulus to generate another random variable range which seems correct. you try to generate few number and they looks random but are they? no. here for sake of simplicity I have choose random range of 0-255 which I then convert to 0-100 range. here the probability that 0 comes is greater than having 100 because 101 doesn't evenly divide 255. there is a remainder of 53. which means the first 53 numbers are more likely to be chosen than the rest of the numbers which we can see in the graph.

you might be wondering why? it's rather simple. there are exactly 3 numbers in 0-255 that maps to number let's say 3 ( or any number less than or equal to 53 ). while there are only 2 numbers that maps to any number greater than 53. this affects their likeliness of being chosen.

which case this is fine?

only and only when the number of elements in bigger range is evenly divisible by the number of elements in smaller range. eg, ~~0-2 ( 3 elements ) 255 % 3 = 0~~ 0-4 ( 4 elements ) 256 % 4 = 0 in this case the likeliness of an element being chosen doesn't change.

hope this was useful :)

Edit:

off by one correction. thanks to @eleijeep@piefed.social

you are viewing a single comment's thread
view the rest of the comments

[–] Jenztsch@discuss.tchncs.de 1 points 2 months ago (1 children)

The last point is a correct method if you're accepting the theoretical risk that it could run forever. In case of an uniform distribution on the original range the probabilities converge to an uniform distribution on the smaller range. For non-uniform distributions you also get a distribution where the new probabilities are scaled sums of the original probabilities.

In reality you should probably introduce a maximum number of rerolls. In that case you have your issue again but you can easily calculate error estimates to choose a good tradeoff limit for your purposes.

[–] eleijeep@piefed.social 3 points 2 months ago

The probability of going for p repeats without hitting the lower end of the range is ((N - M) / N) ^ p where N is the size of the input range and M is the size of the largest integer multiple of the output range, which falls exponentially towards zero as p increases, so the chance of the process not terminating is zero.

With OP's example, with an input range of 256 and an output range of 202, this would mean the probability of making 10 unsuccessful attempts would be (54/256) ^ 10 = 0.00000017 or about 1 in 6 million. The probability of making 20 unsuccessful attempts would be 1 in 36 trillion, and so on.