Author: Stuart Cracraft
Date: 15:53:05 03/07/06
Go up one level in this thread
On March 07, 2006 at 18:05:24, Tord Romstad wrote: >On March 07, 2006 at 16:01:57, Dann Corbit wrote: > >>Fruit uses late move reductions, and yet the search is perfectly symmetrical. > >No, it is not. See the following output from Fruit 2.1: > >First I ask the program (freshly started, with default settings) to analyse >the initial position to depth 5: > >position startpos >go depth 5 >info depth 1 >info depth 1 seldepth 1 score cp 26 time 0 nodes 2 pv b1a3 >info depth 1 seldepth 1 score cp 54 time 0 nodes 3 pv b1c3 >info depth 1 seldepth 1 time 1 nodes 21 nps 0 >info depth 2 >info depth 2 seldepth 2 score cp 0 time 1 nodes 44 pv b1c3 b8c6 >info depth 2 seldepth 2 time 1 nodes 82 nps 0 >info depth 3 >info depth 3 seldepth 3 score cp 54 time 1 nodes 148 pv b1c3 b8c6 g1f3 >info depth 3 seldepth 3 time 1 nodes 186 nps 0 >info depth 4 >info depth 4 seldepth 6 score cp 0 time 1 nodes 300 pv b1c3 b8c6 g1f3 g8f6 >info depth 4 seldepth 6 time 2 nodes 976 nps 0 >info depth 5 >info depth 5 seldepth 9 score cp 48 time 4 nodes 1729 pv b1c3 b8c6 g1f3 g8f6 >d2d4 > >After a restart of the program, I try the same position with black to move: > >position fen rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR b KQkq - 0 1 >go depth 5 >info depth 1 >info depth 1 seldepth 1 score cp 4 time 0 nodes 2 pv a7a5 >info depth 1 seldepth 1 score cp 10 time 0 nodes 4 pv b7b5 >info depth 1 seldepth 1 score cp 52 time 1 nodes 8 pv d7d5 >info depth 1 seldepth 1 score cp 54 time 1 nodes 19 pv b8c6 >info depth 1 seldepth 1 time 1 nodes 21 nps 0 >info depth 2 >info depth 2 seldepth 2 score cp 0 time 1 nodes 44 pv b8c6 b1c3 >info depth 2 seldepth 2 time 1 nodes 82 nps 0 >info depth 3 >info depth 3 seldepth 3 score cp 54 time 1 nodes 148 pv b8c6 b1c3 g8f6 >info depth 3 seldepth 3 time 1 nodes 186 nps 0 >info depth 4 >info depth 4 seldepth 6 score cp 0 time 1 nodes 300 pv b8c6 b1c3 g8f6 g1f3 >info depth 4 seldepth 6 time 3 nodes 979 nps 0 >info depth 5 >info depth 5 seldepth 10 score cp 48 time 4 nodes 1743 pv b8c6 b1c3 g8f6 g1f3 >d7d5 > >As you can see, the search isn't entirely symmetrical. The node counters and >the selective search depths differ. If you repeat the experiment with Fruit >2.2, >you will see the same thing. > >Tord Okay so now I am completely confused. My PVS/Hash/Nullmove/Late Move Reduction/Various Extensions/SEE program can't be tested with this method is what you are saying or not? How can I test for asymmetry? Using simply the flip and flop for any larger number of FEN/EPD's? I am more than happy to write flip and flop and evtest and put them into my program with those same names but want to invest the time only if the search method of running against the 4 published pre-rotated positions is not good. On the other hand, maybe I should just read in those positions, evaluate each of them and if the score isn't the same, excepting the flip with the sign-change, then flag it. Still, that is only one or two positions, not enough test sample. Suspecting bugs in my eval and search, I need debugging methods my brethren. Certainly evtest/flip/flop (hereafter called EFF) will be on my list to do. Not too hard to implement and uncovers a monster issue. One last question: why does asymmetry screw up the search so much? Many parts of computer chess operation seem to be slightly or moderately forgiving. But not asymmetry. Why? Stuart
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.