Author: Richard Pijl
Date: 02:12:23 09/25/04
Go up one level in this thread
On September 25, 2004 at 04:24:46, martin fierz wrote: >aloha! > >i made a small experiment: old root move ordering vs new root move ordering. > >old: >generate all moves. do not order. use normal search and after each completed ply >(or fail high) move the current best move to the top of the list and shift all >moves back. > >new: >generate all moves. do not order. use normal search and after each completed ply >(or fail high) move the current best move to the top of the list and order the >remaining moves by subtree size. In the Baron I do a few other things as well. First: I don't use raw subtree size, but make it relative to a constant. So the move with the largest subtree will get a score of e.g. 100. I do the same with other possible parameters, like history value (with a different constant of course), whether it is a capture or not (as captures), returned searchscore relative to adjusted alpha from the previous iteration. Then I divide the previous ordering score by two and add the new score to it, to stabilize the order of the moves. It may seem like a lot of work, but better rootnode move ordering will save you a few nodes in positions where the pv will change regularly. >results on centrino 1.4GHz: >- test set ECMGCP 5s/move: old 107/183 solved, new 103/183 solved I'm not surprised. In tactical test positions the solution is often a move with a small subtree in previous iterations, and is also often a capture, making it examined earlier with regular move ordering schemes. Richard. >- matches at blitz 1'+5'' increment vs frenzee & gothmog: >old: 8-32 against gothmog, 21-19 against frenzee >new: 7-33 against gothmog, 20-20 against frenzee > >(i really shouldn't be testing against gothmog, it's way too strong for my >engine, but i believe you learn more from losses than wins and this is a good >way to generate lots of losses...) > >conclusion: the "improved" new root move ordering did worse both in matches and >in the test set. obviously the difference is far from significant and more games >would be needed to prove anything. but overall i am a bit disappointed that it >didn't do better in any of the 3 tests. > >cheers > martin
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.