Author: José Carlos
Date: 09:48:06 07/25/03
Go up one level in this thread
On July 25, 2003 at 12:32:49, Uri Blass wrote: >On July 25, 2003 at 12:13:16, José Carlos wrote: > >>On July 25, 2003 at 11:30:56, Uri Blass wrote: >> >>>On July 25, 2003 at 11:15:25, José Carlos wrote: >>> >>>>On July 25, 2003 at 10:52:41, Uri Blass wrote: >>>> >>>>>On July 25, 2003 at 10:31:20, José Carlos wrote: >>>>> >>>>>>On July 25, 2003 at 08:10:47, Uri Blass wrote: >>>>>> >>>>>>>On July 25, 2003 at 04:34:35, Amir Ban wrote: >>>>>>> >>>>>>>>On July 25, 2003 at 02:41:22, Dann Corbit wrote: >>>>>>>> >>>>>>>>>Now, a qsearch ending in checkmate may or may not really be a checkmate. After >>>>>>>>>all, we only tried certain moves and it could very well be that the checkmate >>>>>>>>>could be avoided. >>>>>>>>> >>>>>>>>>So, the burning question is... >>>>>>>>>What should we do when the qsearch ends in a mate? >>>>>>>>>There are lots of alternatives, from the primitive "return a mate" to "send a >>>>>>>>>danger signal up the tree and let the regular search deal with it" to >>>>>>>>>"extending" to... >>>>>>>>> >>>>>>>>>What is your favorite choice and why? >>>>>>>> >>>>>>>>I don't see where opinion comes in. In a node where all legal moves are not >>>>>>>>considered static eval is the minimum. >>>>>>>> >>>>>>>>Amir >>>>>>> >>>>>>>I think that it is not so simple. >>>>>>> >>>>>>>Suppose you find in the qsearch that all captures are losing because of >>>>>>>checkmate. >>>>>> >>>>>> You miss the point. It's not that all captures lead to checkmate, it's that >>>>>>you don't detect checkmates. >>>>> >>>>>There are programs that detect checkmate in the qsearch. >>>>> >>>>> Particularly, Amir was talking about a position >>>>>>with no captures out of check. If you don't try all legal moves, you don't know >>>>>>if you're checkmated. >>>>> >>>>> >>>>>I assume in this discussion that the program knows that it is checkmated in a >>>>>leaf position. >>>>> >>>>>Movei knows for a leaf position if it is a checkmate or not a checkmate. >>>>> >>>>> >>>>> You can assume it if you want, but I don't think that the >>>>>>probability of capturing the checking piece, or capturing something to go out of >>>>>>check, is bigger than 0.50 for all in-check positions, thus you're gonna make >>>>>>more than 50% mistakes. >>>>>> >>>>>> José C. >>>>> >>>>>I was not talking about a situation when the king is in check and I think that >>>>>Dann also was not talking about it because he talked about checkmate. >>>>> >>>>>I will explain it by a diagram >>>>>suppose the following position is a position when qsearch is called >>>>> >>>>>[D]r3qrk1/5p1p/7Q/5B2/8/4P3/R4PPP/6K1 b - - 0 1 >>>>> >>>>> >>>>>You analyze Rxa2 Qxh7# >>>>> >>>>>What is the value that you return from qsearch. >>>>> >>>>>You can return the evaluation of the root and you can be more passimistic >>>>>because you detect checkmate in the search. >>>>> >>>>>I think that Dann meant to this in the original post because he said in the >>>>>original post >>>>> >>>>>"Now, a qsearch ending in checkmate may or may not really be a checkmate." >>>>> >>>>>He did not say >>>>>"Now, a qsearch ending in check may or may not really be a checkmate." >>>>> >>>>>Uri >>>> >>>> I don't think Dann meant that, because the answer would be obvious. If you >>>>_know_ that the position is checkmate, what could be the reason for not >>>>returning checkmate?. If the reason is the qsearch is selective, then you >>>>couldn't return checkmate anywhere in the tree (nobody uses pure minimax). >>> >>>No >> >> Yes. >> >>>I can return checkmate if the first move of the qsearch is leading to checkmate >>>but I cannot do it for the root position if only the second move that is a reply >>>to capture does it. >> >> Anywhere in the tree where you stop the search because it's checkmate you can >>return it, and you should return it. > >Yes but the question is what to return for the root position of the qsearch. > > > All the tree is selective, so I don't mind >>if you've discarded non capturing moves or a null move that failed high or a >>position where eval = Beta + 1000. It's exactly the same concept. You have a >>tree you search as you want. You have leaf nodes you must evaluate and return >>the score. Checkmate is the maximum evaluation for a chess tree. >> On the other hand, if you use fail hard, you won't see checkmate scores but in >>the leaves, because you'll always return alpha or beta. In that case, you can >>return beta in a checkmate position, but just because of the algorithm. >> >>>practically I do not generate captures if the score is above beta but simply >>>return beta >> >> That's how qsearch works. >> >>>and if the score is behind alpha then I return alpha >> >> I don't follow here. If the score is below alpha, you can still raise it by >>trying captures, so it's absurd to return alpha. > >I know >I meant only for cases when there is no good capture. >I thought about the relevant case of the diagram when the only capture is losing >because of checkmate so if the score of the root position is below alpha I >return alpha and if the score of the root position is above beta I return beta >without seeing the mate and the only case when changing the evaluation based on >seeing mates in the qsearch can happen when the score of the root position is >between alpha and beta. > >Uri That's correct in the framework of fail hard. But if you do fail soft, in your diagram you'll say: static eval = x -CHECKMATE < x <= alpha score returned from capture = -CHECKMATE So I'd better not capture, I'll stop here and return my static eval, x, which is the best I can hope for if I follow this line. Whether returning x is better than returning alpha is not clear. However, that's how fail soft works, and it generates smaller trees (more cutoffs). It has other drawbacks also. José C.
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.