| Age | Commit message (Collapse) | Author |
|---|
|
Previously the code base assumed that there was a single, global game
state which was the implicit target of all actions taken. Looking
ahead at architectural improvements, this has now been (almost
entirely) made explicit and functions take tak_state_p where
necessary (and also where unnecessary).
Two important fixes to actions.c were made:
- Previously when generating the possible stack moves, stack height
overflows (> 15) were not taken into account and this resulted in the
tree search corrupting the board state. Now action search does not
list all legal actions, rather the subset of these encodeable by the
implementation.
- The check for crushing on a stack move was incorrect (too strict),
and this resulted in many legitimate moves being igonored.
Finally, in other changes, weights have also been improved by training
all games instead of some subset for chosen players, and clang-format
was run on the codebase.
|
|
This is a special interface to negamax_cnn1986 which is designed to
generate output for use in a CGI tak interface to be used over gemini.
Also in this commit is a reformating of the various source files to
use the traditional tab width of 8 spaces.
|
|
Previously check_win would call check_road_colour once for each road
colour, and check_road_colour would call a depth-first search (DFS)
for each of the two axes. This meant that we were doing (up to) *four*
depth-first searches for each call of check_win.
I have replaced both axial DFS with the world's worst TM
implementation of a connected component generation algorithm backed by
the least guaranteed disjoint set data structure. Essentially doing
anything about union find correctly is slower than just ... not doing
it. Although we lose the asymptotic complexity, in practice we're
doing this millions of times per turn, for a fixed board size and
that's what matters.
All in all, it appears that i've managed to shave about 69ns off
check_win, per call -- nice! This amounts to 50ms or so saved at depth
5 per engine move, in one of my test games.
Unfortunately nearly 99% of the time is still taken by evaluating the
convolutional neural network. It's slow.
|
|
Eventually there'll be a more complicated data generation step than
the one we're presently using, so having it in-lined in the loop is
wasteful. Ideally also this would be update per ply and we could avoid
recalculating it entirely for every query -- though it's probably
``fast enough'' for now. Also, caching is WIP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
With minimax of depth 1 the evaluation function seems alright with the
current method of training and generating weights
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Corrected use of static
- Implemented next_turn
|
|
|
|
|
|
|
|
|
