What writing a failed rock-paper-scissors program taught me (or should have taught me) about sample size and uncertainty

In a recent comment thread, Phil shared the story of a program he wrote on the little computer in our high school math room. I think it was an OSI (Ohio Scientific) that used, ummm, I think it was 5-inch floppies but maybe it was 8 inches. As Phil said, we programmed in Basic. The cool thing to me was that it had a terminal! I’d learned programming using punch cards. Being able to type directly into the terminal and see the results on the screen . . . that was just amazing.

Anyway, there are two programs I remember writing for it. First was the lunar lander program–that one’s a classic, zillions of people have programmed it, actually it’s kinda fun. Your lander is subject to gravitational acceleration and you have a fixed supply of fuel. You can fire the rockets to slow down, and the goal is to land softly. Use too much fuel too early and you’ll decelerate too fast, with not enough fuel to slow you down at the end when you need it. Wait too long and it’ll be too late! This is the simple one-dimensional version–it’s easy to program (just Newton’s laws!) and a small challenge to play and survive.

The other thing I remember is writing a program to play rock-paper-scissors. It started with random plays, then after 10 rounds or so, it tried to figure out what to do based on the opponent’s pattern of play. It was crudely fitting a lag-1 Markov process, estimating the probability of each of the 3 choices conditional on the previous play. I programmed it up, tried it out a few times myself to see that it worked, and then gave it to others to play (without revealing its rules).

I fully expected the program to do well. People are predicable, right? Actually, though, it bombed. I don’t think its poor performance came from savvy play on the part of its opponents. That is, I don’t think my friends adapted their play against my rock-paper-scissors robot so as to defeat its algorithm. Rather, I think it’s just noise. First, playing a few rounds against someone would not be enough for my bot to estimate the conditional probabilities. I can’t remember how my program worked, but it probably used a crudely empirical estimate which would in practice be super-noisy. Second, even if the program really was somewhat better (or worse) than chance, you’d need lots of rounds to be able to notice it. To really see if the program is doing well, you’d need to collect a bunch of data.

10 thoughts on “What writing a failed rock-paper-scissors program taught me (or should have taught me) about sample size and uncertainty

  1. It’s a good thing the curmudgeons who commented on yesterday’s post on AI failing at tic-tac-toe didn’t know you in high school — they’d have to conclude that your rock-paper-scissors failure exposes you as an ignoramus whose neural architecture couldn’t possibly yield insights into statistics.

      • Its already about using logistics (how to accomplish tasks) rather than simple Q/A “facts”.

        Questions like “give me three ideas for an experiment to study X, with exact reagents and equipment I need. Next give an in vivo study to go along with it. Do web searches to double check then give prices and links to where you got them.”

        Once again, if you are only using free web interfaces you have no concept of what they are capable of (like me a few months ago).

        The “hallucinations” are pretty independent so just run a couple of those then have another model judge and synthesize.

        Writing dissertations/etc is done as a way to demonstrate mastery of a topic.

        PS. Of course its all NHST experiments, but that’s what grant reviewers want and expect.

        • “Once again, if you are only using free web interfaces you have no concept of what they are capable of (like me a few months ago).”

          I’m now wondering how someone who can automatically disregard all p-value-based science as lacking sufficient evidence could generate enough evidence to convince yourself of something like this. You must have spent hundreds of hours comparing chatbot outputs!

          Do you have an example where your paid subscription chatbot was capable of demonstrating rational thought that was beyond a “free web interface?” Not just a better answer, but a PhD answer that is categorically different from what a free interface offers.

          Every time LLMs come up here on the blog, someone feels compelled to claim that their paid-subscription chatbot can do whatever is in dispute even if other chatbots cannot. I will need to see a consistent pattern of actual evidence for that before I believe it.

          Remember the first rule of reverse engineering: if something looks ordinary, you probably understand it just fine. If something looks extraordinary, you probably don’t understand it.

  2. Isn’t adapting one’s play to the play of the opponent (whether computer program or otherwise), the only reasonable strategy in rock-paper-scissors? The only Nash equilibrium is to play each round randomly and with probability 1/3 for each option, right? So there is no reason to have any other stable pattern of play – as seems assumed by the Markov estimation. And if that estimation leads to some stable pattern of play by the program, then that is something that the human player can use to their advantage – whether they know how the program came up with that strategy or not.

    • I recall a programming competition many years ago, where contestants would submit programs to play tic tac toe, and then there was a big round robin tournament with enough games to get reasonable statistics. All the successful strategies included a fallback to random if it looked like they were losing, so that the result would count as a draw due to not hitting a significance threshold.

      The more memorable part of the competition was a separate bracket explicitly for programs that tried to cheat. One of the winners there would fork, submit a different action on each child, and then kill the processes where it lost. Good fun!

    • Nash equilibrium play is in some sense a worst case; if the other player is playing optimally it’s all you can do, but suboptimal players may be exploitable.

      A classic example of an algorithm that can be trained to do well is Claude Shannon’s “Mind-reading Machine” at Bell Labs, which played a game that’s essentially matching pennies (ie, I say heads or tails, I say heads or tails, I get a point if I guess what you chose correctly, you get a point if I guess wrong), and reportedly could beat most humans. It is not to hard get an algorithm that provably does reasonably well for any sequence; rock-paper-scissors, like matching pennies, is a zero sum game, and it’s known that game play according to any no regret algorithm will asymptotically do at most slightly worse than the best fixed strategy; meaning that if your opponent randomizes properly it wins almost half the time, with that almost approaching exact as rounds go to infinity. The nice thing though is that if a person fails to randomize in the long run (maybe you do 36 percent rock, or whatever), it does about as well as someone who plays paper the optimal amount. Of course, any method will have variable results due to randomness, so Andrew may just have had bad luck, but unregularized methods are provably exploitable in the worst case.

      The key difference with Andrew’s program here, which uses a basic statistical learning approach, is that, e.g., fitting a Markov model (or any standard model class) by, e.g., fitting empirical frequencies, is not a no-regret procedure. Plenty of simple things are, though they generally involve randomization and maybe some kind of regularization. This includes Bayesian updating, if you play by sampling from the posterior! Game theorists call this the “Hedge” or “Exponential Weights” algorithm. See, on the mind-reading machine in particular, notes by Sridharan https://www.cs.cornell.edu/courses/cs6783/2021fa/lec11.pdf, and for general zero sum games, the rest of the class notes (or really any other class on computational games; Aaron Roth’s are particularly good).

Leave a Reply

Your email address will not be published. Required fields are marked *