Author: Uri Blass
Date: 10:15:50 01/09/04
Go up one level in this thread
On January 09, 2004 at 12:51:47, Robert Hyatt wrote: >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_. I do not say that you can do the SEE accurate. The point is that if I know that it is more inaccurate with more captures then maybe it is better to stop it and have a rule to return "do not know" in part of the cases when you can decide not to prune if the optimistic evaluation after 3 captures suggest that it is a good capture. I do not think that q-search needs to be as limited as possible and you can do also checks in the first plies of the qsearch. 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.