🚀 go-pugleaf

In article <1rglhs$l3d@news.cs.tu-berlin.de> dietmar@cs.tu-berlin.de (Dietmar Wolz) writes:
->Content-Transfer-Encoding: 8bit
->
->
->Some ideas about hashing in gnuchess4pl61:
->
->1) routine PutInTTable in util.c
->
->      if (score > beta)
->        {
->          ptbl->flags = lowerbound;
->          ptbl->score = beta + 1;
->        }
->      else
->        ptbl->flags = truescore;
->
->Why beta+1 is stored ? If we have a window (alpha,beta) and a result score
->with score > beta, then score should be a lower bound for the real value.
->Storing score instead of beta+1 would cause more (correct) cuts.

The evaluation routine use a less scoring routine when the score seem
certain to be outside the alpha-beta interval anyway.
If the score is known to be evaluated accurately, then your
suggestion would be useful. Maybe adding a flag to tell if
the score is based on inaccurate calculations would be useful.
The simplest thing would be to make the inaccurate calculation
return beta+1, then no flag is needed.

->    
->2) routine ProbeTTable in util.c:
->
->#ifdef notdef                   /* Never happens! see search */
->          else if (ptbl->flags & upperbound)
->
->Thats true, but why ? Todays machines have large memory resulting in large
->transposition tables. Why not also store upper bounds ? This again results
->in more cuts during search.

Try it! With large transposition tables it might, as you say, result
in more cuts. It might also not be worth it.

Comment I fully agree with deleted.
-- 
Urban Koistinen - md85-epi@nada.kth.se
Stop software patents, interface copyrights:  contact lpf@uunet.uu.net