Author: Sune Fischer
Date: 18:02:49 09/09/03
Go up one level in this thread
On September 09, 2003 at 14:06:42, Knut Bjørnar Wålberg wrote: >Your friend remembers correctly, there is something mentioned in the T-notes >from June 29th 2003 (http://www.chessbase.com/support/support.asp?pid=271): > >-"Skip even plies" changes this behavior somewhat. If you set the dialogue for >"9" through "13" and check this box, you'll get just three games instead of >five: it will play games using search depths of nine, eleven, and thirteen plies >-- skipping over "10" and "12". There's a reason for using this setting: some >chess engines (particularly older ones) become somewhat tactically "blind" at >even-ply search depths (they fail to consider responses to surprise moves by the >opponent and neglect defense a bit). So you'll tend to get better play with >these older engines if you check the "Skip even plies" box. > >And I found a brief explanation >(www.cs.ualberta.ca/~games/articles/aphidacc.ps.gz): >-Many game-tree search programs exhibit an effect based on the parity of the >search depth (odd or even number of ply). Scores are stable when you look at >results from the odd plies only, or even plies only, but are sometimes unstable >when you mix the two. Thus, we use the largest ply value with the same parity, >instead of always using the largest ply value available. > >...which makes sense. Then finally a paper by among others Aske Plaat >(http://www.cs.vu.nl/~aske/Papers/optim.pdf): >-An interesting feature is that all three programs, Othello and chess in >particular,have significantly worse performance for even depths. The reason for >this can be seenif we look at the structure of the minimal tree. In going from >an odd to an even ply,most of the new nodes are nodes where a cutoff is expected >to occur. For the minimalgraph, their children count as just one node access. >However, the search algorithmmay have to consider a number of alternatives >before it finds one that causes the cutoff.Therefore, at even plies, move >ordering is critical to performance. On the other hand,in going from an even to >an odd ply, most of the new nodes are children of nodes whereno cutoff is >expected. All of the children are part of the minimal graph. Hence, at >thesenodes move ordering has no effect since all children have to be searched >anyway.The preceding leads to an important point: reporting the efficiency of a >fixed-depthsearch algorithm based on odd-ply data is misleading. The odd-ply >iterations givean inflated view of the search efficiency. For odd-ply searches, >all three programs are searching with an efficiency similar to the results >reported for other programs.However, the even-ply data is more representative of >real program performance and,on this measure, it appears that there is still >room for improvement. In light of this, theHitech results of 1.5 for 8-ply >searches seem even more impressive [3]. > >The explanation above seems ok, but I'm not among the most qualified on these >boards to comment. Oh, BTW, all quotes found by the help of Google. :) IMO that is pure nonsense, for real chess programs anyway. In fact, if you see this in your program then you know your q-search is not good enough - per definition you can almost say, because this is the kind of instability effect a q-search should eliminate. But not only the q-search should help combat this, the whole search should (probably) be bell-shaped around the ply-depth. For good engines I'd expect this bell to be rather flat and smooth. Admittedly I've never extracted this curve from my own program, but maybe I should... :) -S.
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.