Author: rasjid chan
Date: 12:32:11 06/18/05
Go up one level in this thread
On June 18, 2005 at 14:05:44, Vasik Rajlich wrote: >On June 18, 2005 at 11:12:38, rasjid chan wrote: > >>Your "4 or 5 lines" for fail-soft is should be correct. >>These lines are needed in FL to record the greatest FL score and we simply FL >>with this irrespective of the bounds. Fail-high don't need any extra lines, we >>simply return the score received from search() instead or returning beta. >> >>When we hash FL/FH, I think we can safely hash the fail-soft score and not the >>bounds and the theoretical advantage is straight-forward. So fail-soft is as >>simple as it should be. > >Yes. > >> >>My earlier comments are actually for an attempt to have as good a hash-table >>implementation as posssible by "preserving and passing down" an exact score. >>It is posssible only with fail-soft. >> > >Yes. Of course fail-soft values will also be artificially close to the search >windows - they always err on that side. > >>When we eval() in QS and there is no move to search, we return eval-score. >>we also return an int return_type = ex irrespective of the bounds. This ex >>return_type may be preserved and passed downwards(I don't have the statistic >>nor know the usefulness). So lower down when all moves are searched >>and we have a FL, we may have a best score < alpha. An int best_type is also >>kept which is done by applying reverse_type() to the return_type. >>The best_type may be ex/ub/rep3. So we may end with FL below alpha(soft) >>but we hash type as "exact" and not the usual "upper_bound" which is the default >>if we don't pass down types. >> > >I don't follow what the purpose of the "return_type" is - you shouldn't need it. If you dont understand my "passing down a return type", then I may be doing something wrong,but I'll still have to think again. To put it simply, without what I am doing, then at FL nodes, set the upper bound value(from your comments below, and it must be UB). In my case, at FL nodes, AND IF THE BEST_TYPE(which is obtained by reversing the return_type) == EXACT I still fail-low, but I dont set the upper bound,I SET UB = LB = BEST_SCORE, in other words I don't have to observe the rule "when fail-low, hash as upper bound", I now have "fail-low and hash as exact". I think if what I am doing is correct,then hashing is theoretically more efficient. The priority in over-writing hash tables is :- 1) exact preferable to upper bound; 2)upper bound preferable to lower bound(retaining score that involves more time spent searching all moves). Does anyone see this "passing down return_type" as simply wrong/is correct? - just like Dieter post his qsearch()to highlight possible pitfalls (I have yet to detect that error) Best Regards Rasjid >The simplest way to handle the hash table is to have both an upper and a lower >bound there. At FL nodes, set the upper bound value; at FH, the lower bound >value; at nodes which return a score between alpha and beta, set both bounds. > I understand this, exact is when UB==LB,so basically ok. >If your hash table has a single value with a "LB/EX/UB" flag, then the logic is >the same. At FL nodes, set the UB flag; at FH nodes, set the LB flag; at nodes >which return a value between alpha & beta, set EX flag. > >Vas > >>If we have double bounds in hashing, then if we have depth=3,type=ex >>and the hash table main bound is depth=4, type=UB/LB(not EX), we need not >>discard hashing this search, but slot it into the secondary bound. The question >>is how useful is all these work. I have found that the codes for passing >>down "type" is rather straight-forward. As a comparison, implementing double >>bounds in hashing is rather complicated. >> >>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.