I am not sure I understand this. What information is in the lookup tables that would not be provided by the bitboard generation already? Is it that you store a lot of info on every move, that it pays to have an intermediate level of indirection through the pointers (so that later you would only have to sort the pointers, etc.?)Steve Maughan wrote: ↑Thu Mar 14, 2019 11:20 amMaverick uses a hybrid magic bitboard and lookup-table method. The bitboards are used to generate the moves, which are then stored as a list of pointers into the move table. This has the advantage of bitboard move generation of captures etc, and the lookup table advantage of make-unmake. I'm sure it could be optimized more but Maverick was doing single core 8 million nps on a 2015 i7 when it had a basic piece-square table.
For me a move is usually just a from-square, to-square, promotion flag and sort key. This can almost always be packed into a 32-bit integer very easily, even on bloody-big boards. So I always manipulate the moves directly, with no need for pointers.
Only when I want to save time on sorting for the history heuristic I would assign two words to each: one for the move itself, and a 'pointer' (actually just an index into the move stack) of the 'next' move, so that I can put the non-captures in linked lists binned by history value. So that later I then just can loop through the bins and the lists without any further sorting.