Henk wrote:I just found out that my engine can not finish a KQK end game. PSQ table says that King should stay in center. Don't know if that's the only reason. My engine also does not know that KK is a draw.
Draw by Kk is not so easy to fix but I give you an idea :
Henk wrote:I just found out that my engine can not finish a KQK end game. PSQ table says that King should stay in center. Don't know if that's the only reason. My engine also does not know that KK is a draw.
Draw by Kk is not so easy to fix but I give you an idea :
I was thinking about a material lookup table. But maybe too much work for now for I first want to repair/debug/test search. Also my perft tests may not be complete and I actually also want to rewrite my move generator(iterator) to make it less slow. I also should not spend too much time on this hobby. Also if you implement it sloppy to save time you may get even more bugs.
Henk wrote:I just found out that my engine can not finish a KQK end game. PSQ table says that King should stay in center. Don't know if that's the only reason. My engine also does not know that KK is a draw.
Don't worry, a lot of chess players don't know how to play this end-game.
The simplest way is to remove square value for winning pieces and give only a value for the loosing king on the border and the winning king near to him. The mate will raise up from alfa-beta.
Henk wrote:My alpha beta search without TTable used 2 minutes to solve this mate in 4 puzzle. But at least it is faster than me.
[d] rnb3kr/ppp2ppp/1b6/3q4/3pN3/Q4N2/PPP2KPP/R1B1R3 w - - 0 1
This was a fixed-depth alpha-beta search? How do you order moves? Are checking moves ordered ahead of non-checking moves? How were leaf nodes evaluated?
if (inCheck) ++depth;
if (depth == 0) return qSearch(...);
This mate-in-4 puzzle would require 7 or 8 iterations without check extension, which would still take fractions of a second with normal move ordering but can also take significantly longer with suboptimal move ordering. With check extension you solve this one within iteration 4.
Don't rewrite your move generator only for speedup, this will end up in adding new bugs without any measurable speedup. Better invest your resources in correctness and in implementing a strong search, including proper move ordering.
Henk wrote:My alpha beta search without TTable used 2 minutes to solve this mate in 4 puzzle. But at least it is faster than me.
[d] rnb3kr/ppp2ppp/1b6/3q4/3pN3/Q4N2/PPP2KPP/R1B1R3 w - - 0 1
This was a fixed-depth alpha-beta search? How do you order moves? Are checking moves ordered ahead of non-checking moves? How were leaf nodes evaluated?
Yes fixed depth alpha-beta search. My move ordering doesn't recognize checking moves. Leaf notes were evaluated material + PSQvalue. Null move pruning was disabled.
Last edited by Henk on Tue Apr 07, 2015 3:26 pm, edited 1 time in total.
if (inCheck) ++depth;
if (depth == 0) return qSearch(...);
This mate-in-4 puzzle would require 7 or 8 iterations without check extension, which would still take fractions of a second with normal move ordering but can also take significantly longer with suboptimal move ordering. With check extension you solve this one within iteration 4.
Don't rewrite your move generator only for speedup, this will end up in adding new bugs without any measurable speedup. Better invest your resources in correctness and in implementing a strong search, including proper move ordering.
I have no good ideas to improve search. LMR did not give much, futility and razoring were no gain too. But move ordering could be improved. First I have to concentrate on correctness.
Henk wrote:With TTable it uses 1 minute. But I extract PV from TTable so now I can see more moves of the solution instead of only the best move.
Doesn't that make you suspect something is badly wrong with the engine? Fairy-Max, which does not even have proper move sorting, solves this in 2.37 sec, with TT.