Author: Uri Blass
Date: 09:22:41 01/09/04
Go up one level in this thread
On January 09, 2004 at 11:24:38, José Carlos wrote: >On January 09, 2004 at 11:05:40, Uri Blass wrote: > >>On January 09, 2004 at 10:30:11, Uri Blass wrote: >> >>>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 >> >>I can add that it is even worse in the following position >> >>[D]7k/2R5/8/2r5/8/2p2q2/1K6/2R5 w - - 0 1 >> >>SEE of crafty is going to say that Rxc3 is winning a pawn when it is losing a >>rook. >> >>Smallest attacker first simply may be wrong when you do a lot of captures in the >>SEE and it is a good reason to consider limiting the number of captures in the >>SEE. >> >>If you cannot trust the result then it may be better not to spend time on >>calculating it. >> >>Uri > > But there's no risk of missing something, only of searching some more nodes. >Since you (first) believe the capture is good, you'll search it further, and see >you were wrong. > An example when you believe the capture is bad when it's not would be more >dangerous, because you'd prune that capture and miss a good line for you. > > José C. I can also generate an example when you believe that a capture is bad when it is not bad [D]2q4k/2r5/8/2R5/1P6/2p2r2/1Q6/K1R5 w - - 0 1 R1xc3 is a good capture because of Rxc3 Qxc3 but SEE may evaluate it as bad capture and prune it because see is not going to calculate capture with the queen. Uri
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.