What Rose Petals Teach Us about Induction
What Rose Petals Teach Us about Induction
by Oran Looney
July 16, 2026
Philosophy
Machine Learning
LLM
Visualization
Richard Hamming famously used to ask his colleagues at Bell Labs this question:<br>“What is the most important problem in your field, and why aren’t you working<br>on it?” To which they probably replied, “Look, Dick, it’s eight-thirty in the<br>morning. I haven’t even had my coffee yet. Who starts a conversation like<br>that?”
Still, it’s a good question, isn’t it? For me, the answer is obvious: “Is there<br>a general method for induction?” Now, you might think that the human race has a<br>pretty good handle on induction, what with the scientific method and statistics<br>and all that. But no: there’s a gap in the very foundation of our understanding,<br>a gap we can only cross occasionally and haphazardly.
Hume called it the problem of induction; a catchier name is the No Free<br>Lunch theorem, although it’s about as far from being a “theorem” as it’s<br>possible to get. And it is simply this: there is no general, systematic way to<br>go from observation to understanding.
If you haven’t encountered it before, it’s likely you don’t see what the big<br>deal is. Don’t we all do this all the time, without even thinking about it? We<br>do, but we don’t know how we do it, which means we don’t know how to teach<br>it, how to automate it, or even if we’re doing it right.
What’s needed is a simple, concrete example which illustrates the idea without<br>any particular need for mathematical sophistication. I’m going to give just<br>such an example, show how various algorithmic approaches fare, and try to<br>explain the unavoidable trade-off at the heart of the problem.
If all goes well, you’ll not only learn something important about one of the<br>most fundamental unsolved problems out there, you’ll have developed a practical<br>intuition that will help you understand, for example, why François<br>Chollet introduced the ARC-AGI benchmark, why AI researchers keep<br>talking about world models, and what it means to say the transformer<br>architecture hits a sweet spot for language models.
The Game
Let’s start with a bit of nerd folklore, traditionally passed down by a friend<br>who knows the trick and judges you to be the kind of person who will enjoy it.<br>I’ve replicated the experience as nearly as possible here. You don’t have to<br>solve it, necessarily, but you do have to make an honest effort if you want to<br>fully grasp the underlying lesson.
JavaScript is disabled, so the interactive game can't be shown here.<br>You can play<br>Petals Around the Rose on the standalone demo page instead, or read<br>about it on its Wikipedia page.
All done? Great! What method did you use? Could you teach your method to a<br>child? Could you write a program that implements your method? No? Well, I<br>can’t either. That’s what this article is about. But let’s give it a shot<br>anyway, using some off-the-shelf machine learning algorithms, and see if that<br>tells us anything.
Spoilers Ahead!
Algorithmic Approaches
Here’s what I did. Different machine learning algorithms were shown a gradually<br>increasing number of examples; each example consists of the numeric values of<br>the five dice rolls as well as the correct number of petals around the rose for<br>those dice. Each algorithm, in its own way, learns a function which maps those<br>dice rolls to the number of petals. Then, its performance is evaluated on a<br>different set of examples, ones it hasn’t seen before and wasn’t trained on.<br>Whatever number the function outputs is rounded to the nearest integer and<br>marked correct only if it exactly matches the true number of petals; if<br>it’s off by even 0.5, it’s marked incorrect. The test accuracy is the<br>proportion of dice rolls that it gets correct. Once a given algorithm has<br>reached 100% accuracy, we deem that it’s saturated the benchmark and stop. The<br>minimum number of examples needed to reach 100% accuracy is marked with a point<br>and shown as the $N$ in the legend.
(By the way, the full source code and summary report are<br>available on GitHub if you’re interested in the gory details.)
In a minute we’ll go case-by-case to try to understand why each approach fared<br>well or badly, but first let’s just take a look at the high-level results:
Even at a glance, there are already some very interesting conclusions we can<br>draw from the graph. First of all, it’s obvious that some of them solve it<br>almost immediately, some struggle for a long time before noticing the pattern,<br>and some never solve it at all. So there’s something that makes some<br>approaches better or worse than others at this specific problem.
It’s also interesting that each curve seems to follow the same characteristic<br>shape, even across...