Comment by twoodfin

Comment by twoodfin 17 hours ago

It’s simpler. Chess is a search through the space of possible moves, looking for a move that’s estimated to be better than the best move you’ve seen so far.

The search is by depth of further moves, and “better” is a function of heuristics (explicit or learned) on the resulting board positions, because most of the time you can’t be sure a move will inevitably result in a win or a loss.

So any particular move evaluation might take more or less time before the algorithm gives up on it—or chooses it as the new winner. To throw a consistent amount of compute at each move, the simple thing to do is give the engine consistent amounts of time per move.

TheDong 13 hours ago

> To throw a consistent amount of compute at each move, the simple thing to do is give the engine consistent amounts of time per move.

The simple thing to do is give it a limit on the total number of states it can explore in its search.

If your goal is consistency, wall-clock time makes no sense. If I run 'make -j20', should the chess computer become vastly easier because the CPU is being used to compile, not search? Should 'nice -n 20 <chess app pid>' make the chess computer worse?

Should my computer thermal-throttling because it's a hot day make the chess computer worse, so chess is harder in winter?

If the goal is consistency, then wall-clock isn't the simple way to do it.

Reply View 2 replies

shadowpho 13 hours ago

>If the goal is consistency, then wall-clock isn't the simple way to do it.
It’s simpler than doing a limit on number of states, and for some applications consistency isn’t super important.
Doing a time limit also enforces bot moving in a reasonable time. It puts a nice limit to set up a compromise between speed and difficulty.
Doing state limit with a time limit might be better way to do it, but is harder.

Reply View | 1 reply
- Dylan16807 7 hours ago
  
  > It’s simpler than doing a limit on number of states
  According to who?
  A counter that you ++ each move sounds a lot easier to me than throwing off a separate thread/callback to handle a timer.
  > Doing a time limit also enforces bot moving in a reasonable time.
  It's designed for specific hardware, and will never have to run on anything significantly slower, but might have to run on things significantly faster. It doesn't need a time cutoff that would only matter in weird circumstances and make it do a weirdly bad move. It needs to be ready for the future.
  > It puts a nice limit to set up a compromise between speed and difficulty.
  Both methods have that compromise, but using time is way more volatile.
  
  Reply View | 0 replies