Author: Robert Hyatt
Date: 20:37:49 09/21/02
Go up one level in this thread
On September 21, 2002 at 21:59:55, scott farrell wrote:
>On September 21, 2002 at 16:09:36, Tom Likens wrote:
>
>Tom,
>
>That sounds interesting, given it would allow the killer slot not to be
>overridden by obvious moves, and would make the killer move overall more useful.
>
>Very interesting indeed.
>
>Scott
Note also that a killer is a "general refutation move" that works in a wide
variety of cases. A capture is most often a refutation of a specific move
that hangs a piace (the piece moving or another one).
The point about MVV/LVA not understanding "good captures" is a critical
point. If you use MVV/LVA you should try _all_ captures first. If you
use SEE to evaluate the captures, you can just search winning/even captures
and save the "losers" for later.
>
>>On September 21, 2002 at 12:20:24, scott farrell wrote:
>>
>>Hello Scott,
>>
>>I've had more success by trying winning/even captures before killer moves.
>>Also, these same captures are never saved as killers in order to avoid
>>searching the same move more than once.
>>
>>regards,
>>--tom
>>
>>>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.