TalkChess.com

Board representation for incremental attack tables should be build from scratch.
It is not a efficient idea to add attacks as extra weight to well-known representations.

You need to do std::flush() after printing each info string.

This representaion is as fast as the fastest perft known engines. My principal chess representation consists of 16-byte vector for each 16 chess piece from each side. attackMap is array of Ranks of BitRank vectors for each piece; BitRank: byte of 8 squares per rank (1/8 of bitboard); PieceId: index ...

Stroustrup's "The C++ Programming Language" is must read for practical experience. I personally read some old Effective C++ books and dislike them all. Agile is all about Team Project Management not about individual programming skills. "Clean Code" is good reading for programmer but it is not a tuto...

The trick is to use second counter. unsigned long nodes; unsigned long nodesLimit; //search limit enum : unsigned { TickLimit = 5000 }; // ~1 msec unsigned nodesQuota; //number of remaining nodes before slow checking for terminate // the current exact number of nodes node_count_t getNodes&...

There is a true metric: ratio of nodes pruned relative to full minimax tree.

jdart wrote:Color-flipped positions *can* occur in chess, but I would be surprised if they were frequent enough to make this optimization a significant win.

--Jon

It is easy to make color-independent but side-to-move dependent board representation. So all hashing and evaluation are transparently symmetrical.

Please can you explain what is rollout algorithm in simple words?

Null move heuristic should not be done on PV-nodes. To my limited understanding all non-PV nodes in PVS are searched with null-window.

It is possible to store lower- and upper- bound score with their respective depths (exact score is both upper and lower bounds) of the same position, but the hash move should be only one (or sometimes none).