Well, I’d follow yebellz’s priority list.
J9-J1, H8-H1, …, B2-B1, A1, A2-A9, B3-B9, … H9
With this particular ordering, aren’t our two definitions equivalent? (Could be wrong, I haven’t checked)
I’m not sure what you mean by simpler exactly. Anyway I would like to point out that my definition also provides a rather straight forward algorithm for checking whether a sequence is canonical: For any symmetry line, checking if a point with coordinates (i, j) lies left / on / right of the line is easy and fast. Then apply the conditions on the moves in order, remembering for which symmetry line we already found a point that does not lie on it.
If they are indeed equivalent, I just personally prefer to state it the way I did, but of course it’s always somewhat subjective which is easier!
I don’t see any difference in how easy it is to check whether a given sequence is canonical (comparing two coordinates in lexicographic order is also easy and fast).
…
Given a sequence of moves, how to decide quickly which other moves would be symmetrical choices to the last move in the sequence?
Finding the symmetries of a given position is indeed more computationally expensive than just comparing individual coordinates.
Perhaps I’m still misunderstanding, so could you give an example how you would apply your rules to determine if the sequence below is canonical? (in particular, how do we detect that symmetry reappears on move 4, after having been totally broken on move 2?)
(edit: of course technically move 5 would not be equivalent to C5 under superko, however for practical purposes such as an opening dictionary we would like to treat C5 and G5 as equivalent)
At the end of the day, I think it’s all a bit arbitrary. Do we care more about adhering to tradition, or something that is simpler to apply? I guess the main motivation is just to help keep a curated collection of fuseki manageable, right?
The rules that I stated earlier do not quite adhere to tradition either. Typically, when Black opens on the 44 point in the top-right (in a 19x19 game), White would traditionally prefer to play the second move in the top-left, rather than the bottom-right (for cases where White wants to play the second move in an “adjacent” corner). So, my symmetry handling rules would not properly capture how 19x19 fuseki are most typically played out.
I have no idea about the proper, polite, or traditional conventions in 9x9. Maybe things are a bit more flexible for that variant? If Black opens on tengen (in 9x9), is there a traditional convention for generally where White should play next?
There is not only symmetry detection to worry about, but also transpositions. I don’t really know much about the computational tricks used to handle those, but it seems that others have already given considerable thought to technical issues: see Transposition table - Wikipedia and Zobrist hashing - Wikipedia
KataGo’s opening books is an example of a project with full handling of symmetries and transpositions (there are some interesting implementation side effects, like the “canonical parent”-button doesn’t always go back to the position you were just at)
My impression is that beyond the first 2 moves, there’s not a widely agreed upon convention on 19x19. And on 9x9 even the first move doesn’t have a strong tradition. So I think a particular project is quite free to choose whatever rules make sense in that context.
is it too late to rewrite this in React
It’s never too late.
I want to because managing state is getting gnarly and I forgot how much nicer React can be (after last night I toyed around with this)
But I’m not sure I have the time/energy. I have a new version using existing code which will switch to the new puzzle collection starting on #15. Just some tweaks left: going to add an “about” page with a basic link instead of modal for now, to explain the hard mode/easy mode, and also a link to OJE on solution.
Then I think I’ll take a break except for bugs
What does rewriting it in react entail? I really don’t know much about that entire framework. Would it be possible to refactor just the app.js part of the code, or does one need to dive into refactoring BesoGo as well?
I can help with doing this, even with the modal style. It seems that @shinuito posted a very helpful tutorial and it seems fairly straightforward.
I don’t think we would need to refactor BesoGo, I believe there is a way to embed non-React things or wrap non-React things in React components, which would be the way to go. But I’m not an expert.
The main advantage is handling state and state change. React is quite elegant at this, and state changes flow nicely through the code and the framework smartly takes care of redrawing as needed. But it’s a bit of work and I’m not really suggesting it seriously.
Awesome! I didn’t start yet. I just pushed the latest
Here’s an update on the puzzle collection: I stopped scraping OJE around depth 20, which yielded:
- 588 joseki total (sequences marked in the explorer with “Joseki: Done”)
- 236 easy joseki (a subset of the total, but with length less then 10 or marked with “Basic”)
The new version of the app will switch to start using this collection at #15 (Tuesday in US timezones). The reason I picked this is the collection we have starts getting repetitive around then (same first 2 moves or so). The default will be “easy”. I think we can add a link in the about/help that says something like “want more challenge? click here for hard mode”. Hard can be toggled with a query parameter (?hardMode=true
) and should keep storage/history of guesses separate. The numbering is the same but will include “(hard)” in the title for the purpose of sharing. I thought about changing hard to use letters or something, since “Josekle #15” is likely a totally different joseki than “Josekle #15 (hard)”, but this was just easier.
We can test this now with the puzzle=15
parameter (anything >=15 should be new collection), and I would appreciate it if anyone has a chance to play with it to see if anything is broken, both hard mode on and off, etc.
The new puzzles will also show a link to OJE on solving (only new ones since only they have the ID present).
This collection is just using the “puzzles.js” style system, which has some limitations of course. But fetching two puzzle json blobs and managing the state was obnoxious which is why I was thinking about React. My thinking is, assuming there’s no major bugs, this collection is like more than 6 months of Josekle…
Probably the Fusekle variant would want better curation tools, but I leave that to someone else
Here’s how far I got in one session of compiling 9x9 openings with KataGo!
(for the future Fusekle mode of Josekle)
(this is just tengen openings, I’ll try to have a similar amount for all the main opening moves before sharing a first version of the sgf, to have some good variety)
The variations so far are between 5 and 12 moves. I’m guessing somewhere around 8 moves is most fun to play, but if the last move is very forcing I’ll extend it a few moves. I’ll probably avoid variations including captures, as they are very rare in the first few moves anyways.
I relaxed my “optimal” requirement a little, allowing evaluations of ±1 point or so.
I’ve finished a basic pop-up help page. The pull request for this has been sent to @okonomichiyaki.
By the way, have you all checked out the “Add to homescreen” feature (via your mobile browser) on the Josekle page? This puts an icon on your homescreen that launches the website kind of like an app. Basically, it opens the page in your browser (hence, using the same local storage), but it automatically hides the browser address bar and navigation panels to give more room by default, and maybe shows a small splash screen on launch.
My next focus will be supporting the 9x9 Fusekle mode.
@antonTobi, do you still have the convention that every solution is denoted by and ends with a childless leaf node?
So far, I’ve put together a very basic editor tool where one can load and edit an SGF, and then export all paths to childless leaf nodes as a “puzzles.js” solutions file. Here is the live tool on my dev fork:
https://yewang.github.io/josekle/puzzles.html
I still need to add the feature to append to an existing file, which should avoid duplication, and only shuffle the new sequences added to the end. This should facilitate managing the curation of the solution set as an ongoing process. Also, I need to implement solution shuffling. Apparently, javascript does not have a built-in array shuffling routine, but it is straightforward to copy-paste a solution from a Google search.
I also plan to duplicate and modify the app.js file (maybe with some degree of modularization) to specifically handle Fusekle, which will use the “old-style” format for the solutions, and also create a separate fusekle.html page that will host the game (along with maybe a custom help screen for that).
Question for you experts: If you save information in local storage, do you have to make an “accept cookies?” prompt? I don’t know the answer, it might also depend on the laws of ones country.
Probably depends on laws like GDPR, but it might also depend on what you want to do with the cookies.
It might be ok to just use them to store session data, like if you’ve attempted this puzzle already today.
Might require acceptance if you plan to sell their user data to google or whoever so they can sell us the latest go courses and gobans every time we click a YouTube video
Unrelated: it’s a bit hard to click the share buttons now on safari mobile. I have to do a mixture of zoom and scroll to find them, neither work by themselves
I thought the “standard accept cookies prompt” that you see almost everywhere these days only asks for permission to save data, i.e. additional permission is needed to pass on the data. Is this assumption wrong?
In a lot of cases cookie banners are about sharing (e.g. selling) your data.
Regarding local storage I guess it depends on what you store there and what you do with that data. If it’s not personal information, I don’t think GDPR kicks in. Are stored Josekle guesses personal information? I don’t know about that.