Author: Robert Hyatt
Date: 18:47:40 03/07/06
Go up one level in this thread
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).
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.