# What is the application of pseudorandomness in astrophysics?

What are the advantages of using pseudorandom numbers in Monte Carlo simulation instead of random numbers? What are other applications of pseudorandomness in astrophysics? Many thanks.

• There are two questions here. The first is a general Software Engineering one "What are the benefits of pseudorandom numbers". The second is also really a general question "what are applications of random numbers in science". Have you looked at wikipeidia : en.wikipedia.org/wiki/Applications_of_randomness#Science Commented May 22, 2021 at 5:50
• "What are the advantages of using pseudorandom numbers in Monte Carlo simulation instead of random numbers?": the speed. A PRNG is usually very much faster than (true) random number generators. You usually use a (slow) TRNG to seed a very fast and good PRNG like SFMT. Commented May 22, 2021 at 8:42
• A computer cannot simulate a truly random number, ever. Hence for all of physics, including astrophysics, when we need random numbers, we have to use pseudorandom numbers. Truly random numbers can be generated by observations of e.g. cosmic ray radiation or nuclear decay, but they don't exist in sufficient quantities on demand. Commented May 22, 2021 at 13:46
• @AtmosphericPrisonEscape "A computer cannot simulate a truly random number, ever." Are you sure? en.wikipedia.org/wiki/Hardware_random_number_generator Commented May 23, 2021 at 18:59
• @LawnmowerMan: A "computer" as in "Turing-machine solving problems using deterministic algorithms". Some piece of hardware accessing quantum effects wouldn't count to that, would it. Commented May 23, 2021 at 19:25

The primary advantage of pseudorandom numbers is speed (as Cristiano mentioned) and convenience: they're what are available in almost any software package or library, whereas true random number generators are not. As long as you use a pseudorandom number generator (PRNG) with good statistical qualities and are not worrying about true cryptographic randomness, this is perfectly acceptable.

In addition to Monte Carlo simulations, pseudorandom number are used for many different applications, including all sorts of physical simulations (cosmological, stellar evolution, planet formation, etc.), statistical analyses (bootstrap resampling), initial conditions for fits, updating parameters in genetic algorithms, sample selection, etc.

A personal example: I've worked on two different studies where we were making classifications of different aspects of galaxies, based on their individual isophote plots or radial surface-brightness profiles. Rather than worrying about the possibility of subtle biases based on possible knowledge of individual galaxies ("Oh, it's NGC 1097, I'd expect that galaxy to be..." or "Well, the list is alphabetically ordered, so the middle galaxies will have NGC prefixes, and those will mostly be really luminous galaxies, so..."), we set up a blind analysis system, where the galaxies were presented to us in a random order, without names (with the actual identifications automatically recorded where we couldn't see them until the whole thing was over). The randomness of the order was, of course, really pseudorandom order.

This is how things like Galaxy Zoo work, for example: the individual galaxies that citizen scientists classify are (pseudo)randomly selected. (And for one of the projects I mentioned above [Kruk et al. 2019], we set up the classification process using the "Zooniverse" framework that Galaxy Zoo developed).

A separate advantage is that if you save the number used as the seed for the pseudorandom number generator, you can use that to regenerate the exact set of pseudorandom numbers used in the analysis/simulation/whatever, which can be very useful for debugging purposes, and also for allowing others to replicate your results. (E.g., you run some kind of relatively short/simple simulation, and derive some results and figures from that. How can someone else trust that your results and figures accurately represent the simulation? Provide them with the code and the PRNG seed, and then can generate the same simulated/random-sampling results and check. Plus, they can vary the seed and make sure you didn't cheat -- or fool yourself -- by reporting atypical results. Here's a Github site for a recent paper of mine that includes both the code for a survey simulation and the seed number I used for the figure in the paper.)

