Guess the Number
The computer picks a secret number — guess it in as few tries as you can.
Pick a range, then guess — you’ll get a higher or lower hint after every try, and press Enter to submit. Halving the remaining range each time finds any number from 1–100 in at most seven guesses.
The computer picks a number in a chosen range and tells you whether each guess is too high or too low until you find it. Simple to play, and a neat demonstration of binary search — the algorithm that makes it solvable in far fewer guesses than most people expect.
Guessing 1 to 100 one number at a time takes 50 attempts on average. Guessing correctly takes at most seven, every time, and the difference is entirely a matter of method.
The strategy, and why it works
Always guess the midpoint of the remaining range. Each guess then eliminates half the possibilities regardless of the answer, so the search space collapses geometrically rather than one step at a time.
For 1–100: guess 50. If too low, the range is 51–100, so guess 75. Then 63, then 57, and so on. Seven guesses is always enough, because 2⁷ = 128 exceeds 100.
| Range size | Guesses needed (worst case) |
|---|---|
| 10 | 4 |
| 100 | 7 |
| 1,000 | 10 |
| 1,000,000 | 20 |
| 1,000,000,000 | 30 |
Each doubling of the range costs exactly one additional guess. That's what logarithmic growth means in practice — and why a billion is only ten guesses harder than a million.
The same algorithm, everywhere
- Database indexes use B-trees, a generalisation of binary search, to find a row among millions without scanning the table.
- git bisect finds the commit that introduced a bug by halving the range of suspect commits — twenty steps covers a million commits.
- Looking up a word in a physical dictionary is binary search done by hand.
- Debugging by commenting out half the code and seeing whether the problem persists is the same technique applied to source.
- The prerequisite in every case is an ordered space and a comparison that tells you which half to keep. Without ordering, you're back to checking every possibility.
Why the first guess feels wrong
Most people don't open on 50. They open on a number that feels lucky, or on something low, and then adjust in uneven steps — often over-correcting after a 'too high' and searching a range they've already ruled out.
The discipline that makes binary search fast is exactly the part people skip: committing to the midpoint even when it feels arbitrary, and trusting the previous answers to have genuinely eliminated everything they eliminated. It's a small, clean illustration of a general point — a method that feels unintuitive can beat a method that feels natural by a factor of seven.
Frequently asked questions
- What's the fewest guesses needed for 1 to 100?
- Seven in the worst case, using binary search — always guess the midpoint of the remaining range. Since 2⁷ = 128 is greater than 100, seven halvings always suffice.
- Is the target number chosen fairly?
- Yes. It's drawn uniformly at random from the range when the game starts and doesn't change as you play — the answer isn't moved to avoid your guesses.
- Why is guessing the midpoint optimal?
- It guarantees eliminating half the remaining possibilities whichever answer you get. Any other guess eliminates more in one case and fewer in the other, which is worse in the worst case.
- How many guesses would a million-number range take?
- Twenty. Each doubling of the range adds exactly one guess, so a range a thousand times larger costs only ten more attempts.
- Where is binary search used in real software?
- Database indexes, git bisect for finding the commit that broke a build, dictionary lookups, and the general debugging habit of eliminating half the suspect code at a time.
- Can I change the range?
- Yes — pick a different range to make the game shorter or longer. It's a good way to see the logarithmic pattern: ten times the numbers costs only about three more guesses.