From the current root position, you know every mating move.syzygy wrote: ↑Tue May 22, 2018 1:54 amIf that were an option, you could as well directly examine every possible path and not use any tables at all.Dann Corbit wrote: ↑Tue May 22, 2018 1:01 amIf the repetitions are avoidable, the programmer can examine every mate path calculable with the DTM50 tables.
From each child position, you know every mating move.
I expect that normally, this is a small fraction of the possible moves that can be ignored such as draws and losses (assuming that the root is a mate).
I also expect that you can examine the pv returned. If it contains any 3rd repetition or exceeds the half move clock then a recursive search of mate only positions would be needed. Otherwise, it can be used directly. So the auxiliary search should be very rare.
Perhaps my assumption about searching only mate positions is wrong, because we have to change the game state either by a reversible move or by choosing a move that does not lead to a 3 move repetition.
If, for instance, the 3 move repetition occurs, then we cannot use the mate from the root directly. But can't we just continue the search, using the tablebase file to search future mate positions as well?
It seems possible to me to create a smart tablebase with a TB engine (perhaps a shared library that has threads of execution if needed). It is given the game state and will know if it can simply return a mate or if it has to search. Considering that I do not intimately know how the DTM tables function, I could be wrong. But I do not yet understand why it cannot work.