This is why you should use those APIs that ask for the max, that's why they exist, and this is what's going on under the hood. But if you have to do it yourself. This is how. O.k. next, what if we need to random selection ...
-
-
That probably didn't make any sense. Here's a Wikipedia page that also won't make much sense: https://en.wikipedia.org/wiki/Normal_distribution … . It especially doesn't make sense that those totally differently looking lines are supposed to be "the same". That's ok though.
Show this thread -
It's ok because STATISTICS DOESN'T MAKE SENSE. They work really well, but if you think about them for too long and too deeply, you fall into a transcendent state. That's also how we know that statistics are pure science. Anyway, back to the topic ...
Show this thread -
A cool, though not common any more, way to generate normally distributed numbers is called the Box-Muller transform, https://en.wikipedia.org/wiki/Box–Muller_transform …, and it combines the "Just throw the bad crap away" (aka rejection sampling) and two-dimensional approaches we've seen already.
Show this thread -
With Box-Muller, we choose two random values, between -2^^31 and 2^^31 say, we plot them as x and y on a two dimensional plane. If (x,y) lies within the circle of radius size 2^^31, we keep the point, otherwise we go again. r is the distance from the origin to (x, y) squared.
Show this thread -
Here's a picture from Wikipedia, but basically we're throwing darts at a square and if they land in a circle we're good. It's amazing how much low-level stuff is dumb-as-rocks.pic.twitter.com/pQ97dvdD8x
Show this thread -
O.k. some parting thoughts before ending this thread. First, if you need to generate random numbers in constant time, or exotic distributions, get super deep into this stuff. There are seriously rough weeds to tackle.
Show this thread -
Second: if you find yourself building a whole RNG, it's really very hard, again, get deep in the weeds and learn about DRBGs, fork-safety, thread-safety, /dev/urandom, getrandom() and so on. Avoid if you can!
Show this thread -
Third: always use a secure RNG, your language or programming environment should have one. *Don't* ever seed an RNG yourself. One exception: for fuzz inputs and other tests, where you may want repeat deterministically for debugging. But DON'T LET IT LEAK INTO PRODUCTION.
Show this thread -
Another exception is games, where you may want to generate content and play based on a small seed value, BUT UNDERSTAND THAT THIS IS NOT SECURE.
Show this thread -
Last tip: always measure your little random functions with a histogram or whatever. I still code these wrong and have to check. Thanks for reading!
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.