ctak/include/actions.c, branch lazy_queue An implementation of Tak and a computer opponent in C https://git.l-3.space/ctak/atom?h=lazy_queue 2026-08-28T18:37:41Z experimenting with a lazy queue implementation 2026-08-28T18:37:41Z tslil tslil@posteo.de 2021-07-03T20:17:27Z urn:sha1:7e58eadab1678d794344a0b14c7872296f585f96 presently it's not correct Trying to make things faster 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. Fix copyright notice in files, and small preemptive optimisation 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. Rename ct_k -> ct, IANAL but ... 2026-08-28T18:37:41Z tslil tslil@posteo.de 2021-02-05T21:49:14Z urn:sha1:ce09b6d94ac3dbf426e959b14fd7731001a003d1 Try to squeeze out a little more performance 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-01-30T21:47:48Z urn:sha1:84ad2e3c12cb505e3c5e3dd29d05edb529b82174 ``Common wisdom'' dictates that placements are often better than stack moves, so we bias the generated move list in this fashion. Seems to be a little faster. Added license information! 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-01-29T02:30:30Z urn:sha1:a77062ce3dc9a99ad0662010cc7eeb00dd5036a6 It would appear that any function call whatsoever is slower :/ 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-01-28T17:01:42Z urn:sha1:b5b337d4044a8e64956b8a2309739353f9ce339e For now we'll stay with directly recomputing it at each non-terminal node Somehting along these lines, i'm tired 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-01-27T03:39:28Z urn:sha1:6b48baaf6b67cc7364d5945eb6d9b25ea9683bd9 Storing best moves! 2026-08-28T18:37:41Z tslil clingman tslil@posteo.de 2021-01-26T22:42:53Z urn:sha1:de4f20f28afe23ecfc546ad242e5bb44710996cc