Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: hard question about SEE and crafty - it only needs 4 iterations ?

Author: Robert Hyatt

Date: 06:58:54 01/09/04

Go up one level in this thread


On January 09, 2004 at 05:36:57, Sune Fischer wrote:

>
>>>>I hope the 2 statements above are sound.
>>>>
>>>>The next part of my argument is I think you only 3-4 entries in the array, and
>>>>you dont need to iterate all pieces, just the first 1 or 2 captures each
>>>>(depending how you count them - and if you count the first one or not).
>>>>
>>>>
>>>>after the initial capture, the other side either has a good capture, or they
>>>>dont. To determine if there is a good capture or not, I dont see that we need to
>>>>pile a nearly unlmited number of pieces on. The minimax could would need a
>>>>slight tweak to disregard the last capture I think.
>
>You can make the sequence shorter if you only want to know if it's a winner or
>loser, but not if you want to know how much it wins or loses (AFAICT).
>
>E.g. PxQ is clearly a winner so we can stop right there, but do we lose the pawn
>or not?
>
>I had this check in at one point, you just need to see that your current gain is
>higher than the value of the last piece you captured with, so even if you stand
>to lose that you are still ahead.
>

I do this in my q-search now.  If a piece captures a piece of equal or less
value, I use SEE to analyze the expected gain/loss.  If a piece captures a
piece of greater value, I just assume the gain is captured - capturing and
skip SEE to save time.




>>I also noticed that the order of using sliding pieces, say rooks can matter, and
>>crafty chooses them randomly. Say one Rook reveals no hidden attacker, and the
>>other reveals a Rook, OR, one reveals a Q, and one reveals a R, this must surely
>>have an outcome that would be different if you randomly selected the other rook
>>to start with. or maybe there is no difference, as it is unlikely to be a
>>smaller piece, which is the only case that upsets the apple cart. Larger
>>revealed pieces dont change the order at all, they go to the end of the queue,
>>even reveals pieces (rook reveal rook) dont change the order either. A Rook can
>>only reveal rooks or queen, bishops can only reveal bishops or queen, the queen
>>is the only piece that can reveal smaller pieces, and it is unlikely to have 2
>>Queens in which that is the only case you can reveal a smaller piece. So the
>>order of queens capturing is the only place where this can go wrong.
>
>The order of captures does matter actually, Rfxc3 wins a rook while Rcxc3 is
>just an equal capture.

How can that matter?  The next cycle will use the other rook and since we are
only looking at one square, the order you use rooks is immaterial.  If they
uncover a queen, the queen won't be used until _both_ rooks have been used,
no matter what gets uncovered when...



>
>[D]7k/2R5/8/2r5/8/2R2r2/1K6/8 b - - 0 1
>
>I don't think these things are important for the search, but still it is
>annoying when ones tries to debug by using symmetry validation.
>
>-S.
>>Scott
>>



This page took 0.01 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.