Author: Mark Young
Date: 16:38:43 05/19/99
Go up one level in this thread
On May 19, 1999 at 14:25:38, Dave Gomboc wrote: >On May 19, 1999 at 08:05:28, Mark Young wrote: > >>On May 19, 1999 at 02:55:48, Dave Gomboc wrote: >> >>>On May 18, 1999 at 22:52:23, Mark Young wrote: >>> >>>>On May 18, 1999 at 22:18:47, Dave Gomboc wrote: >>>> >>>>>Some balance here is necessary. Some people are content to say that if a move >>>>>is selected as best, this is good enough. Other people insist on seeing a score >>>>>accompanying the move that accurately reflects the theoretical value of the >>>>>position after the move is played. >>>>> >>>>>It is important that an accompanying score is accurate. This certifies that the >>>>>software has seen its way through whatever complications may be present. >>>>>Changes to the position that do not interfere with the themes that support the >>>>>main line of play will not prevent a solution from being found. >>>>> >>>>>It is important that the best move is played, even if the accompanying score is >>>>>not accurate. This certifies that the software understands enough about the >>>>>position to make its way forward correctly -- for the moment. It is useful to >>>>>identify that a move is likely to be the most promising, even if a definitive >>>>>conclusion has not been reached. >>>>> >>>>>It is fair to say that the while the former is better, the latter is often >>>>>adequate. If the software's assessment of a position is highly perturbed by >>>>>"small" (read: irrelevant) changes to a position, then it could be said that >>>>>much "luck" is involved in it choosing a particular move or another. More >>>>>often, though, assessments do not vary widely between positions with "small" >>>>>(again read: irrelevant) changes, and in this case, it is partially the >>>>>consistency of the assessing that allows the proper move to frequently be >>>>>chosen, even without the discovery of a tactical verification, or tactical >>>>>refutation of alternatives. >>>>> >>>>>So, in testing, prefer a proper score, but do not ignore a proper best move >>>>>without a proper score. It is still doing something right: give it half credit. >>>> >>>>What is the proper score, any + score, a huge +score....the only proper score of >>>>a winning positions is mate in n. >>>>> >>>>>Dave >>> >>>This is a valid question. I think that a "proper score" is one that is high >>>enough relative to the alternative scores that a certain path is absolutely >>>guaranteed to be selected (including from perturbations of the position to be >>>played from.) This is different from the usual notions of "seeing that it can >>>win the piece", et cetera: a sufficient, but not necessary criteria for matching >>>my "good enough" score. >>> >>>If the scores for all of the moves but the best one are abysmal, then it has >>>found that only one move is playable, even if you don't see that it wins (or is >>>actually not good enough anyway!, but is still the best move because it holds >>>off a resignable position as long as possible.) If the scores for four or five >>>moves are roughly even, this isn't really good enough to score "full points" >>>IMO. >>> >>>We can see that if the program reaches a position that it presumed to be okay >>>(in an earlier search), but sees that it is resignable when it gets there, it's >>>toast. Finding a "proper" score at some earlier stage would have allowed it to >>>avoid the error completely by not playing to the bad line. The major idea >>>behind singular extensions is to see what is happening at the "end of the >>>tunnel": you can see those fail-highs and fail-lows early enough that you can do >>>something about them (head towards the position, or avoid it.) Programs that >>>see "proper scores" from further back in the game are going to be stronger than >>>those that don't, ceteris paribus. >> >>So what you are saying is the program has to see it tacticly, or it does not >>count. Programs have other aspects to them then just there search, and I see >>nothing wrong with a program finding the correct move by seeing the other line >>get killed, instead of seeing this one move wins. > >This is something that I definately did not say. At least, I tried to be very >careful not to. In some positions with some chess engines, even a steady >one-third of a pawn difference might be enough to make such a guarantee. The >margin of difference required depends on the position and on the engine. > >>You did not really answer the question, and we are back at square one. All of >>what you are saying is subjective thus anyone can reject any BM played by any >>program producing almost any score. You are trying to split the baby and I don't >>think it can be done. >> >>You need to show me how this is workable with some examples. > >I am not about to enter a comprehensive scientific experiment to do so, sorry. Exactly, it not so cut and dry your solution. > >>>Dave > >Dave
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.