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.