A while ago I started creating an app for playing tsumego puzzles, and some of its shortcomings could be solved by automatically generating the puzzles, as well as using a solver for providing in-app “intelligence”.
So a few months ago I started creating a solver and generator for life and death puzzles, and it’s finally got to a point where it works end–to-end.
I like it a lot. It’s really cool, as the difficulty seems to be just right for me.
One comment I have is that it gave me a puzzle where the best outcome was ko. That confused me after having puzzles where you could always kill or live. But I think it’s cool to leave the puzzle open and let the player see what the best outcome would be.
Also, one puzzle I did wrong, and it didn’t give me any explanation. But I believe you plan to add something like this?
But anyways, this is really fun, and I don’t need to go through the hassle of searching for a set of Puzzles that are ‘good’ for me.
It requires registration because it works out your skill level from the puzzles you have played and gives you puzzles of the correct difficulty. I do have plans to improve the user experience for non-logged-in users though, by giving them something better than a static splash page.
Currently the site uses manually created puzzles, and the quality and correctness of these vary. This was the motivation behind creating the tsumego solver and generator, and once integrated into the site it should fix both those problems you’re experiencing.
Aah okay. Yeah the puzzles felt a little curated sometimes. So many comb shapes. I was impressed by how close you got to human puzzles with your algorithm. But that explains it.
Will the puzzles’ difficulties also be learned by user behavior? It would be interesting to expand glickgo by adding the information that some “players’” skill never changes. Maybe it’s even enough to set the rate of change one or two orders of magnitude lower than that of the real players.
The puzzle’s difficulties are actually currently learned in exactly the same way as the users skill is, by using the glicko algorithm and treating puzzles and users both as “players”, and a user failing a puzzle is a win for the puzzle and vice versa.
I think what you’re suggesting could be achieved by simply rescaling the rating by using some puzzles as fixed reference points. In fact, this would be useful for converting from the elo scale to kyu/dan, as well as combating the inflation problem that these elo-like algorithms have.
I actually didn’t mean fixing the puzzles rank. It’s anyways just an arbitrary number given by humans, inferior to what you can infer from your data. Rather I was wondering if it is possible to adapt glicko to assume the rank of a puzzle to be fixed, but at an unknown score. But I guess that would require to go through the whole theory of that paper. A lot of work.
But if the current system works well (which it seems like it does), then there is no reason to change
I btw looked through the code of the generator and solver. I like the use of u128 to represent the puzzles. The implementation looks really efficient.
Right, I see what you mean now. That’s an interesting idea. I have plans to improve the ranking system, although unfortunately quite low priority at the moment, and will look into this at the time.
I’m going to look at implementing WHR instead of glicko, and it’s possible that the w parameter of the Weiner process could be set to zero for the puzzle’s ratings only, essentially making this a static rating system from the point of view of the puzzles. However, I have not comprehended the paper enough to determine this yet.
Thanks for looking at the code! I think the BitBoard part of it should be really efficient, but the performance is still way below state-of-the-art. However, there’s loads of stuff I can do in that area, and is one of the highest priorities with that project because otherwise it can’t generate very difficult puzzles.
I haven’t evaluated your software, but you ought to be aware of the Tsumego generator/solver “Go Tools” from years ago by T. Wolfe. It specialized in creating
problems with incredibly complicated multiple Kos.
Yes I am aware of this GoTools, but there was a few reasons why I built my own rather than using this. Firstly, the source code is not available and I need to run it in the browser by compiling it to wasm. Secondly, I wanted an interesting side-project to do and this seemed to fit the bill.
Unfortunately my solver isn’t anywhere near the power of GoTools yet - it’s very much an MVP. However, I’m slowly improving it and hopefully some day it will get there.
