my vision for th`future of [chess ]engines

Sort:
Victamon

Standard modern chess has an enormously expansive game-tree; according to Wikipedia, around 10^40 unique feasible board positions (Refer to: https://en.wikipedia.org/wiki/Solving_chess#Predictions_on_when.2Fif_chess_will_be_solved) exist, which cummulatively arrive from ~ 10^120+ possible legal game-paths (finite thanks to fifty-move and three-fold-repitition drawing rules, the former of which as originally added would preclude lots of endgames such as tablebase-guided ones which include many of lines and indeed even branches that proceed for hundreds of moves performed provably accurately by either side before concluding in the gamepoint being awarded in full to one side or the other or split down the middle, resulting in a different delegation of the gamepoint should either one side perform sub-'optimally' in absence of said rule), a lowerbound figure known as the 'Shannon number' (the actual precise integer being uncalculatable, let alone determinable to the nearest power of ten, with number-crunching limitations of today's hardware & software, despite the hitherto impressive advancement of the Information Era).  By comparison, the largest two-person zerosum non-chance {i.e., no dice & full visibility of data to both/all participants} board game that to_date has been solved at the middle degree of 'weakly' (See: https://en.wikipedia.org/wiki/Solved_game#Partially_solved_games), is Western checkers (accomplished in 2007), with a gamespace of ~ 5×10^20 tempi. (It results in a draw given non-imperfect play from both sides.)

 

Now, obviously 10E120 is many orders larger than 5E20: by a near-unfathomable magnitude itself, exceeding 10^110. As such, chess is unlikely to be 'solved' in the near future. However, perhaps some of the concepts of 'solving' a game can be applied toward increasing the functionality of modern game-computing programs (particularly in this context, 'chess engines'): specifically, I am talking about the idea of "win/draw/loss".

 

 From any given chess-round scenario (complete with board position and relevant details of castling potential, presence of any en-passant square, and most importantly which side to move; secondary relevance to clocks' status and ignoring info on tournament setting), most modern chess engines today will assess the data input to compute a 'best' move output utilizing its allocated processing power and user-defined settings such as search-depth, performing milions of calculations per second based on the algorithms programmed into the engine's software to determine an optimal 'score' that can be attained on the given turn assuming likewise_algorithm-defined optimal gameplay by the opposing side, thereby selecting the highest-scoring move that it considered during its computations. Along with this singular move nomination, it will likely also output, for the human user's convenience, a string or 'mainline' of moves to follow per the engine's calculations or assumptions of 'best move's reasoning unto either side, and more helpfully an approximate 'score' assignation to that half-turn's move based on its algorithms (considering positional / strategic and tactical aspects), where '-3.48' would rank the side that just moved at a disadvantage of just shy of three-and-a-half pawns' worth, '+4.00' an advantage of four pawns even, '0.00' being assessibly total equivalence, '-M7' indicating the opponent should checkmate your side within seven moves, and '+M11' that your side to checkmate the opposing within eleven moves.

What I propose is to design an engine that, or update a current one with functionality which enables the user to make it, out-put not just a singular move along with a score and sequence of 'relevant' moves but *multiple* first-move possibilities (not necessarily all the possible ones in a given position, since that would often be over a hundred or at least dozens, most of which completely idiotic), and categorize them according to merit, depending in part on the engine's current assessment of that side's present standing in the game.

There are many possible categories. The three broadest could be assessment of likely final outcome of the round after a particular move provided non-imperfect gameplay from both sides:

1. theoretical win

2. theoretical draw

3. theoretical loss

along with the engine's assessment of that side's standing per the same reasoning *before* it moved (i.e. directly following opponent's move), which would compound to nine possibilities, with the preceding number indicating expected net change (which should be 0 outside of engine-determinable 'blunders'):

(0)-win maintain win

(-.5)-win become draw

(-1)-win become loss

(+.5)-draw become win

(0)-draw maintain draw

(-.5)-draw become loss

(+1)-loss become win

(+.5)-loss become draw

(0)-loss stay loss

Now, of course the assessment "win/loss/draw" per move is in chess (outside of seven-man endgame tablebase and 11-man partial tablebase) one based just on theory for the time being, since obviously there is no currently available 32-man tablebase for chess (whichwould become the case only upon strong-solving the game, which presently is true only for games of reatively-speaking much more limited gametrees, not counting end-game tablebases since they have more than one possible "'starting' position"); some people would assume that +/-1.5pt. assessment from a modern strong chess_engine should usually equate to an ultimate win or loss provided accurate gameplay by winning side, respectively (See:http://www.chess.com/forum/view/game-analysis/how-much-of-an-advantage-should-lead-to-a-win). That assumes, however, *accurate* play--accurate as discernible by e.g. modern software, of which human computing power is very likely to fall short in many positions ('masters' included). Even modern software likely isn't able to accurately assess a _theoretical_ nature of win/loss/draw, beyond simply assigning a few values such as the +/1.50 figure and maybe a few weights based on progression of the game (i.e. opening - middlegame - endgame), where a '1-point advantage' would carry more weight toward late middlegame --which is probably a moot point anyhow, since engines already consider this in their algorithms (someone who recalls, point-out the term, if you would), e.g. assigning more value to pass-able pawns later in the game, deriving scores in the +/-40-55pt. range in some scenarios just shy of a discernible c'mate. The only occasion where modern engines currently will determine what the end result of a game _must_ or *really should* be prior to the actual conclusion is when it detects "mate-in-nn moves", which it will output as "+/-M[nn]"; this, however, is definitive and not 'theoretical'.

Perhaps, then, another *more* useful categorization of candidate moves that a not-too-distant chess engine could organize for its future users would be based on "number of practical response moves": or, in a matter of speaking, how 'forcing' a move is (either by the opponent or one being considered on the computer's side), at various search-depths[ which would likely often reveal the end of a 'forcing sequence' given by the engine, that is when the number of 'viable moves' blooms back open and at what assessed point change--a concept which need not apply strictly from just plydepth1-on, but for subdepths e.g. a tactical sequence that occurs between 3-8 branches deep of the gametree birthed at respective move0]--- which, in concert with its standard point-value assignations, would be extremely helpful as a learning / review-expediting aide. Currently this can be done in effect by reviewing a round on your choice of chess_engine, going as far in depth on as many different variations as you care to spend from a given position -- which is fine and well but also quite tedious so therefore not too practical for sub-masters.

As an example, take the perfectly sound opening B06, the 'Robatsch defence' or 'modern defense', which is defined by 1.e4 g6. Although this high-wire act is perfectly sound, someone who is not experienced playing it as Black will not know how to navigate all the traps that zhe can fall into against White's moves; having not played thousands of different variations, is likely to miss an angle thus miscalculating early in the round, costing the game. This isn't surprising considering that without an Opening Book installed, Stockfish at a search-depth of 31ply assigns to White an advantage of +0.42 for its default choice-response at >6ply depth to position arrived from 1.e4 g6 (2.d4), as compared to A45 (Queen's pawn game with 1...Nf6) for under which the same automatic stipulations it chooses 2.c4 at a value of +0.17 (still slightly favorable due to White's first_move advantage and since the moves thitherto are sound, but substantially closer to neutrality). 

 

Currently Stockfish (and I am presuming Komodo, Houdini, et cetera) does include some other useful outputs in its computation: at each completed search_depth, in addition to net score it lists time spent calculating, data per sequence, lines searched, and most importantly a + or - on sub depths where its output value changes (e.g. a + at 24/35 for -0.82 from -0.91 at 24/34 or a - +0.95 at 28/42 from +1.01 at 28/41), at depths above 22-ply or so.  

Along this same reasoning, to expand on my idea of searching for multiple moves, it would be nice to output perhaps some +/- assessments obviously per each given candidate move at maximum searched depth, but furthermore per each depth within per candidate move. Naturally this would take a lot more time than going-about using current engines under present normal-type settings, but not _that_ much considering how much longer it takes to thoroughly calculate a gametree at a depth 28-ply (or half moves) compared to just 27 yet still takes only a few minutes on modern processors. For added functionality, perhaps program an option for the user to choose which list that zhe wants to analyze, so the engine knows how its operator wants it to allocate its resources (e.g., just show moves based on number of 'sound'[which could be further defined] responses, just show moves based on total score at depth 18ply, just show moves based on how much +/- changes depending on searchdepth up_to 18ply[, the more swift of changes implying perhaps deep tactical complexities as compared to more consistent continuations implying strategic positional developments?], or any overlapping combination of its human_user's choosing).

Victamon

I do use the term "non-imperfect play" (in lieu of which 'flawless' might also be apt) intentionally as opposed to "perfect play", since the notion of "perfect play" can imply only one possible move response, which is not usually the case (outside of obvious tactics or forcing moves / checks..), whereas the concept "non-imperfect gameplay" clearly allows for any move that would not deviate from a {theoretical} 'win' to a 'draw'/'loss' or 'draw' to a 'loss' and would always opt for an improvement of, e.g., "'loss' become 'win'" over "'loss' become 'draw'" over ""'loss' stay 'loss'", given a round's scenario that allows for such; within those confines, any move could be considered 'accurate' or "non-imperfect": some simply require stricter paths assuming accurate (or some cases, simply decently strong) responses by opponent's side.

 

ideas, comments, retorts?