Author: Robert Hyatt
Date: 18:41:47 01/20/04
Go up one level in this thread
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. > >In fact I don't know why you would even bother to search it when you obviously >can just get it from the hash. See above. If I search the non-checking path first, when I get to the checking path the hash draft is not sufficient. > >Both of them being PV moves, means the window doesn't matter. >Neither of them should be nonsense because they are _the same_. Think about that _carefully_. The search below position H is _definitely_ dependent on the path above H. If all the moves are checks above H, the tree below H will be larger. If you alter the moves so that there are no checks, the tree below H will be much smaller. > >If the depth drops you can do as I have already suggested: >don't use it for the PV. > >>>I wouldn't want it to, I want to know where the search ends and qsearch begins. >>>That is important if you want to interpret the PV correctly. >> >>You can do that if you want. I don't but it is trivial to add, since I do >>know where I copy the PV from the q-search and from the main search. > >My point exactly, the PV is more or less nonsense, you just don't know from >which point on it is nonsense. > It is _not_ nonsense. Otherwise the entire _search_ in nonsense. Alpha/beta is all about proving that the path is the best path based on min and max operations for opposite sides. If the path is no good, the search is no good, and we may as well go home. > >>>>But when I was doing this, I did hash in the q-search. >>>>The same problem arises irregardless. Prior to the q-search, you can overwrite >>>>stuff. When you probe for "imaginary" positions beyond the end of the current >>>>hash-table-hit position, you can get anything. Good moves. Moves that don't >>>>go with the current PV. And with today's Crafty I would get no q-search moves >>>>at all, and they are often critical to see. >>> >>>I suspect your search is broken then. >> >>Suspect what you want of course. I suspect it is not broken myself... >> >>:) >> >>> >>>If you terminate a leaf position because you've run out of depth and you have in >>>hash that position stored with a decent depth, why not use that information to >>>get a more accurate score back down the tree? >> >>That's not what I said. I didn't mention "decent depth" at all... >> >>I just said "hash signature match". > >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. > >-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.