Author: Vasik Rajlich
Date: 03:47:22 06/23/05
Go up one level in this thread
On June 22, 2005 at 13:44:01, rasjid chan wrote:
>On June 22, 2005 at 06:58:20, Vasik Rajlich wrote:
>
>>On June 22, 2005 at 04:23:20, rasjid chan wrote:
>>
>>>On June 21, 2005 at 15:27:10, rasjid chan wrote:
>>>
>>>>Dieter,
>>>>
>>>>Some of the things here by Vasic and you are actually advanced stuff for me
>>>>and I am not yet at the level to completely handle them yet. Just like Vasic's
>>>>mention of being optimal.., I need time to consider those subtleties, but I keep
>>>>things in mind that there are such things to be alert to when it's time.
>>>>
>>>>I can sense both of you did more formal reading but I get most tips here after
>>>>I come about 2 years back.
>>>>
>>>>Just as an example of the big gap in my knowledge.I was fixing my rep3 code
>>>>after being reminded by Vasic about the correct 0 score and I got stuck; it
>>>>seems not that simple! So after thinking, I found it could be the graph tree
>>>>interaction stuff of Breuker you refer to. It may be wrong! :-
>>>>
>>>> This is for the sake of rep3 theoretical accuracy.
>>>>
>>>> updatehash();//for the node B after makemove() below
>>>> if (rep3()){
>>>> best = 0;
>>>> .....
>>>> // let this node B repeats A down below.
>>>> }
>>>>
>>>> makemove();
>>>>
>>>> Say rep3 is triggered. Then all nodes searched after B will inherit
>>>> dependency until we leave A. Had B being reached through another path w/o A
>>>> below we don't have the best = 0. So basically subsequent sub-branch searched
>>>> will be corrupt until we leave node A. I may be wrong as I just thought of it
>>>> an hour ago.
>>>>
>>>> I will make copy of my ab_search_w/o_storehash() to disable all hashing(not
>>>> probehash) until search leaves node A. I think just return ply of A from
>>>> rep3().
>>>>
>>>> Don't laugh at what I am going to do. I am only experimenting, not weighing
>>>> efficiency yet.
>>>>
>>>> Vasic,
>>>> Incidentally, just to let you know. BU fail-soft could pass inconsistencies
>>>> from QS to horizon depth/pre-horizon depth when we have QS generate check. I
>>>> remember I need always to gen-check for 1st ply of QS and maybe also 2nd ply.
>>>> The move set of QS changes. Also a need to keep 1 bit _qs_gen_check in HT.
>>>> You'll know what I mean.
>>>>
>>>> Best Regards
>>>> Rasjid
>>>
>>
>>I'd have to think about this more. Off the top of my head, I don't see why this
>>should be the case. Checks are just another set of moves which must all return
>>exact at fail-high nodes (ie. fail-high nodes in the q-search) in order to
>>propagate this "exact" flag.
>>
>>Anyway I like the new term "BU fail-soft". Actually I think you can just go with
>>"BU FS" - of course nobody will know what you're talking about :)
>>
>>>
>
>Firstly I think it is not a practical issue. Fabien wrote Fruit without thinking
>about any such things, just write a strong program.
>
I don't know. Fabien knows a lot about search - it's clear from his code as well
as from his comments here. It's very easy when writing a search to make wrong
decisions you don't really understand - and this is a good way to make a weak
program.
Personally, I think these sorts of issues through by trying some examples and
then changing my mind three or four times. Maybe for others it's "easier" - hard
to say.
>I mis-interpreted that it is about BU FS. It is strictly the issue of search
>inconsistency when QS generates checks, ie QS do not consistently generate the
>same QS chess tree subspace when similar searches of identical nodes are made at
>different times. This corrupts the HT in general, etc.
>
>I wanted first to do a clean FS and so I had to go into details and formulated a
>simple set of rules for QS check generations so as not to add inconsistencies
>into search.
>
>EG Rules for QS check generation :-
>
>1) allow checks in first N plies of QS
>2) a QS node generates (all) checks only when the move 2 plies down is a check
> move;we may add eg. && (_is_double_check || _move_following_do_not_capture)
> or material balance, etc..
>3) 2nd ply of QS must generate all checks.
>4) 1st ply of QS must generate all checks.
>5) any other conditions that depend only on the properties of the QS chess-tree
>/ moves; eg conditions on alpha, beta bounds adds inconsistency.
>
> On rule 4 -
> Consider a position X which is from the 1st ply of QS. X may be reached in many
> ways through 2 moves in full search, some having the 1st move being a check
> move, some having the 1st move not being a check move. This means rule (2)
> cannot cover this case and therefore rule (4) is needed. The same reasoning
> applies to rule (3).
>
>These rules always ensure QS generates the same QS tree subspace, and therefore
>the same chess tree space, in any research.
>
>If at horizon BU FS fail low and exact, the result of a resarch may be different
>if the QS chess-trees are different. Again this may only be for theoretical
>strictness only and may not have any impact on a chess program's playing
>strength.
>
I think I follow this. You can also generate q-search trees which are not
identical, but as soon as your are omitting some moves from the q-search, you
must pass up one-sided bounds only (ie. no exact scores).
>
>>>My mistake again, hope this is final.
>>>I am just trying to first get the stict conditions correct.
>>>
>>>Node B has a rep3 and whatever the final score (need not be 0) be for B has
>>>dependency. This dependency propagates to the parent node only and whatever the
>>>final score of this parent be inherits the dependency. This propagates all the
>>>way down to root. So strictly for HT purity all nodes along root_node -> A -> B
>>>should avoid hashing; ie. even the root search for this iteration should not be
>>>hashed.
>>>
>>
>>I am slightly confused by your terminology here. If A is the node at which a
>>position occurred the first time, and B is the position which it occurred the
>>second time (ie. rep3() == true), then positions between A and B can't go in the
>>hash table, but positions between root and A _can_ go in the hash table.
>
>
>I had it correct finally except for adding an extra tail. Thanks for correcting
>me. Dependency ends at node A. I now have (I think) a good picture - dependency
>concerns paths that cuts into path AB above node A. Parent of A don't apply.
>
Yes. BTW - see my reply to Dieter. I think even nodes between A and B belong in
the HT (after all) - but this might change again in the next few days :)
Vas
>Best regards
>Rasjid
>
>
>
>>
>>Vas
>>
>>>But this inheriting of dependency at root may not happen at every iteration as
>>>node A may be pruned. Even changing the move ordering may avoid dependency.
>>>
>>>Best Regards
>>>Rasjid
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.