Math is fun. There’s plenty to discover if you put your mind to it, sort of like magic. I mentioned Pi a while ago (I’m still fascinated by that number and e, for that matter) – that number there became the star of my latest face palm moment. You see, if you think circles and chaos theory don’t mix, you’re bloody wrong. My latest oh-shit moment came when some piece of software I wrote to support a theory gave me numbers so .. bogus they didn’t make sense at all. After spending some time debugging, cursing and drinking, I reached the obvious conclusion: my code was perfect. What gives? Murphy’s laws for computers – shit goes in, shit comes out. Monte Carlo has flaws, but not in the implementation – in the input.

The obvious thing to do is blame the software, make some programmer angry by passing the task to him (because they’re programmers and I’m not) and call it a day. Wrong. I did that, I still owe the guy a few beers and still got no improvements over what I wrote. Lateral thinking time! This should be a slogan, I think. Like I said, to fool the average individual you mess with how you label the results, but to fool the scientist you have to mess with the input. So I grabbed myself a bottle and went to my happy place.

Monte Carlo is an useful tool for everybody, though a bit hard on the neurons for those not familiar with it. It’s really like graphing a function, hell, it’s exactly that if you connect the dots in an ordered fashion. Sorting the input and connecting the dots gives you a trend and that trend is more accurate the higher the number of times you run the simulation. A Monte Carlo works like this: you have a function, f(x) = ax + b, for instance – and you keep feeding random numbers into it while recording the values you get as a result. Do that many, many, many times and you have a very nice collection of dots, from which you can approximate the rest of the dots you didn’t have. It’s very nice for statistics. You can put it to use wherever you like, from physics to finance risk management, and it’ll give a nice view of whatever you want to measure. I lost ye, haven’t I? Well now, join the club. I’ll explain, it’s easy once you understand the workings, but also easy to mess with it covertly. Monte Carlo is like simulated reality.

You see, a Monte Carlo simulation is sort of adding reality into the mix. You have a specific scenario, with a good set of rules determining the outcome, and you want to know how it would work in real life. Let’s make it even simpler, like determining the value of Pi by shooting a shotgun at a square target – it’s totally doable. How? Let’s talk math:

The area of a circle is Pi times (R squared) where R is the radius, while the area of a square is the length of a side squared. Now, if we circumscribe a circle inside a square, the length of the side of that square is the same size of the diameter of the circle. Let’s call the length of one side of the square Y, while the radius of the circle is X. Y is twice the size of X. So what happens if we divide the circle into 4 quadrants? Well, we also divide the square into 4 smaller squares – each of them having the sides equal to the radius of the circle. The area of the quadrant is (Pi times R squared)/ 4. The area of the small square is R squared. We did all this just to have a target, actually. You see, firing a gun at this target, assuming we never miss, will have the pellets either pass inside the quadrant of the circle or outside it (but still inside the smaller square). Either it hits the quadrant or not, it’s not important, but it’s important that all the pellets hit the target. What is important is something else – the probability of the pellets hitting the quadrant. A shotgun sprays the pellets over an area, at random. If you shoot the rifle once, it’s called running the scenario – the input is the firing of the rifle and the output is where the bullet hits. Since we have no control where the pellets hit, if we run the scenario an infinite amount of times, we’d cover the whole square with bullets. But here’s the thing – we can count the holes. So the probability of the pellets hitting inside the quadrant is the number of holes inside the quadrant divided by the total number of holes in the square. Add enough shots and you covered the whole area, so you can simplify the formula as the area of the quadrant divided by the area of the square. It becomes sort of like this: ((pi times R squared)/4) / (R squared) = Pi/4. Whoupsie, we got a constant here. Counting the number of shots inside the quadrant and dividing it to the number of total holes inside the square gives you a constant. Of course, you have to run this scenario many many times before you’re close, but think about it – just shooting at a target and counting the holes can give you a sufficiently close approximation of Pi. All you have to do is run it enough times to compensate for gravity, rifle characteristics and so on. If you take those out of play and go for a nice set of “what if?”, you don’t even have to shoot that many times.. Now that’s crazy, innit?

What’s even crazier is you can adapt this scenario to work with team management and risk management. Let’s say the success of one team depends on every member of the team doing their work correctly and on time. If we assign each member two variables for that, we have a scenario. For each team member (i), we have a function f(i) = correct work (c(i)) * on time work (o(i)). F(i) = c(i) * o(i). Now we can tweak each variable according to individual team members and our past experience with them, by adding constraints to each variable. This scenario is now set, so by running it an enormous amount of times, each time placing a random value (as defined by the individual constraints) in each variable (c or o), we can see a closer to reality image of what exactly the outcome should be. We can determine a probability of success for a few time intervals and team members and we can then adjust the time we give the teams for a specific assignment, but we can also determine the weak links in team members. Some team members work better with specific individuals, others don’t. John works better if Jane’s in the team. George is rather annoyed by Jake. Melinda hates John but loves George. And so on. Team management just became a math problem. Also, we can probably make the teams work their arses off while also avoiding to give them assignments they can’t possibly finish on time. It’s a think, ya’all.

Banks also use such methods to calculate various risks in liquidity and assets, like how much money should I have in cash for customers, while also keeping only the minimum amount liquid. You see, cash in the vault can’t generate much income the way interbank loans and other assets can. So they have to have just enough cash to give anybody wanting to withdraw from their accounts and at the same time maximizing the income from other assets. It’s all reduced to probability, to reasonable expectation. It’s also why a large number of clients unexpectedly demanding for their money in cash will kill any bank. It’s not because it’s a large number, but because it’s not something they expected – and don’t have sufficient cash in their vaults to give their clients. They have the money but not in cash, and that’s what bank runs really mean. Some of the cash is in loans for other clients, some is lent to other banks, some is in other assets, and they can usually borrow against them to have enough money for clients if they have the time. They won’t have enough time, if it’s a bank run, because that event is unexpected.

Well, anyway, Monte Carlo is what I used. Why did it fail me? Because the input was shaite. You see, if your random numbers aren’t that random, your results won’t matter. The probabilities it gives you will be far from the truth. The list of random numbers I used was from a third party ~~created by a lazy son-of-a-gun who probably only thought to get home faster~~. It’s also why I don’t trust software random number generators, like the ones people use for consumer encryption. How did I check? I made a small excel script based on this here paper, measuring the deviation from uniformity. A frequency test. It’s crude but it worked. Gets you thinking though, how an avoidable error could compromise months of preparations. If the random numbers had been generated using a non-linear algorithm with long enough period, I’d still be banging my head on the wall. Sheesh. Of course, if one takes away the impossible, all that’s left is the truth, according to Mr. Holmes, so I did have a spectral test prepared, if local nonrandom can’t be found. But that’s another story and would have required a nice fellow like myself to owe a few more cases of Guinness to another nice programmer, since I don’t have the knowledge to put that algorithm in code. Come to think of it, I really ought to have looked at how long the computers had been working that day. Or attach a thing to the hardware modules, but who’s going to pay for something like that? Good luck running that through accounting…

Post scriptum:

All of the above didn’t happen. Ever. We’re safe and secure. Go back to sleep, it’s not like NSA needs your cooking recipes or the bets you place online. However, it was a good face palm, since I now remember a few things about random events and the issue of human mind. I wonder if anybody has the winning lottery numbers spanning back 30 years or so, since I don’t have access to anything radioactive – now that I could use to test other generators.