H. G. Muller wrote on Tue, May 21, 2019 07:25 AM UTC:
It would be really, really awesome to make it smart enough that, when a game starts, even if it is a user-define game through an include file, it does enough endgame table generation to make some basic decisions about this stuff, but that is probably a long way off.
I think Sjaak II makes an attempt at that. Of course there are some cases where this is obvious, such as not attacking any orthogonally adjacent squares. Beyond that heuristics quickly get as complicated as a single iteration of EGT generation, meaning that code-wise there is litlle to gain, and you might as well put the loop around it to do the full generation, if you can afford it timewise. Without full generation you would probably never see that a Silver General has no mating potential, or that the forced mate with a 'Turtle' (fhNfAbF) is almost entirely cursed because it takes on average 100 moves.
This is not out of the question; even the JavaScript generator in the checkmating applet typically needs under 100 msec to solve a 3-men 8x8 ending. And you could have the engine maintain a file where it 'caches' the conclusions from such EGT generation on disk. It could consult that file whenever a new variant is selected (or even just at the start of every game), to see if it contains data on all of the participating pieces, and if not, generate the EGT and add the data. With such a design it could even be acceptable to generate all 4-men of the participating pieces, to know what in general draws what, and which pairs of minors can checkmate. It only means that first time you use a newly defined variant it takes a few minutes to start.
A nasty aspect of EGT generation is that you don't just need the normal moves of the piece, but also the retrograde moves. For point-symmetric leapers and sliders these are the same, and even for asymmetric pieces you can just use the flipped version of the piece for the retrograde moves. But for bent sliders the moves are fundamentally different, and would need a separate provision in the move generator.
I think Sjaak II makes an attempt at that. Of course there are some cases where this is obvious, such as not attacking any orthogonally adjacent squares. Beyond that heuristics quickly get as complicated as a single iteration of EGT generation, meaning that code-wise there is litlle to gain, and you might as well put the loop around it to do the full generation, if you can afford it timewise. Without full generation you would probably never see that a Silver General has no mating potential, or that the forced mate with a 'Turtle' (fhNfAbF) is almost entirely cursed because it takes on average 100 moves.
This is not out of the question; even the JavaScript generator in the checkmating applet typically needs under 100 msec to solve a 3-men 8x8 ending. And you could have the engine maintain a file where it 'caches' the conclusions from such EGT generation on disk. It could consult that file whenever a new variant is selected (or even just at the start of every game), to see if it contains data on all of the participating pieces, and if not, generate the EGT and add the data. With such a design it could even be acceptable to generate all 4-men of the participating pieces, to know what in general draws what, and which pairs of minors can checkmate. It only means that first time you use a newly defined variant it takes a few minutes to start.
A nasty aspect of EGT generation is that you don't just need the normal moves of the piece, but also the retrograde moves. For point-symmetric leapers and sliders these are the same, and even for asymmetric pieces you can just use the flipped version of the piece for the retrograde moves. But for bent sliders the moves are fundamentally different, and would need a separate provision in the move generator.