Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Bug-free fail soft must pass return_type

Author: rasjid chan

Date: 10:44:01 06/22/05

Go up one level in this thread


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 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.


>>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.

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.