Mathematics Stack Exchange is a question and answer site for people studying math at any level and professionals in related fields. It only takes a minute to sign up.
Sign up to join this community
I play the number guessing game with positive integers and a known constant upper bound. Every time I make a guess about the number I have to pay 1 dollar but if my partner answers 'Yes' I have to pay 9 more.
What is the best strategy to minimize my average cost of the game (other than not playing)?
Does the strategy change if I have to pay more/less for the good guesses?
Ordering doesn't matter here, only the size of the search space. Since every question is yes/no, it splits the space into two parts, and the only parameter that matters for each question is how to size those parts. This allows us to compute the expected cost recursively. Define $T(n)$ to be the average cost of asking enough questions to determine the number from a search space of $n$. By definition $T(1)=0$ (technically the game doesn't end until you have actually guessed the number, but this adds only $O(1)$ to the cost so I'll play fast and loose with this distinction).
For $n \ge 2$, the expected cost of asking "is the number in a given subset of size $k$?" and continuing to play the game on the remaining search space is $1 + \frac{k}{n} (9 + T(k)) + \frac{n-k}{n} T(n-k)$. So we optimize this quantity over all $0 < k < n$:
$$T(n) = \min_{0<k<n} 1 + \frac{k}{n} (9 + T(k)) + \frac{n-k}{n} T(n-k) = 1 + \frac1n \min_{0<k<n} (9k + kT(k) + (n-k)T(n-k)).$$
This gives an optimal value of $T(100) = 26.5$, substantially better than CJ from buherator's answer (assuming we agree on the $O(1)$ convention). I computed the optimal costs and moves up to $n=10000$.
An optimal strategy for $n=10000$ costs about $52.1$, and the first question is to ask "is the number in the range $[1,1607]$?" This has a $0.1607$ chance of costing $10$ plus the cost of solving the size $1607$ problem (which is $\approx 41.956$), and a $0.8393$ chance of costing $1$ plus the cost of solving the size $8393$ problem (which is $\approx 51.127$).
This example suggests that the optimal cutoff is approximately where the two cases balance out in cost, just as in the symmetric case. If we make this assumption then we can do a pretty good job of approximating the optimal strategy. The value of $T(n)$ is a priori somewhere between $\log_2 n$ and $10 \log_2 n$: we make the ansatz that it is asymptotic to $c \log n$ for some constant $c$. Then the optimal cutoff occurs where
$$9 + c \log k = c \log(n-k) \implies \frac{k}{n} = \frac{1}{1 + e^{9/c}}.$$
On the other hand (still under the key assumption) the cost is also equal to the number of iterations that descend into the large half, so $c = -1/\log(1-\epsilon)$. This gives two equations in $\epsilon$ and $c$:
$$\epsilon = \frac{1}{1 + e^{9/c}}, c = -1/\log(1-\epsilon),$$ which has the numerical solution $\epsilon \approx 0.164922, c \approx 5.548537$. So I would conjecture that the optimal strategy is close to "is the number in the first 16.5% of the current range?" The actual ratio appears to be rather non-monotonic, varying up and down between $0.14$ and $0.17$ as $n$ increases, even for large $n$. This could be due to rounding errors in my computation (we could be comparing several $k$ values whose scores are really close), but if not then it suggests that the deviation between the optimal $k$ and $\epsilon n$ is more than just rounding to an integer value of $k$.
So after all, we put together a little sample script for simulation:
https://gitorious.org/campzer0/numberguessing/
We implemented the naive linear approach and two modified version of binary search:
After 10000 runs with an upper bound of 100 the results look like this:
naive average of 10000 runs: 59.8012
synalgo average of 10000 runs: 32.9129
cj average of 10000 runs: 30.9006
CJ is usually ~10% better than synalgo and they both present good results compared to the naive approach.
These algorithms are of course not proven (close-to) optimal, but provide acceptable efficiency for my actual problem. Any further optimization proposals are welcome though!