Author: Uri Blass
Date: 19:26:54 08/05/04
Go up one level in this thread
On August 05, 2004 at 20:54:15, José Carlos wrote: >On August 05, 2004 at 20:01:29, Cesar Contreras wrote: > >>I'm trying to improve my move ordering, with a little success, principal due to >>correct my understanding and implementation MVA\LVV. I had not sucess with SEE. >>Anyway, i think my tree it's still too big. >> >>I need to know if i can do any more about it. >> >>currently i do: >> >>1.- Moves on transposition, ordered by evaluation (some one suggested me order >>by node count, why do you think?) > > I guess he meant _at the root_. In the root position of the search, you want >to try the PV move first (because your best move so far) and then all the rest, >which you expect to quickly fail low. As the world isn't perfect, you'll fail >high on a non pv move sometimes. Due to alphabeta nature, you want that to >happen as soon as possible. Node count is a good general idea, because more >nodes means "in the last iteration, it was harder to refute (fail low) this >move, so it might be good". > I use node count, but I've found better (for my program) to try previous pv >moves before. For example, in the initial position, e4 is your pv move until >iteration 7. Then you fail high on d4. At iteration 10 you fail high on Nf3. In >this case, for iteration 11, I first search Nf3, second I search d4, then e4, >and after that, all the other moves, sorted by node count. This is exactly killer moves and it can be improvement only for programs that do not use killer moves in the first ply. It was the case for old movei when I did not think about the first ply when I defined killer moves but I corrected it later. Uri
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.