Author: Robert Hyatt
Date: 11:28:14 01/21/04
Go up one level in this thread
On January 21, 2004 at 05:07:45, Sune Fischer wrote: >On January 20, 2004 at 21:41:47, Robert Hyatt wrote: > >>On January 20, 2004 at 19:21:04, Sune Fischer wrote: >> >>>On January 20, 2004 at 13:09:04, Robert Hyatt wrote: >>> >>> >>>>>Are you saying a 5 ply PV on position X is good, but when we later in some other >>>>>parts of the tree search X with ply 5 or above the PV will be nonsense? >>>> >>>>Absolutely. I explained why. One sequence of 5 moves might have two checks. >>>>Another sequence to reach the same position might have no checks. Which >>>>resulting search will be more accurate? The one without the preceeding checks >>>>or the one following the checks? Think about "draft". >>>> >>>>> >>>>>I think you need to explain that to me very carefully. >>>> >>>>Done. :) >>> >>>No you haven't explained anything, it's exactly the same calculation! >> >>No it isn't. read _very_ carefully. >> >>I search a-b-c-d-e-f-g-H and reach position H in a 10 ply search. When I get >>to H, the remaining depth is 3, except moves a e and g are checks. So the >>remaining depth is 6, this is the draft. >> >>Now I search g-f-e-d-c-b-a-H and again I get to position H. But with this >>order of moves, there are no checks. The remaining depth is 3. >> >>Same position, same ply, different draft, different result when you search >>position H. Which do you search first? Again, same position, but with a >>different sub-tree hanging below that position. That is _not_ "exactly the >>same calculation." Trees are strange things, in reality. > >Hmm, I think you are the one who should read very carefully, I specificly said: >"search X with ply 5" which means the PV was produced by a 5 ply search, so that >means the _remaining_ depth is 5. :) No it does _not_. Please re-read what I wrote _again_. Just because you searched to a fixed position, that does not guarantee you a specific "draft" when you reach that position. The draft will vary based on the _path_ you used to reach that position... We are discussion how position H in my above search could produce the wrong move when probed in the hash table to construct the PV after the entire search has completed. I gave two different paths to reach H, which would cause the search below H to produce possibly a different best move or a different best score... Or even worse. Such as the second failing low and destroying the best move so that there is nothing there when you come back. All that matters right now is "is the position H going to have the correct best move after I store it here, and then come back at the end of the search and try to retrieve it?" My answer is "maybe or maybe not." For the reasons given above. > >You can check the two remaing depth against eachother and make sure it isn't >less accurate than what you need. Certainly, although it could also be "more accurate" which produces a PV that also doesn't go with the score. Or it could be useless as another path through this position could fail low because the remaining search depth was low enough or high enough to make this position fail low this time around. > >But actually, your example is interesting as well. >Say we concatenate two PVs, one very much shorter than the other (from a much >less deep search), why should that give us problems? Simple. One could search below position H and produce a best score and best move. The second could produce a fail-low. No best move. Or a different best move. You have the score from the first search below H, and either the best move from a different search below H with a different depth, or else no move there at all... > >They are both PVs so seperately they are ok, why shouldn't they be ok together? > PV A goes with score A. PV B goes with score B. but in the case above, PV B goes with score A. I can't debug that. >I suppose it is possible the window is way off in one case (e.g. a mate window) >and somehow getting mated turns into a PV which we then glue up with a PV from a >different window showing a draw score.. :) That is one of many odd cases that happen, yes. But if you look back over the CC literature, you will find lots of questions about PVs when they are constructed in this fashion. Deep Blue was but one case where oddball moves showed up because they had no choice in how to get their PV since the chess processors did not supply one. > >But I suspect this would be unusual, basicly I don't see how the same position >can produce such different yet _exact_ scores?? > DIfferent "depth remaining". Caused by two different orders of moves leading up to the position, each having a different number of checks. Sit at a board and set up the pieces so that you look at a root position where you want to play two moves by either side to get to my position "H" as described previously. IE perhaps Bc3+ Kf5 Kh2 Kf4. One check, one extension. What happens when you search Kh2 Kf5 Bc3 Kf4? One less check, one less extensions, a completely different subtree below that position since it will be one ply shallower the second time around. >>>A-ha! >>>If you recorded qsearch I can understand why you saw nonsense..:) >> >> >>Not only q-search. See previous example. >> >>The hash is path-independent. The tree below a node is _not_ path >>independent, from repetition to 50-move-rule to search extensions that >>may or may not be done depending on the order of moves in the path. > >Yes that's true, that is always an issue with the hash. >I think it is a small issue in this context though, "grasping for straws" come >to mind :) Nope. Just explaining a problem that has been well-known for a _long_ time. Surely you don't think that this idea came up recently? People have already criticized DB's PVs because they had strange moves in them for this very reason. At one point HiTech did this I believe. I can recall others talking about the same odd behavior back in the late 70's/early 80's as memory became big enough to make hashing more viable... > >-S.
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.