Author: Sune Fischer
Date: 07:46:25 09/10/03
Go up one level in this thread
On September 10, 2003 at 10:18:34, Dave Gomboc wrote: >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. For real (and good) programs it is, certainly not for the academic fixed ply searches. A delta peaked search to fixed ply is one of the most in efficient trees possible, it would suffer from the horizon effect to its full degree. IMO it is a big mistake to compare or expect this effect to plague real chess programs. The idea with the search is to evaluate each move as precisely as possible. So when you see scores jumping all over the place at every other ply, it is a tell-tail sign of a systematic instability near the horizon. That is not to say that some positions aren't harder to quiesce accurately than others, of course :) -S. >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.