Author: Dave Gomboc
Date: 07:18:34 09/10/03
Go up one level in this thread
On September 09, 2003 at 21:02:49, Sune Fischer wrote: >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. It's not pure nonsense. Not every position is tactical. Dave
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.