Author: Tom Likens
Date: 07:27:32 09/22/02
Go up one level in this thread
On September 21, 2002 at 23:35:09, Robert Hyatt wrote:
>On September 21, 2002 at 12:20:24, scott farrell wrote:
>
>>I was just fiddling with my move ordering (as we all do from time to time).
>>
>>I found that my MVVLVA code worsened (is that a word?) my move ordering, and
>>slow my searches significantly.
>>
>>I altered it to just simply ordering the capture by the size of the material it
>>is to take, disregarding the size of the piece to perform the capture.
>>
>>As far as I know current wisdom for move ordering is something like this:
>>1. from hastable first
>>2. killers next
>
>No.....
>
>hash move first.
>
>winning captures next...
>
>then killers
>
>Not in the reverse order. The most common refutation of all is a capture,
>the killers are a very poor second place to that.
>
>Note that a good capture can be the hash move, so that doesn't invalidate my
>last statement.
Bob may have already mentioned this, but it is also worthwhile not to search the
same moves multiple times. You usually will have to take some precautions so
that
the move returned by your hash table probe is not researched if it fails to
produce
a cut-off. In fact, this generally holds true for any moves that are retained
between
searches. If you're not careful your normal move generator will reproduce these
moves and your engine will faithfully research them.
If you don't have it already, adding a debug option to your program that allows
it
to print the trees being searched is really useful. It's amazing the amount of
redundant effort that can show up once you start adding new features to your
engine.
The only caveat, is be careful the first time you enable it since it will fill
up your
hard-drive *very* quickly :(
regards,
--tom
>>3. winning captures ordered by MVVLVA
>>4. other moves
>>5. losing captures
>>
>>My updated move ordering is:
>>1. from hastable first
>>2. killers next
>>3. all captures, ordered by the size of the captured piece (largest first), and
>>ties broken by size of attacker only
>>4. other moves
>>5. losing captures
>>
>>I havent looked into to hard just yet, but I am pretty sure its got something to
>>do with search extensions, and recapture extensions. Running all the captures
>>first allows the extensions to kick in quickly and cause lots of nice cutoffs.
>>
>>The other thing it might be is a bug in my code - and turning off the MVVLVA
>>ordering of capture bypassed the bug, but its only a few lines, and I dont think
>>there is any bugs.
>>
>>What do you all think? am I crazy, do I have a bug, or are some programs already
>>doing this?
>>
>>Scott
>>
>>Here is my old code:
>>
>> if (moves[depthTree][i].capture > 0)
>> {
>> //black is capturing a white piece
>> if (b.isAttacked(moves[depthTree][i].s2, Board.WHITE))
>> moves[depthTree][i].searchOrder
>> += (Board.pieceValues[moves[depthTree][i].capture]
>> - Board.pieceValues[
>> - moves[depthTree][i].piece])
>> * 100000 ;
>> else
>> //enpris
>> moves[depthTree][i].searchOrder
>> += Board.pieceValues[moves[depthTree][i].capture]
>> * 100000 ;
>> } else if (moves[depthTree][i].capture < 0)
>> {
>> //white is capturing a black
>> if (b.isAttacked(moves[depthTree][i].s2, Board.BLACK))
>> moves[depthTree][i].searchOrder
>> += (Board.pieceValues[-moves[depthTree][i].capture]
>> - Board.pieceValues[moves[depthTree][i].piece])
>> * 100000 ;
>> else
>> //enpris
>> moves[depthTree][i].searchOrder
>> += Board.pieceValues[-moves[depthTree][i].capture]
>> * 100000 ;
>> }
>>
>>
>>and my new code that is much much better at ordering:
>>
>> if (moves[depthTree][i].capture > 0)
>> {
>> moves[depthTree][i].searchOrder
>> += (Board.pieceValues[moves[depthTree][i].capture] +
>>moves[depthTree][i].piece)
>> * 1000;
>> } else
>> {
>> moves[depthTree][i].searchOrder
>> += (Board.pieceValues[-moves[depthTree][i].capture] -
>>moves[depthTree][i].piece)
>> * 1000;
>> }
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.