Author: Bruce Moreland
Date: 19:45:04 12/01/00
Go up one level in this thread
On November 30, 2000 at 14:28:28, Dan Newman wrote: >On November 28, 2000 at 12:52:57, Scott Gasch wrote: > >>Hi, >> >>I posted a couple of messages about move ordering yesterday and wanted to share >>some results from my (limited) testing. I ended up implementing the suggested >>"apparently losing captures" (MVV/LVA) after all others order. In one test >>position this resulted in a tree 200k nodes larger at 8 ply but in two others it >>resulted in a marginally smaller (under 40k nodes) tree at 8 ply. I will do >>more testing on this matter but it may be a moot point because I intend to write >>a SEE pretty soon. >> > > >I tried this with MVV/LVA a while back and had much the same result. I think >the trouble is that it sorts perfectly good captures that would cause a >cutoff to the end of the list. NxP might lose the knight, but quite often >(in the search) it will simply win the pawn (and give a cutoff). There are >lots of nonsense positions in the search where pieces are simply put enprise. You can't detect losing captures with MVV/LVA. If you sort down-captures to the end of the list, you may as well reverse your sort order, since NxP is often a good move, since the P is very often not defended. I can't imagine that this could be good. bruce >When you switch to a SEE this changes since the SEE gives a much more >accurate assesment of these "losing" captures--at least it's more often >right than MVV/LVA for this. > > >>I also did some experimenting with ordering captures that take the last moved >>enemy piece. At low search depth this seems to make some difference but at >>higher depth this heuristic actually grew the tree in all three test positions I >>tried. >> >>I also did some playing with history weight and settled on hist[x][y] += (2 << >>depth). My numbers (this is total nodes searched until ply x including plys >>1..x-1) for d2d4 d7d5 e2e4 e7e5 are currently: >> >>1. 45 >>2. 621 >>3. 3725 >>4. 14146 >>5. 38694 >>6. 183449 >>7. 598020 >>8. 1286875 >> > > >Here's what Shrike gets: > > 2 670 > 3 2363 > 4 7354 > 5 27901 > 6 103043 > 7 307139 > 8 1042687 > 9 3232257 >10 7967050 > >-Dan. > > >>I am doing null move (R=2/3 depending on remaining and normal futility pruning >>with a slightly larger than safe window on frontier nodes and in qnodes. I've >>read about extended futility pruning and razoring too. I'd be interested in >>other ideas to cut down the tree search size... be they other move ordering >>heuristics or other pruning methods that are reasonably safe. How do the nodes >>searched in the position given compare to other engines? >> >>Thanks again, >>Scott
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.