I have a chess GUI which I've recently been updating to do preemptive searches (that is, depth searches for all possible opponent moves) that I'd like to speed up, since the bot searches go to at least depth 16 for every move, and each move runs a new Stockfish 11 command line (with minimum settings) in a separate thread.

Now, I have some solutions for the threading issue, but one would involve knowing more chess math than I know now.

I noticed that, after a certain search depth, the PV's first move, and then first few moves, really don't change that often, and I'd like to know if there's a formula out there, similar to one that I used to calculate winning odds.

I considered the following:

  • Do a depth search of n on the position after hypothetical opponent move m.
  • Retrieve the pv for depth n.
  • Append it to a corpus.
  • Do a depth search of n+1 on the same position.
  • Retrieve the pv for depth n+1.
  • If a text prediction algorithm using the corpus will produce n+1[pv][0:x], such that x is sufficiently large (needs more math) to be reliable, cease the depth searches and recommend n+1[pv][0].

I'm thinking that there might be a simpler way of reaching a similar outcome, since pv[0] would have to arise every time in the text prediction.

What other Stockfish info might I want to consider in generating a statistical confidence that the recommendation need not search any deeper?

  • This sounds difficult to tackle as it depends a lot on the position. Generally speaking I would guess that a stable evaluation may imply more stable future PVs. However that's not a guarantee, even a stable eval might just be overlooking some deep tactics. However I think it's more likely to keep the PV than an already varying eval. – koedem Nov 25 '20 at 17:55
  • Another thing to look at may be the node counts for different moves. I don't quite understand how you intend to use this / how your setup works, however, if you have some search and the top move being looked at takes most of the nodes, i.e. all non-optimal moves are dealt with quickly, then I'd think it's more likely that the top move won't change. (as all other moves are "refuted" very quickly) Whereas if the non-optimal moves take a lot of nodes they may be on the verge of becoming the new best move if that makes sense. – koedem Nov 25 '20 at 18:00
  • Sorry for the many comments but I have so many questions about this setup. So you run a fresh independent search for each possible move? You are aware that this is massively inefficient? (especially if you "only" care about the root position evaluation and move, but even otherwise) Not only does that deprive oneself of transposition table speedups between moves but also any search speedups through search windows. (for instance if you want to know if move x is best you don't need to know the evaluation of all other moves, you just need to know that they're worse than x; much faster to verify) – koedem Nov 25 '20 at 18:27
  • @koedem, so the naive preemptive mover that I built has the bot evaluate at depth for all opponent moves. For instance, if we're at startpos and the bot is black, the function I run threads 20 Stockfish 11 UCI's. Each UCI searches at depth (let's say 20), and then returns the info at depth 20. The program then kills the UCI's and the threads. All of the info is then stored so that, when the human does make a move, the response is faster. The inefficiency you mentioned obviates any gains from that approach. Hence my quest for shortcuts to either close the UCI's earlier or use just one. – Joshua Harwood Nov 25 '20 at 19:04
  • 1
    @koedem, yes, I tend to build brute-force, naive programs, and then work on optimizing them. – Joshua Harwood Nov 25 '20 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.