Author: Vasik Rajlich
Date: 03:58:20 06/22/05
Go up one level in this thread
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 :)
>
>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.
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.01 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.