An implementation of Tak and a computer opponent in C https://git.l-3.space/cgit/ctak/atom?h=lazy_queue 2026-08-28T18:37:41Z 2026-08-28T18:37:41Z tslil tslil@posteo.de 2021-07-03T20:17:27Z urn:sha1:7e58eadab1678d794344a0b14c7872296f585f96 presently it's not correct 2026-08-28T18:37:41Z tslil tslil@posteo.de 2021-07-02T16:00:00Z urn:sha1:07c5dded49d5943f54cca0c75a7a93a30ee2f323 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. 2026-08-28T18:37:41Z tslil tslil@posteo.de 2021-06-01T19:20:48Z urn:sha1:0deb42134cb7f0ed6ec809c3de1052ab2dfe2235 I tried the following, but they all made things worse: - moving away from the singly-linked (tail tracking) list for actions by: + using an array zipper for a deque + using an array to poorly hold a floating deque - caching the results of generating move lists in the transposition table and then + copying the resulting list/zip/deque instead of generating it + applying the move-to-front without copying, but this made the search order worse. Presumably in this case shallower nodes were messing up the search tree with garbage moves? I think some of this is not supposed to happen, but i have just the right combination of poor evaluation function and naively ordered and cheap move generation that i'm in a local minimum here. 2026-08-28T18:37:41Z tslil tslil@posteo.de 2021-03-28T04:22:26Z urn:sha1:29536c86457d83967c23a900574182b3898f04dd 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-03-28T04:19:05Z urn:sha1:2dbb9fa9b69e49d49cebb1c17559f6fe67600a4d 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. 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-03-18T03:10:53Z urn:sha1:c9823c76dd43aa40bef3f67fa0940a78cb40bf05 2026-08-28T18:37:41Z tslil tslil@posteo.de 2021-02-12T02:04:42Z urn:sha1:00a04c2929bdc8f8f4bf7d5d8cf413ebfb3cd006 For some reason it would seem that moving flats to a lower value and increasing the proximity between caps and top flats improves acquisition. Still not great, but every bit counts. 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-02-11T01:07:24Z urn:sha1:890eb8d7f4a8c46eae18283ca5ac9c61fd41ed97 Although it pains me to say it, ``label smoothing'' appears to be actually work. I'm also currently experimenting with training simply against _all_ games, instead of only bot matches. Once the training finishes i'll pit cttei against itself with old and new weights, hopefully there'll be a noticeable improvement. 2026-08-28T18:37:41Z tslil tslil@posteo.de 2021-02-05T21:49:14Z urn:sha1:ce09b6d94ac3dbf426e959b14fd7731001a003d1 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-02-05T21:37:32Z urn:sha1:5bc1e056412cb7d96831ab7ae32842c166b38436