Computer Chess Club Archives


Search

Terms

Messages

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

Author: Uri Blass

Date: 07:30:11 01/09/04

Go up one level in this thread


On January 09, 2004 at 09:58:54, Robert Hyatt wrote:

>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...


It is not going to change the evaluation of Rfxc3 but it may change the
evaluation one ply earlier if there is a previous capture to analyze.

[D]7k/2R5/8/2r5/8/2p2r2/1K6/2R5 w - - 0 1

Rxc3 Rfxc3 wins a rook for a pawn for black when Rxc3 Rcxc3 wins a pawn for
white.

If you are unlucky to search Rcxc3 in your see then you may consider the capture
as a good capture.

Uri



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.