suppose you've been kidnapped and your captors want to play televised game of chess. if you lose, they'll double the ransom, so you don't want to lose.

however, since you are a very forward-thinking individual, you have prepared for this scenario, and have set up a system for communicating to your friend via chess-moves. you want to tell your friend where you're being held captive, so they can send the police in. obviously, you can't use words. your friend will look at every 3 moves you make, and see if the majority of them were on pieces from the right half or left half of the board. if the majority were on the left, that will be a 1 and if the majority were on the right, that will be a 0. putting all these bits together, your friend can decode the string you sent.

this is a delicate balancing act. some schemes are more efficient, in that you can sent more bits, possibly even multiple bits per turn, but will make it pretty easy for you to lose the chess game, whereas there are strategies which don't impact your ability to win the game as much, but will result in less information being sent.

assuming you have utilities for the ransom doubling and you successfully sending information to your friend, what is the best information coding scheme you could have come up with?

since i don't expect there is any straightforward answer, what i really want is an algorithm which can perform some sort of search to arrive at a good coding scheme. however, i'm afraid that the search space of "all coding schemes of a chess game" is so large that there's no good way to tackle this besides using crazy schemes like genetic programming, which i want to avoid.

There's two parts: translating chess moves into a bit sequence, and translating the bit sequence into a message. Let me start with the second.

ASCII is a bit wasteful (do you really need control characters in your message?), you can get away with 5 bits per character (lowercase letters only, no numbers). This is easy enough to calculate in your head if you don't stress out too much. You can go slightly more elaborate and find an encoding where letters take 5 bits, and numbers take 6 bits.You could memorize a huffman tree, giving common letters like "e" shorter representations than "y" (like morse code does), but you better not forget the tree in a stressful situation. Note that you cannot use morse code, since it's not binary (short, long, pause are three symbols!). This can backfire though, if you end up trapped in a welsh town with lots of uncommon letters in the name.Anything more advanced than a predefined huffman encoding will need at least pen&paper to construct, so you wouldn't want to rely on that. Arithmetic coding, backreferences, run length coding.. just don't. It's also rarely useful for very short messages.

tl;dr: let's say 5 bits per letter.

How how long do you need your message to be?"51 30 26N 0 7 39W" is nice, if you know the information. 17 letters = 85 bits."BUCKETVILLE, MAIN STREET 27, BASEMENT" is a bit long, but maybe "BKTVL MAIN 27 BASEM" will suffice. 19 letters, 95 bits."NOT SURE BUT I HEARD SEAGULLS WHILE DRIVING AND THEN THERE WAS A BRIDGE AND THIS ROOM LOOKS LIKE AN ABANDONED CAR LOT" won't do at all.

Now, a quick google check suggests that the average chess game lasts maybe 40 moves for experienced players. Under duress, I wouldn't expect you to last more than 30. With 1 bit per 3 moves, that's 10 bit, not even enough to send "SOS".

To put out a meaningful message, you'd better cram 3 bits into every move, possibly 4. Is that possible?The opening move has 10 movable pieces, each with 2 options to move. That's 20 possibilities, barely above 4 bits. The number of options changes throughout the game (more when you free your queen, less when you start losing pieces), but let's use 20 as a ballpark.If you enumerate all possible moves in a fixed manner and do exactly the move corresponding to the next bits in the message, then 4 bits per move is doable. But then you won't last 30 moves. And you won't win. It's also kinda suspicious.

In other words, if only your moves get televised, you're probably screwed. If there's a camera on the chess board, recording your hand movements, then that may give you other options. Almost touching a piece, hesistating, then moving another. Picking your nose. Things like that might get you enough bits.

Tub wrote:How how long do you need your message to be?"51 30 26N 0 7 39W" is nice, if you know the information. 17 letters = 85 bits."BUCKETVILLE, MAIN STREET 27, BASEMENT" is a bit long, but maybe "BKTVL MAIN 27 BASEM" will suffice. 19 letters, 95 bits."NOT SURE BUT I HEARD SEAGULLS WHILE DRIVING AND THEN THERE WAS A BRIDGE AND THIS ROOM LOOKS LIKE AN ABANDONED CAR LOT" won't do at all.

