Author: scott farrell
Date: 19:03:57 09/21/02
Go up one level in this thread
On September 21, 2002 at 13:33:46, Andreas Guettinger wrote:
Thanks for looking at my code,
I think the second set of code does exactly what you suggested.
Thanks
Scott
>On September 21, 2002 at 12:20:24, scott farrell wrote:
>
>While i looked at you code, i had th impression that you implemented MMV/LVA not
>correctly. You do a pieceValue[victim] - pieceValue[attacker] for determining
>your mvvlva value. Instead for mvvvlva do something like this:
>
>value = pieceValue[victim] - attacker;
>
>where pieceValue for example is:
>queen = 900
>rook = 400
>bishop, night = 300
>pawn = 100
>(or the values you use)
>
>but for attacker take:
>pawn = 1;
>knight = 2;
>bishop = 3;
>rook = 4;
>queen = 5;
>
>
>In this case, the value of a pawn capturing a queen is 900-1 = 899 an will be
>prefered over a knight capturing a queen 900-2 = 898. This should improve your
>sorting.
>
>regards
>Andy
>
>
>
>
>
>>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
>>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.