Author: Stuart Cracraft
Date: 13:27:16 03/08/06
Go up one level in this thread
On March 07, 2006 at 21:47:40, Robert Hyatt wrote: >On March 07, 2006 at 18:53:05, Stuart Cracraft wrote: > >>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 > > >Asymmetry is an evaluation issue only, in this context. It catches errors in >the evaluation code that are unintentional. If you invert the board completely >across the horizontal axis, the score should invert also. If it doesn't you are >doing something for white you are not doing for black, or vice-versa. > >asymmetry in the search is a different issue. You might extend more for white >than for black, or more for the program than for the opponent, or vice-versa. >That can cause a different type of problem... > >Asymmetry is OK if you know it is there and are using it for a reason. For >example, prior versions of crafty had asymmetry with respect to king safety. I >did it for a reason. That doesn't hurt a thing so long as you know it is there >and it is intentional. You don't want to misevaluate a position just because >you do something for the white pieces that you don't for the black pieces, >unless you do that intentionally... (for reasons I can't imagine at the >moment). Thanks.
This page took 0.01 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.