Author: Vasik Rajlich
Date: 02:47:52 06/19/05
Go up one level in this thread
On June 18, 2005 at 15:32:11, rasjid chan wrote: >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 This should never happen. At FL nodes, your return type will be UB. If you can get a return type of something other than UB at a FL node, then I don't understand properly how your return type works. >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) > As I understand, you could figure out the "return type" at each interior node - it's not something that needs to be passed around. Vas >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.