🚀 go-pugleaf

> 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.

PieceList[] = { K, P, P, P, R, N, Q, B };

Let say that during the search, the white N is captured by the opponent.
The new PieceList would e

PieceList[] = { K, P, P, P, R, Q, B };

Now when the search is undoing the capture, it would stick the N right
at the back (all these is in UpdatePieceList() routine in search.c).

PieceList[] = { K, P, P, P, R, Q, B, N };

It is very likely that moves generated from this PieceList and moves
generated from the original PieceList will gives a slightly different order.
This is because move generation begins from the start of the PieceList array.
Even after applying some ordering heuristics (see my previous post), the
order will still be slightly different.  This is where the inconsistency
arises.


> I'm really beginning to become paranoid because my current version
> finds the solution to bk010 in 5 seconds (Sdepth=4) when started fresh.
> When I have a dirty gnuchessr (by first solving another bk problem) then
> the solution is found after 50 seconds in Sdepth 5 !!!
> Turning of the nullmove heuristic and the hashtable makes no difference
> and I have the evaluation cache disabled.

This is interesting.  All the while my impression is that the difference
between a "clean" and a "dirty" gnuchessr is the hashtable.  Perhaps I 
was mistaken.  This is definitely not due to the PieceList thingie discussed
above.  I'll try and see if I can figure this one out.

Regards.

Kong Sian