If you subdivide the Earth's surface into 2^30 equal pieces, they cover less than a square kilometre. So if you (like the huffman encoding) account for lots of uninhabited water and land (unlikely to be held there; and you need less precision in low-density areas) and locality of kidnapping (more likely to occur less than 50 km away), you can drop some of those 30 bits to keep the same (expected!) precision.So if you know your exact location and you have a perfect encoding memorized for locations, you can be found with as few as 20 bits with high probability.

>-) wrote:this is a delicate balancing act. some schemes are more efficient, in that you can sent more bits, possibly even multiple bits per turn, but will make it pretty easy for you to lose the chess game, whereas there are strategies which don't impact your ability to win the game as much, but will result in less information being sent.

Your friend is aware of what you're trying to do, right? So they'll do everything in their power to keep the board open for you to send information, right?Or can the captors get suspicious and cancel the game when they only see pawn movement?

Luckily, you can send 16+ bits of information by moving pawns from their starting positions, which you may be able to use even if your friend is playing to win. This is a mental relief too, because they're all independent moves, so you can just subdivide the search tree into 2*8 subtrees, then 2*7 subtrees, then 2*6... and you can do them during any turn.

If your friend isn't playing to win, they may be moving a horse back and forth, or maybe setting up some pieces will increase your available moves later on.

english has less than 1.5 bits of entropy per character, so with 30 moves you could send something like 20 characters, although it's possible that an address or something may have more entropy than your average sentence.

but i'm not interested in a specific scheme for a scenario where you want to send exactly k characters or something. suppose the more information you send, the better, but of course you don't know how much better. i want something algorithmic procedure which can play the game over and over, and figure out the scheme with the best balance of information and chess-performance. it shouldn't be specific to chess either -- if you suddenly had to play a game of go, then the same algorithm should work

for example, the simplest algorithm would be to pick a random coding scheme, play a bunch of games with that scheme, and then take the average final score of the meta-game -- that is, scoring for whether you won or lost the chess game and how much value you got from transmitting the information.

but this is untenable because the space of coding schemes is too large, and i'm not sure how to deal with it

Entropy is a lower bound for compression, not something guaranteed to be achievable.

The secret to entropy coding is to make a good guess at the next character given all the previous characters. More precisely, you need to list all the possible characters, and assign them probabilities.

If your message starts with "This ice-cream is ", then you'd assign high probabilities for it to be followed by "delicious", "tasty" or "cold", but low probability for "sentient", "burning" or "bird".

For this to work, both the encoder and the decoder need to agree on the precise probabilities for each symbol at each step of the message. You can only compress a message to its entropy if both sides can agree on all probabilities without communicating.For english language, you cannot do that. No two people would agree precisely on the same probabilities in all situations, and a formal look-up table will get too large even for short messages. You can try to send the required probabilities along with the message, but that'll cost you more bits than it'll save. You can try to guess the probabilities from previous parts of the message (like, 2 of 10 letters so far were "e", so I expect the next letter to be "e" with 20% chance) - but that's pointless for short messages, because it takes too long to train.

The best you can do for a short message is to agree on fixed probabilities for each letter and use those. Memorize a huffman table. That gets you down to about ~4 bits per letter. Otherwise 5 bits.

>-) wrote:[..]but this is untenable because the space of coding schemes is too large, and i'm not sure how to deal with it

You can neither accurately simulate the opponents, nor can you do an exhaustive simulation of all the possible chess games. There's no point in finding the perfect coding scheme if your scoring function is inaccurate - just find a scheme that's good enough.If you're serious about implementing this, try a dozen coding schemes that seem promising. The results should be interesting enough, and they might give you ideas for further schemes to try.

Flumble wrote:If you subdivide the Earth's surface into 2^30 equal pieces, they cover less than a square kilometre.[..]

You think that narrowing it down to a km² is enough to find a kidnapped person? Who are you, Liam Neeson?

Flumble wrote:Your friend is aware of what you're trying to do, right? So they'll do everything in their power to keep the board open for you to send information, right?