• Unless one uses the exact same make of computer as did you, the exact same version of the operating system as did you, the exact same compiler as did you, with the exact same compilation options, etc., as did you, that person will not be able to reproduce your results. At least not exactly. And once things differ by one bit, the deviations in a model of a chaotic system tend to grow exponentially. Commented May 23, 2021 at 4:54
• @DavidHammen When people talk about "reproducibility/replicability", they're not talking about some (absurd) "down-near-the-level-of-machine-precision" reproduction, as you're suggesting. If I report some magnitude etimate as "10.014", then the fact that your machine might produce 10.0142292801 and mine might get 10.0142292803 from the same initial data is undetectable and irrelevant. Commented May 23, 2021 at 11:09
• Most "simulations" in the general sense don't involve chaotic dynamics. Even those that do would require that your calculation starts in a chaotic region of the phase space, and that you carry out out long enough -- and that the Lyapunov exponent is large enough -- for an initial bit-level difference to grow to a meaningful difference in the reported values. (And in any case this is irrelvant to the question of "pseudorandom vs truly random numbers".) Commented May 23, 2021 at 11:14
• When creating simulated data, it can be quite handy to use the reproducibility of PR numbers. When testing an instrument design or a data reduction process, it's useful to be able to rerun tests with the same input data. With PR numbers you can have realistic randomness in your data along with the ability to recreate it from a seed, avoiding the need to save huge files. Commented May 23, 2021 at 12:40
• Thank you so much Commented May 25, 2021 at 6:27

What are the advantages of using pseudorandom numbers in Monte Carlo simulation instead of random numbers?

Where are you going to get those true random numbers? Even reading from /dev/random has documented issues with not being truly random, and even worse, It. Is. Slow. (Or it would be slow if it was implemented as originally conceived. To make it faster, most implementations of /dev/random deviate from the concept of blocking until it builds up sufficient entropy. Even then, it is still slow. It's just not all-caps SLOW.) Except for computers outfitted with specialized hardware devices designed to provide lots of entropy, you are not going to get true random numbers on a computer.

Suppose you are asked to build a Monte Carlo-based simulation of a galaxy for your masters degree thesis. (This is not PhD-level, at least not anymore.) You most likely will not get your thesis approved if you use rand() as the basis for your randomness. Many implementations of rand are worse than bad. On the other hand, you also most likely will not get your thesis approved if you use /dev/random, or even a cryptographically-secure random number generator, as the basis for your randomness. /dev/random, if properly implemented, is SLOW. A cryptographically-secure random number generator (which theoretically predictable) is merely slow. Your simulation needs something that is fast. Just as lousy (e.g., rand()) is not good enough, something that is slow also is not good enough. Physics-based Monter-Carlo simulations need something that is fast, and more importantly, that passes most if not all tests of "randomness".

On the third hand, despite being over 20 years old, no one will blink an eye if you use Mersenne Twister. Despite its age, and despite that better techniques that are equally fast (maybe even faster) have been developed since, MT remains more than good enough from the perspective of randomness tests. MT is the current state of the practice technique for generating reasonably good random numbers.

This isn't astrophysics, but suppose you are part of a team that develops a simulation of a lander that takes humans to the surface of the Moon. Suppose your simulation shows that 9900 out of a 10000 simulation runs has the vehicle landing successfully, but 100 crashed into the surface. There should only have been 27 or so crashes out of 10000 runs per NASA's three sigma rules. You had better investigate those hundred cases, and fix the underlying problems. Deterministic behavior is very, very helpful in this regard.

Getting back to astrophysics, deterministic behavior of a pseudo random number generator helps developers of astrophysics simulations find bugs in their software. Suppose all the bugs have been identified and fixed, and they still get some weird behavior in some cases. That weird behavior might well be real! Once again, deterministic behavior in a Monte Carlo simulation proves to a feature rather than a flaw. The weird emergent behavior in a few special cases suggested by the initial Monte Carlo simulation can become the subject of subsequent investigations.

• There's some good info here about /dev/random and /dev/urandom: Myths about /dev/urandom. FWIW, in Python, the default PRNG is Mersenne Twister, but it's quite easy to use SystemRandom (which is essentially /dev/urandom) or your own custom PRNG class. Commented May 23, 2021 at 0:58
• @PM2Ring I didn't mention /dev/random vs /dev/urandom because (1) the distinction is technical, (2) they're the same on many systems, (3) it doesn't matter because even a non-blocking /dev/whatever_random is slow, and (4) they aren't perfect. Perfect is the enemy of good enough. For most Monte Carlo physics simulations, Mersenne Twister is good enough. Commented May 23, 2021 at 3:49
• Oh, sure. Mersenne Twister is fine. And in Python it's seeded from urandom if you don't supply a seed (it falls back to using the system time as a seed if the OS doesn't have a random source). And of course, while developing & debugging it's madness to not use a specified seed. ;) Commented May 23, 2021 at 4:07
• Thank you so much. Commented May 25, 2021 at 6:27