zxul767 / pawn Goto Github PK

The 3-fold repetition rule is currently implemented as a forced draw, but in reality official chess rules (as established by FIDE) establish that it is in fact just a situation in which the player about to move can claim a draw. 5-fold repetition, on the other hand, does imply a forced draw.

repetition: 5.3.1. 1. A player may claim a draw if the same position occurs three times. 2. A game is drawn if the same position occurs five times.

The same issue is present with the 50-move rule, which in current rules only opens the possibility for a player to claim a draw, but does not automatically imply it. 75 moves is the correct limit for a forced draw.

One of the major weaknesses of pawn at the moment is that its evaluation function is a linear combination of features. This means that even if we tune the weights to their best possible value (e.g., via genetic algorithms optimization), it is still unable to play various phases of the game with enough precision because what is relevant in one phase (e.g., king protection during the opening and middle game), becomes less relevant in another (e.g., with few pieces on the board, it is no longer a good idea to keep the king away from the battle.)

I first noticed this while I was watching it play against crafty and realized that even though at some point it seemed to have an interesting advantage, it wasn't able to capitalize on it because of the above.

It seems to me that one solution might be to define a set of weights w_i as a function of the features F, according to something along the lines of:

where

This last equation shows that the weight for a given feature is a non-linear function (sigma could be a sigmoid function, a ReLU or any other non-linear function) of all features. In other words, the importance of a feature at any point in the game is determined by all other features at that moment. Of course, this last mapping (w*) must be learned in some way to reach optimal play, so this again becomes an optimization problem, except that we must now learn a matrix of weights instead of a single vector.

The possibilities to learn this matrix of weights are many (e.g., genetic algorithms framework, temporal differences learning, supervised learning using other chess engines, etc.)

This idea can also be roughly but imprecisely implemented by using a ser of different weights in discrete phases of the game (i.e., opening, middle game, ending), which are usually determined via heuristics (e.g., the ending starts after a certain amount of material is left; the weight for mobility is smaller in the end than in the opening; etc.) Of course, this can help improve the engine's performance, but it's always limited by our own human prejudices about what's good or bad in chess. As AlphaZero has proven, humans aren't necessarily at the top of the knowledge pyramid in any given domain.

How random is the current implementation really? Can we document its source?

Originally posted by @zxul767 in #19 (comment)

There is no point in creating our own format when we could use JSON to store the configuration. Parsing it could be easily done with a library like https://github.com/nlohmann/json

We do have a to_bitboard function in util:: but I think we need to reorganize things because Util.h is following the anti-pattern of being a miscellaneous toolbox that forces unnecessary recompilation of almost all other units. At the very least, we should separate into mathematical stuff and bitboard stuff (which is mostly what is currently in util::)

Originally posted by @zxul767 in #19 (comment)

pre-commit has been added to the project to ensure code gets formatted automatically using clang-format and clang-tidy, but it is not currently enforced in the CI/CD system.

We need to document how these opaque bit-twiddling algorithms work.

Originally posted by @zxul767 in #19 (comment)

There's something fishy about having "kind of moves" and move types. Can we coalesce them into a single representation?

Originally posted by @zxul767 in #19 (comment)

It would be very interesting to generalize this to allow arbitrary features.

Originally posted by @zxul767 in #19 (comment)

The current implementation simply assumes that a king is safe if it castled and has pawns in front of it. A better implementation should consider if the vicinity to the king is under heavy attack, and/or if there are enough defenders.

the code of the script is outdated

Reproduction steps:

1. Remove or rename initial.in from the top-level directory
2. Start the program (e.g. bin/mae)

Expected:
The program starts with the board in the initial position (according to the usual rules of chess)

Actual:
The program starts with an empty board, so there are no possible moves to make

I recently discovered and read the source code for python-chess and found that they have quite an efficient (and clever) implementation for legal moves of a bishop (and other sliding pieces, like rooks and queens).

See this link for details (in particular, the implementation of the _attack_table function)