Desperado wrote:
The first thing i would try without changing the search would be to
modify the root's alpha beta window. I dont think we need to
search lbound to ubound or sth. like that. If we are in mate-search
mode we only need to test for mateIn(d) score. if that fails we continue
with the next depth, until we find a depth having a mate.
The first advantage i see is that in a mate search we only have to set
the root window different, which keeps the code clean. The second
point is that it should find existing mates (much) faster than the normal
search.
Hey that's a good idea. Very simple and makes a lot of sense! When I get round to implementing the UCI 'go mate x' command, I'll certainly try to do that.
Thanks!
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
I have now tried to implement this idea of bounding alpha and beta to mate values, but perhaps I am doing something wrong because I got some asserts in the search.
My first impression is that if we force the engine to fail low always until it reaches the correct depth we completely fool how move ordering, alpha beta searching and TT works, so I really don't know what to expect from this (without considering my current asserts).
ZirconiumX wrote:It depends which Fruit version you chose. Fruit 1.0 had a dedicated mate search (read full-width alpha-beta with TT) for this task. It takes its sweet time.
One think that should be easy to implement is setting ss->skipNullMove when doing a mate search - you may run into a zugzwang position - or the problem has a horizon effect.
Matthew:out
Null-move is not as big a problem as LMR. Used to be if you were searching for mate in N, you could stop after iteration 2*N - 1, but not with reductions.
Here we are talking about using the number of plies (distance from root) not the iterations as a stop criteria, so LMR is not an issue (of course you have to continue the iterative deepening indipendently from the supposed number of moves to mate).
I have tested also returning in non-pv nodes after 2*mate plies (as suggested by Robert) and it works much better than just PV because side branches return much faster.