My apothecary chess (my own invention) engine

[catugocatugocatugo]

I am writing a fairy chess engined for a collection of two upcoming games that are invented by me. Before, on this link :viewtopic.php?p=975677&hilit=hello+engine+plans#p975677 I have asked for advice discussed some aspects of the upcoming engine. But my current attempt has become a bit cluttered. Also, the long-term goal is to train a NN through self-play to learn the games. Now I have a pretty memory consuming hybrid approach for the representation. As NN is the goal, I consider that probably NNUE would work best.
Question number one: Should I use a different approach for the representation, or the normal NNUE input is fine, for representing the board?
Also, I am thinking to tabulate moves in the beginning alpha-zero style. That would probably improve a somewhat slow move generator.
Question number two: Am I correct in thinking that tabulating moves in the beginning will improve the speed of move generation?
These two questions are because I am strongly considering restarting the work on my engine.

[Aleks Peshkov]

I do not understand the quiestion but I suggest to finish work. It is much easier to refactor working code with small iterations rather than rewrite from scratch (and risk to never finish goal).

[catugocatugocatugo]

Thanks, Alex!

Now I am finished to checking check function, then I'll start writing a classic AI in order to show the basics so that the NN should not have too rubbish examples.

[catugocatugocatugo]

I am now writing the threefold repetition detection algorithm. I need to keep the game history for that. I think I do not need to keep (and subsequently check) the whole history, but only the history after the last capture or after the last pawn push, as after these events the old positions cannot be returned to. Am I correct?

[Aleks Peshkov]

You need to store only double repeats in history to detect 1st search repetition as 3rd repetiton. Otherwise you can detect 2nd repetition inside search as draw.

[catugocatugocatugo]

You need to store only double repeats in history to detect 1st search repetition as 3rd repetiton. Otherwise, you can detect 2nd repetition inside search as draw.

All right, but what I have asked is if I need to store the whole history, or I can dispense of the moves before the last capture, or the last pawn push, as there is no turning back after those?

[hgm]

You only need the history starting from the last irreversible move. But I don't think it would be worth the hassle. I think that what most engines do is save the entire history (game + tree), and then use the 50-move counter to see how far they have to loop back through that data for finding a repeat. For this purpose a null move is often considered irreversible to.

In Fairy-Max I store the game history in the transition table: every position that has occurred in the game will be stored there with a draw score, exact type, and maximal depth. Then every hash hit on it would cause a cutoff with a draw score, so that you won't need dedicated code for recognizing repetitions. You could also do this for repetitions in the search, but then you would have to organize your hash code such that on entering the node it already allocates a new entry in case of a miss, and in any case wrtite the draw data there. (Which later will be overwritten with the search result when you return from the node.) The latter would not work for a multi-threaded search with shared hash table.

In my engines for variants that have no irreversible moves (e.g. due to piece drops) I use a small hash table (256 or 512 entries) to store keys of positions that are encountered in game or search, but remove these when the corresponding node returns. When the engine finds the position after the move it wants to search in that table, it scores the move as a draw. To prevent recognizing null-move-spanning repeats you can store the (half)move number after which the position was encountered in that hash table, and let the search keep track of the move number of the latest null move. It can then test whether that null move happened within the path leading back to the repeat, or before it, and ignore the repeat in the former case.