🚀 go-pugleaf

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

>Even after disabling the cache, Tom Vijlbrief reported that nodes counts
>are still differing after an "undo" and a "go".  This time the difference
>arises only if a capture is undo (non captures will give the same node 
>count).  The reason is because the PieceList array is now arranged 
>differently.  (This array contains the pieces that are remaining on the
>board.  Undoing a capture will yield a piecelist array that has the
>captured piece in a new location in the array then the original array).
>With a slightly different PieceList array, the move generation order is 
>changed.  Subsequently a difference sequence of moves will give rise
>to different node counts during the search.

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.

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.

Tuning gnuchess is ofcourse little fun and almost impossible
as long as this happens :-(

>If we were to change genmoves.c MoveList() routine to search the board
>rather than the PieceList during the move generation, the nodes counts
>report will now be correct.

>Once I figure out why having cache and not having cache gives rise to
>different node counts, I will report the finding.

That would be great !!!


>Regards.

>Kong Sian
> 

Thanks !

Tom