Your friend is not the one you're playing against - that's why it's relevant that the game is televised, so that your friend can see the message and act upon it.

Huh, for some reason I imagined the captive and their friend playing a game of chess via a TV signal.

>-) wrote:but i'm not interested in a specific scheme for a scenario where you want to send exactly k characters or something.

Of course with a perfect encoding you can also make the most out of every sequence of 1..m symbols. (e.g. with an address you start with the country, then the district/city, then street, then number –if the sequence is cut off before the street, at least you made maxmimum use of the information giving the first two symbols)So anyway, let's just assume a perfect encoding for any amount of information sent. (Like Tub said, there are two parts to the problem)

I think the biggest question is: do you want the highest lower bound for information sent during a game or the highest expected amount of information?

Self-natterings: for chess, finding a lower bound might be tricky to implement, because you constantly have that trade-off between more choice (i.e. information) per move versus more moves: putting no restrictions on the first two moves gives you the most information in those two moves, but two of those plays can lead to a fool's mate.For an actual lower bound, you'd have to brute-force all first n moves of both players and count all the paths that cannot lead to checkmate in less than those n moves. No idea how you could get an estimation of the lower bound.An estimation of the expected entropy seems easy to me: run simulations against a chess AI in which you count all available moves every turn, then make one at random. The expected entropy is (the logarithm of) the product of those available moves every game. I think it averages to the true expected entropy: say you have a simulation up to n turns and there are 2 possible moves, one results in a checkmate, the other results in 4 new moves in the next turn (which then all lead to checkmate for simplicity's sake). So the entropy for this subtree should be 2 bits (always decide to do the latter move, which gives 4 options), and the simulation ends up at (1+3)/2=2 bits on average.

Tub wrote:

Flumble wrote:If you subdivide the Earth's surface into 2^30 equal pieces, they cover less than a square kilometre.[..]

You think that narrowing it down to a km² is enough to find a kidnapped person? Who are you, Liam Neeson?

Hey, you don't need to be a protagonist to see that single lodge in the desert. Maybe I should've said something like there are probably fewer than 2^15 buildings in your vicinity, so 16 bits (one bit to signify it's in the neighbourhood) ought to be sufficient for most kidnapping cases.

Derek wrote:Why not just send longitude and latitude? How many bits does it take to communicate those to, say, 100 meters of precision?

In binary lat/long, ~30 bits should suffice for 1km precision, ~37 for 100m, ~44 for 10m etc. But as flumble said, there are better encodings when you realize that you're probably kept on a landmass, not in the ocean.

The practical concern is that you must somehow determine lat/long - I doubt the captors would let you keep your smartphone. Having some flexibility in your message format allows you to communicate other information if lat/long is not available.

Tub wrote:The practical concern is that you must somehow determine lat/long - I doubt the captors would let you keep your smartphone. Having some flexibility in your message format allows you to communicate other information if lat/long is not available.

The captive is fucked unless she has a GPS radio implanted or the street address.

I infer this based on experience.

So if I live in the US and am kidnapped in Paris, I could talk to you on the phone and couldn't tell you where I was without some very specific knowledge. For instance the mailing address on an envelope or GPS coordinates. Did the OP not stop to consider why GPS was developed? Most people don't know where they are at in any absolute way.

i admit that the scenario in the op was a bit contrived, but that was part of my attempt to distill the original problem about a more complex game into a simpler one while retaining the challenging aspects.

in case it helps, here's the original game: https://en.wikipedia.org/wiki/Hanabi_(card_game)roughly speaking, a bunch of players try to coordinate to place down some cards on the board in a specific order, without knowledge of their own cards. each player can see all the cards but their own. however, each player can also give information about another player's cards, in a certain limited way.

however, good (if not optimal) play requires that players give information and play their cards in accordance with pre-agreed on rules so that more information can be sent. for example, one common strategy is for person 1 to hint to person 3 that a certain card is playable, even though it is not -- in the hope that player 2 will notice it, and then infer that player 1 meant to inform player 2 that he should play one of his cards in order to cause player 3's card to be playable. this successfully informs two players of how they should act with a hint which naively can only be used to inform one.

notice that it is very possible to encode much more information into each allowed "hint" by simply using some optimal binary code, but if you play that way, disregarding the objective of the game, you will quickly lose. so this is an example of how a simple but well designed coding scheme can be used to balance information delivered with the game objective. my question is how to come up with the optimal play strategy?

this is very similar to the chess problem i have described, in that the end goal is optimizing for the meta-game, but in order to do that, an efficient coding scheme is needed -- but simply optimizing for the coding scheme will result in poor play, and thus lose the meta-game

I was simply pointing out that she can't tell you where she's at, if she doesn't know where she is. If she only knows within a mile, that as much information as you can transmit, no matter how efficient your encoding. In terms of finding someone, their location has to be relative to some fixed point known to everyone. It's why we use GPS. Anything less than GPS implies higher degrees of uncertainty about that position. You might need to define winning in terms of some area of uncertainty. Or am I missing the point? On your Encoding. Three moves to a bit. So if you wrote four ones in row that would imply 12 moves in a row on one side of the board. 0011 1100 as an example. Is that right? Anyway thanks, good luck.

Yes, i'm trying to say that i'm not too concerned with the technical details and logistics of the game I wrote up in the op since the goal is to not solve that one particular game but to solve a larger class of games, all of which have the same core "issue" which makes them difficult to solve using for example, standard minimax search (or for a cooperative game, maximax search)

If you've already pre-planned for this why not just say, each move I will move 3 pieces, but not actually place them. I'll pick it up and move it but leave my finger on it and then return it to where it was. You could use this to encode a lot of information. If pre-planning is available you could already assign keywords, or what have you to specific pieces based on when you pick it up and move it or return it.

trpmb6 wrote:If you've already pre-planned for this why not just say, each move I will move 3 pieces, but not actually place them. I'll pick it up and move it but leave my finger on it and then return it to where it was. You could use this to encode a lot of information. If pre-planning is available you could already assign keywords, or what have you to specific pieces based on when you pick it up and move it or return it.

Chess has a touch-move rule which says that if you touch a piece you must make a move with it. I've always thought it a rather stupid rule (in favor of the simple "if you let it go your turn is done"), but if your captor is strict then he will not permit you to do that.

I went to look for the original motivation of the touch-move rule and didn't find a ton that I find very compelling (I guess it is either to nebulously try to stop being annoying, or make it more difficult to cheat), but this only slightly related thing is pretty hilarious:

"At one time the rule also required the player who played an illegal move to move his king. In the first half of the nineteenth century, Rule XIII of the London Chess Club provided:

"If a player make a false move, i.e., play a Piece or Pawn to any square to which it cannot legally be moved, his adversary has the choice of three penalties; viz., 1st, of compelling him to let the Piece or Pawn remain on the square to which he played it; 2nd, to move correctly to another square; 3rd, to replace the Piece or Pawn and move his King. (Staunton 1848:37) (Marache 1866:24)

"While this rule existed, it occasionally led to tragicomedies such as in the 1893 game between Lindermann and Echtermeyer, at Kiel.[8] In that game, after 1.e4 d5 2.exd5 Qxd5 White, probably intending the usual 3.Nc3, instead placed his queen's bishop on c3. Since that move was illegal, White was compelled to instead move his king. After the forced 3.Ke2??, Black gave checkmate with 3...Qe4# (Chernev 1974:119)."

trpmb6 wrote:If you've already pre-planned for this why not just say, each move I will move 3 pieces, but not actually place them. I'll pick it up and move it but leave my finger on it and then return it to where it was. You could use this to encode a lot of information. If pre-planning is available you could already assign keywords, or what have you to specific pieces based on when you pick it up and move it or return it.

Chess has a touch-move rule which says that if you touch a piece you must make a move with it. I've always thought it a rather stupid rule (in favor of the simple "if you let it go your turn is done"), but if your captor is strict then he will not permit you to do that.

I guess I've never actually played in an official tournament type setting. But that would indeed prevent the type of messaging I had hoped to achieve.

According to the wikipedia page EvanED linked, if you touch a piece, then you must move it if you can move it. Touching a piece without valid moves appears to have no consequences.

You have 6 unmovable pieces at your first move, giving you ~2.6 bits per touch until either your message is sent, or the captors are fed up with your nonsense and shoot you. You could also pick up the pieces and move them around for extra bits, but that's probably not faster than quick touches.

But if there's a camera on your hands, and you don't mind raising suspicion, then you can also just point at one of the 64 squares for 6 bits, or use sign language ..

Sometimes players will hover their hand over a piece for a couple seconds before touching it, just as a last moment consideration. You can freely withdraw it and move another piece as long as you've not touched it.

If you touch a piece, move it, and don't let go, you can actually change your mind about where you want to move it to if you put it back and think more, as long as you never let go. Again, players will sometimes do another assessment of the position with the piece in it's "final" location while holding on still. So aside from looking suspicious, you could also think about moving a piece somewhere, don't let go, think for a couple seconds, move it back, think more, then move that piece to the same or a different square.

So it definitely seems like you could, at least for a short while before they figure it out, send more bits of information. One major consideration to this is any sort of timing constraints the captor may put on you. ie, 10 or 15 seconds per move etc. Heaven forbid they make you play speed chess.

If you're quick enough anyway, then with the handy clock visible to you and perhaps the observer, encode information by time. Movement of index finger up/down(/left/right) as each even second ticks past could give you a number of other bits of data, per forced move. Restricting to even seconds gives you a clear two-second period to try to match a dominant signal to the temporal marker, lets you reset between two similar movements, lets you actually move a piece...

(I'm not saying that the captors won't think something odd is going on/that you can still think enough to also play half-decently/that you can encode the half-baud signal on the fly, but it's an additional information vector to consider using.)

I don't really have any idea of how to do what he wants but I believe that he wants the answer to the question of how many ways you can use a chess game to encode a message and where could he find them. For instance, if your time sense is good enough, and your chess skills are better than average, each move could transmit ten digits irrespective of the move. Count beats before making a move. Instead of hiding the code in the game, hide the code in the spaces. Thirty decimal digits in a 30 move game. This one is kinda neat because you could send your zip code and numerical address and the police would find you. And send it twice for redundancy. And Checkmate the villain. Very Bondish.

My guess is the OP is looking for help in coding something for a class or something. It was a little too specific for general musings. I would help if I could think of a good algorithm for doing it. But my issue is it's just a poor way to do it when there are better alternatives available in such a specific situation.

Professors hated me for this very reason. Propose absurd situations and expect an absurd, but technically correct, answer.

I would suggest the card game bridge has some answers. There is much accepted theory about how to bid optimally, while also sending as much information as possible to your partner.

In the case of chess, sending a lot of information as early as possibly is foolish, as you'll very quickly lose. As the game progresses, you start to see equally-optimal moves, where sending information is free. But if you're a very good chess player, I'd go with something like "ignore everything before the 100th move, I'm going to get ahead or even, trap his king in a corner, and essentially force a draw. Then I'll move my own king around in open space according to some rules we've agreed that send information, trading off a piece every 50 moves, refusing his offers of a draw and never repeating previous positions."

Two accomplices in a crime have been arrested and are about to be locked in widely separated cells. Their only means of communication after they are locked up will he by way of messages conveyed for them by trustees -- who are known to be agents of the warden. The warden is willing to allow the prisoners to exchange messages in the hope that he can deceive at least one of them into accepting as a genuine communication from the other either a fraudulent message created by the warden himself or else a modification by him of a genuine message. However, since he has every reason to suspect that the prisoners want to coordinate an escape plan, the warden will only permit the exchanges to occur if the information contained in the messages is completely open to him -- and presumably innocuous. The prisoners, on the other hand, are willing to accept these conditions, i.e., to accept some risk of deception in order to be able to communicate at all, since they need to coordinate their plans. To do this they will have to deceive the warden by finding a way of communicating secretly in the exchanges, i.e., of establishing a “subliminal channel” between them in full view of the warden, even though the messages themselves contain no secret (to the warden) information‡. Since they anticipate that the warden will try to deceive them by introducing fraudulent messages, they will only exchange messages if they are permitted to authenticate them