It's inconceivable (for example) that Paul Erdos, a world class mathematician, would fail to solve this problem if it were actually communicated clearly.

Original rules (host knows where car is and always opens a door with a goat):

- 1/3 of the time your original choice is the car, and you should stick

- 2/3 of the time your original choice is a goat, and you should switch

Alternative rules (host doesn't know where car is, and may open either the door with the car or a door with a goat)

- 1/3 of the time your original choice is the car, the host opens a door with a goat, and you should stick

- 1/3 of the time your original choice is a goat, the host opens a door with a goat, and you should switch

- 1/3 of the time your original choice is a goat, the host opens the door with the car, and you're going to lose whether you stick or switch

So even under the new rules, you still only win 1/3 of the time by consistently sticking. You're just no longer guaranteed that you can win in any given game.

If you were in this scenario, your odds of getting the car doesn't change whether you switch or not

As usual, the problem is not an incredibly difficult problem, but just a failure to state the problem clearly and correctly.

Try to write a computer program that approximates the probability, and you'll see what I mean.

The math is contingent on whether you know the host knows or doesn't know where the door with the car is. This is the counterintuitive bit.

Yes, of course it depends on the host knowing where the goat is, because if he doesn't, the scenario is not well-defined anymore. This is not annoying, this is to be expected (pun intended).

"Impossible" in the program just refers to cases where the host picks the car door, i.e. the path that we are not on, by the nature of the statement. Feel free to replace the word "impossible" with "ignored" or "conditioned out". The math remains the same.

Method 1: Lichess method; 64 bit header, 1 bit per square indicating occupied squares, then (up to) 32 4 bit codes for the 32 occupied squares. So 24 bytes worst case!

Method 2: My own method a list of 2 bit codes, one of the 4 codes indicates empty square, the other three codes are prefixes for a second 2 bit code. Three prefixes applied to one of 4 code values gives a total of 12 possibilities corresponding to any possible chess piece. Worst case 32x2 bits plus 32x4 bits = 24 bytes.

In each case there is sufficient entropy to create tricks to add the supplementary information (who to move etc.), similar tricks are in the original article.

I mention my own method from my Tarrasch Chess GUI https://github.com/billforsternz/tarrasch-chess-gui only for completeness. If I had known about method 1 I would have used that, it is simpler and better and there is much more entropy available making the tricks easier.

I would urge commentators to keep clear the difference between compressing a chess position (this challenge), a chess move and a chess game. A chess move needs far less bits of course. A complete chess game is always encoded as a list of moves, not positions, for this reason.

Edit: I should have mentioned that the chief advantage of method 1 over method 2 is average bits required. An empty board is 64x1 bits = 8 bytes for method 1 and 64x2 bits = 16 bytes for method 2.

Edit 2: I am going to describe my tricks, just because they are fun. Two kings the same colour means Black to move. Two White kings means the first king is white, two black kings means the first king is black. Otherwise White to move. A friendly pawn on the first rank means an enpassant vulnerable pawn. Swap it with the 4th rank square to get the actual contents of both squares. A hostile pawn on the first rank is an unmoved rook or king, establishing all castling rights. The castling and en-passant tricks can be combined in a pleasant and harmonious way.

Oh well. Big Corp doing what Big Corps do. Paying lip service to legal requirements, but reluctantly and with barriers that would no doubt take a lot of time and money to even try and break down.

  /* Copyright 2023. All unauthorized distribution of this source code
     will be persecuted to the fullest extent of the law*/
  #include <stdio.h>
  #include <stdint.h>
  #include <string.h>
  int main(int argc, char* argv[])
  {
      uint8_t number = argc>1 ? argv[1][strlen(argv[1])-1]-'0' : printf("Usage: odd-or-even number\n");
      if (number == 0)
          printf("even\n");
      if (number == 1)
          printf("odd\n");
      if (number == 2)
          printf("even\n");
      if (number == 3)
          printf("odd\n");
      if (number == 4)
          printf("even\n");
      if (number == 5)
          printf("odd\n");
      if (number == 6)
          printf("even\n");
      if (number == 7)
          printf("odd\n");
      if (number == 8)
          printf("even\n");
      if (number == 9)
          printf("odd\n");
      if (number == 10)
          printf("even\n");
  }

Or is the performance considered worse because it becomes O(n) (where n < MAX_UINT) vs. constant time ( O(MAX_UINT) )

      uint8_t number = (argc<2||sscanf(*++argv,"%*[0123456789]%n",&argc)||argc--[*argv]?printf("bad\n"):argc[*argv])-'0'; // No problems here