Author: Robert Hyatt
Date: 16:36:14 09/28/04
Go up one level in this thread
On September 28, 2004 at 18:44:13, Ed Schröder wrote: >On September 28, 2004 at 14:01:50, Robert Hyatt wrote: > >>Here is an example of how this _should_ work: >> >>problem: WAC 141, searched to depth-9. >> >>6 moves at root >> move score >> Kh2 -130 >> Kg1 -165 >> Kg3 -184 >> Kf1 -186 >> Rxf4 -393 >> Qxf4 -833 >> >>That is my initial root move list, in order based on the q-search result from >>each move. Note that the correct move is dead last. >> >>At the end of iteration 8, where Kf1 still looks best, the move list has been >>re-sorted to look like this: >> >> move nodes hi/low >> Kf1 971767 0 0 >> Rxf4 16372 0 0 >> Qxf4 4971 0 0 >> Kg3 1968 0 0 >> Kh2 858 0 0 >> Kg1 630 0 0 >> total 996566 >> >>Notice that Qxf4 is now up to #3, and on the next iteration it actually becomes >>the best move. >> >>If you don't use node counts, Qf4 stays at the bottom. What happens when you >>start an iteration, and run out of time 1/2 way through? You never even >>consider Qf4 and miss a winner, or actually lose. It seems important to me to >>get potential new best moves up near the top as quickly as possible... >> >>Another example: wac 230: >> >>Rb4 starts off _way_ down the list: >>16 moves at root >> move score >> Rh7 113 >> Ra7 111 >> Rf7 110 >> a4 109 >> Bd7 107 >> Rb5 102 >> Rb6 101 >> Kd7 101 >> Rd7 99 >> Rg7 97 >> Kb5 97 >> Kb6 97 >> Rc7 -97 >> Rb4 -455 >> Rb8 -491 >> Re7 -523 >> >>At the end of iteration 12 it has moved up to #2: >> >> move nodes hi/low 1. ... Rb8 >> Rh7 6120660 0 0 >> Rb4 9127160 0 0 >> a4 3038475 0 0 >> Kb5 926281 0 0 >> Kb6 576627 0 0 >> Rf7 492629 0 0 >> Rb5 398943 0 0 >> Rd7 390250 0 0 >> Bd7 274988 0 0 >> Kd7 240179 0 0 >> Rc7 143706 0 0 >> Rb6 111402 0 0 >> Rg7 85907 0 0 >> Rb8 66892 0 0 >> Ra7 40052 0 0 >> Re7 19363 0 0 >> total 22053514 >> >>I'd much rather have it up there since it should eventually become the best >>move, as opposed to having it near the bottom where we might not even consider >>it next iteration if we run out of time first... >> >>I can't imagine it hurting tactical performance since this is what such >>positions are all about (finding a move that looks bad to the casual observer >>but which wins on closer inspection). > > >Interesting idea. Are you sure it's the best way of doing things? Any speed >increase percentage to offer? In WAC 141 it is worth 1%. Not a lot. But that is for test cases. For real games it helps more for me, because I hardly ever finish an iteration, stopping whenever time runs out but always completing the current root move search before doing so. This gets likely new best move candidates to the front of the move list making it less likely they will be skipped when time runs out... > >My way of doing: after iteration one I do a full sort, after iteration 2 and up >I increment the root scores with a decreasing value first (move-1 + 256, move-2 >+ 248, move-3 +240 etc.) before I sort. This is meant to keep the order of >iteration one as good as possible and in the case certain moves had serious >score increases these moves automatically will make it to the top. > >As last item I make sure that previous best-moves are stored as second, third, >fourth in the list and finally that fail-high-errors (fail-high's that after a >research did not produce a best move) are stored as second. The node counts should guarantee that since best moves will have large node counts naturally... > >I never found a better system. I will try to mix your idea with system and see >what happens. > >My best, > >Ed
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.