Author: Robert Hyatt
Date: 09:51:47 01/09/04
Go up one level in this thread
On January 09, 2004 at 12:22:41, Uri Blass wrote: >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 You are worrying about making the lug nut on one wheel perfect, when the rest of the truck is falling apart. SEE is _inherently_ inaccurate. It does not pay attention to pinned pieces, overloaded pieces, etc. It is used to choose moves and move order searched by the q-search, which is _also_ full of holes, it doesn't look at moves that pin pieces, unpin pieces, xray/skewer pieces and so forth. That's why the q-search needs to be as limited as possible, so that most of the time is spent on the part of the search that actually looks at _everything_.
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.