Hacker News Reader

Comment by cyode | Hacker News Reader

Back in the 90s as a kid, one year I got a handheld 20 Questions electronic game as a stocking stuffer for Christmas. I remember being astonished that this dumb little plastic pod with rubber Yes/No buttons and LCD screen "beat me" by guessing the first thing I tried (the Mona Lisa) in 8 or so guesses.

The author quips that "twenty questions isn’t enough to guess almost anything", but I wonder if most people taking their first crack at the game (usually as children) pick something squarely in the 2^20 most popular things.

(My friend's dad was really good at picking words. I remember he stumped us for an entire restaurant visit with "the cub in the Chicago Cubs logo".)

View on HN

My stepson has one- and I was astonished how good it is. I can’t say I’ve thought about it at length but at face value it seems a marvel. Is the logic for such a thing trivial and widely available?

I have no idea how they actually work, but if I were asked to design one:

• Choose some reasonable number of questions of the form "Is it ___"?. Let's say 256

• Come up with a list of objects, and for each one give it a 256-long bitvector encoding its answers to the questions

• Maintain a set (implemented as another bitvector) of the potential items. Figure out which question would divide the set in two most closely; ask that question.

I am the opposite of a hardware hacker or systems programmer, but it seems like this is algorithmically straightforward to implement with bit-twiddling.

One problem with this explanation of how it might work is that it appears to know far more than 256 things - though I don't know how many. And even if it did know only that many, how do you construct the set of questions?

Actually programming the logic once you know it is the easy bit, it's constructing the dataset of answers and questions in the first place.

This approach allows for 2^256 different things, one for each possible yes/no bitstring.

Ah yes, apologies. Still, big job to construct the database of what things correspond to what answers to the questions - and to choose the questions.

I think you'd probably start with a dense matrix of questions x answers populated by humans. But I imagine there's a clever preprocessing step that's used to build the optimum tree of questions, avoiding getting caught in a local maximum and significantly reducing the data you'd have to store.

> Figure out which question would divide the set in two most closely; ask that question.

This depends on the goal. One goal might be to answer all questions as quickly as possible, in which case partitioning the search space in two might be a good strategy. Another goal might be to have the best chance of guessing the item within 20 questions, in which case you will want to choose questions which maximise the % of the remaining search space you can uniqely identify with the remaining questions (perhaps weighted by popularity of that item).

It's been a longstanding question of mine how these things were programmed. How did they construct the database of answers and questions, and what the answer to each question would be for each possible answer?

Maybe it's some reinforcement learning.

People could play the game at http://20q.net/ , and if it didn't guess your word it asked you to enter it. So it was trained by the players.

It's a neural net, so very efficient on small devices.

https://patents.google.com/patent/US20060230008?oq=Artificia...

Looks similar to the https://akinator.com

Apparently it uses a neural network - https://patents.google.com/patent/US20060230008

That last sentence sounds like a pretty magical memory. :)

My family figured out that you could consistently stump those by guessing "poop". Apparently they can't guess that.

Reply on news.ycombinator.com