Shame

[Daniel Anulliero]

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 :

Code: Select all

If(material [WHITE] == VAL_KING  &&  material [BLACK] == VAL_KING)
        return DRAW;

[Henk]

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 :

Code: Select all

If(material [WHITE] == VAL_KING  &&  material [BLACK] == VAL_KING)
        return DRAW;

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]

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

[stegemma]

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]

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

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.

[zullil]

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?

[Sven]

My alpha beta search without TTable used 2 minutes to solve this mate in 4 puzzle. But at least it is faster than me.

Check extension would help here.

Code: Select all

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]

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.

[Henk]

My alpha beta search without TTable used 2 minutes to solve this mate in 4 puzzle. But at least it is faster than me.

Check extension would help here.

Code: Select all

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.

[hgm]

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.

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
 14	+79.96 	3.11M  	0:03.71	e4f6 g7f6 a3f8 g8f8 c1h6 f8g8 e1e8
 13	+79.96 	2.46M  	0:03.23	e4f6 g7f6 a3f8 g8f8 c1h6 f8g8 e1e8
 12	+79.96 	2.14M  	0:02.98	e4f6 g7f6 a3f8 g8f8 c1h6 f8g8 e1e8
 11	+79.96 	1.79M  	0:02.64	e4f6 g7f6 a3f8 g8f8 c1h6 f8g8 e1e8
 10	+79.96 	1.67M  	0:02.51	e4f6 g7f6 a3f8 g8f8 c1h6 f8g8 e1e8
  9	+79.96 	1.61M  	0:02.43	e4f6 g7f6 a3f8 g8f8 c1h6 f8g8 e1e8
  8	+79.96 	1.57M  	0:02.40	e4f6 g7f6 a3f8 g8f8 c1h6 f8g8 e1e8
  7	+79.96 	1.55M  	0:02.37	e4f6 g7f6 a3f8 g8f8 c1h6 f8g8 e1e8
  7	 -2.11 	1.49M  	0:02.28	e4d2 c8e6 e1e5 d5c6 a3d3 b8d7 e5g5
  7	 -2.17 	1.21M  	0:01.87	e4g5 c8d7 e1e5 d5d6 a3d6 c7d6 e5e4
  6	 -2.02 	876812	0:01.37	e4g5 c8d7 e1e5 d5d6 a3d6 c7d6
  6	 -2.06 	513016	0:00.81	a3d3 b8c6 e4d6 c6e5 e1e5 d5d6
  5	 -1.87 	57349  	0:00.09	a3d3 f7f5 e4g5 b8c6 c1f4
  4	 -2.04 	11392  	0:00.01	a3d3 f7f5 e4g5 b8c6
  3	 -2.04 	2626    	0:00.00	a3d3 f7f5 e4g5
  2	 -2.03 	587      	0:00.00	a3d3 b8c6
  2	 -2.14 	226      	0:00.00	c1f4 d4d3
  2	 -2.23 	182      	0:00.00	c1d2 d4d3
  2	 -2.39 	149      	0:00.00	c1g5 d4d3
  1	 -1.67 	123      	0:00.00	c1g5

Micro-Max 1.6, which has no TT and no move sorting at all, only takes 8.6 sec:

Code: Select all

 97	+79.96 	37.8M  	0:08.60	e4f6
  5	 -2.04 	3.91M  	0:00.95	a3a4
  4	 -2.19 	580524	0:00.14	e4c5
  3	 -1.89 	10332  	0:00.00	c1f4
  2	 -1.98 	713      	0:00.00	c1f4
  1	 -1.83 	67        	0:00.00	c1f4
  0	 -1.98 	1          	0:00.00	a8a8