🚀 go-pugleaf

nsrccks@leonis.nus.sg (Chua Kong Sian) writes:

>> Shouldn't a call to InitializeStats before the iterative deepening
>> begins fix this (Because a new PieceList is generated?)
>> I did this but I still have the following problem.

>Ah, not really.  Let me try and explain it with an example.  Suppose
>that before iterative deepening begins, the PieceList for white is
>as follows.

......  (Correct explanation of PieceList ordering deleted.)

I tried to say that inserting a InitializeStats() at the start
of SelectMove() generates a fresh PieceList. This means that
undoing a move (with the undo command from the commandline)
does no longer change the piecelist with which the search is
started in SelectMove, i.e. it does not explain the differing tree
counts.

I think I found a small problem. INCscore is not initialised
at ply 1. So I added:

if (ply == 1)
  INCscore= 0;

at the start of search().

I also added:


#if 1
  /* Make sure that width test at lower ply gets non random move
     count in case of pruning:  -- TomV
     This test also allows us to delay move generation till the
     null move is done.
   */
  if (ply>1)
    TrPnt[ply+1]= TrPnt[ply];
#endif
 
  /*
   * if more then DepthBeyond ply past goal depth or at goal depth and
   * score > beta quit - means we are out of the window
   */
......


Both changes do however still not solve my original tree count problems.
Anyway, I'll continue to give the code a close look.
Thanks for doing the same. I hope we (or someone else) can solve this soon...


Tom