Author: Robert Hyatt
Date: 18:50:58 01/09/04
Go up one level in this thread
On January 09, 2004 at 13:15:50, Uri Blass wrote: >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 I've done the q-search both ways. I took the checks _out_ just before the Jakarta WCCC. Both Bruce and I played a _lot_ of games with and without and we could find no difference, strength-wise. But if you want to do checks, there's certainly nothing bad wrong with it. But there _are_ positions where a check or capture is not the best move, and you will get those wrong _still_...
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.