I feel the original goal gets neglected here, though: one of the goals is to find a system that does not depend on knowing the exact coordinates of the move as a prior.
2 Likes
Back in 2017, in my first year of serious (lol) Go, I had some fun with coordinate systems. I invented:
Tengen-based cardinal direction, with kanji squares: https://senseis.xmp.net/?Coordinates#toc12
âBugcat tengen coordinatesâ: https://senseis.xmp.net/?BugcatsTengenCoordinates
Rotational coordinates, which I think is similar to what Kosh described: https://senseis.xmp.net/?Bugcat%2FRotationalCoordinates
And my favourite, Confluence coordinates, which I myself described as âstrictly esoteric and totally impracticalâ: https://senseis.xmp.net/?Bugcat%2FConfluenceCoordinates
2 Likes
If this is the main goal, then it is an interesting challenge.
Essentially the objective should be the definition a sort of language which avoids numbers (since using numbers combines/fits quite automatically with local or global coordinates).
So, if this is the goal, now I understand better the complexity (evaluated by me as unreasonable at first reading) of Bugcat method in the original post.
1 Like
When I place stones on the goban to reproduce a problem that I found in a book, for example, Iâm used to think in this way: I take as reference the closest hoshi point, then I memorize mentally from this reference the stone placement using common terms used in go like keima, extend, jump, diagonal, etc⌠This is my way to figure out the position of each added stone. So a method that can be proposed is the following:
- Define conventional abbreviation for each move from an hoshi point (or from any point)
- Hoshi points in the corner are named h1, h2, h3, h4 (counting clockwise from top-left)
- Hoshi points on the side are cardinal points, so abbreviated as n, e, s, w
- The central hoshi is named simply c
Until now it should be quite easy to remember. Since the hoshi points repeat themselves on the board regularly, we should find a simple way (alias) to remember moves starting from one of these generic points that should be used as the prefix of each move.
I propose e for extend as if in the reference point (h1, in the picture) there was a stone (but this is not actually necessary, it is only a convention to remember the given names of each move starting from here).
The clockwise numbering convention it appear natural to me and donât lead to any confusion because it address at maximum 8 positions that are similar for reflections and rotations.
Letter d can be used for diagonal move
Letter k for keima (knighât move), but we have to map 8 moves possible around the hoshi point and this should be easy to identify which keima is the related number registered on the script. For me it is.
Letter j for jump, so we have
Letters dj for diagonal jump as in
For moves that are three lines distant from the hoshi point, I cannot find abbreviation better than the following (suggestions are welcome):
Letters ok for o-keima (or bk for big-keima). Here again we have 8 options:
Letters ds for double space extension
please note that some of this outer point can be identified also from another reference point and the description (alias) of the point remain the same but the numbers change. For example in the picture above the hoshi point is h1 so a double space extension in the right direction from here whould become h1ds2 but this point is also known as nds4 (if we strart from the hoshi point named north). I suppose would be normal refer to the hoshi that is closer where the action is currently in place.
To identify 2-3 or 3-2 points from the hoshi I selected the letter l for light play as often it is referred to the art of setting stones with some space in between them (I was unable to find a better alias).
Finally, it remains the four corners of the picture that I labelled m since they (apart those placed on the border of the board) are the middle points among each hoshi points.
At the end of the day this should be the full picture for h1 (upper left of the board)
It can seems quite tricky, but as soon as I memorized the alias and adopted the same clockwise numbering logic for rotations and reflections of the same move, it is quite easy to point out a spot on the board and write immediately its name on paper. More important, it is true the opposite: find quickly where a stone is placed translating the script in action.
Collaterally, you can also abbreviate the script because the referring origin of this system can be different from the hoshi points and it can become really concise if you use as reference the last move played on the board (relative alias). You can simply substitute the hoshi prefix with an _ (underscore). The script become quite short in this way. If the distance from last played move doesnât allow to use the abbreviated version (if one of the players tenuki for example), then it is enough to repeat the reference hoshi point in the script omitting the underscore.
So for example if you are playing the following well-known joseki
| Number | B-W standard | B-W absolute alias | B-W relative alias |
|---|---|---|---|
| 1-2 | D4 - F3 | h3 - h3k3 | h2 - _k3 |
| 3-4 | D6 - C3 | h3j1 - h3d3 | _l8 - _ok5 |
| 5-6 | D3 - D2 | h3e3 - h3j3 | _e2 - _e3 |
| 7-8 | E2 - C2 | h3k4 - h3k5 | _e2 - _j3 |
| 9-10 | E3 - B5 | h3d2 - h3k7 | _k2 - _l7 |
The relative alias mechanism - I realized - is quite confusing because it works pretty well if you re-play a game making moves quickly and consecutively, - but - if you take a break and stop for a while it lacks of a quick reference to find the last move played. You should restart from the last standard reference point (hoshi) annotated in the script. In the example above and below, it means you should restart from the beginning)
At the end of my journey on this topic, I can say that the most natural manual scripting mechanisms seems to me the last one proposed by @yebellz which mix graphical and numerical local notation. For an emergency quick annotation of a game it should work fine. Iâm not sure if it works well also in middle game, when there is a mess of stones around the center. This should be true (or even worst) for the original method in this post proposed by @bugcat.
However, this method - that anyone can easily adapt - at the end of the day is no so different from the last proposed by @yebellz. I used alias instead of coordinates even if the coordinates are still there, since the clockwise numbering is a sort of polar coordinate system.
At the end, I think that my mechanism is more complex than the standard (column 2 in table above) from a pure scripting effort (more characters) but imho it is more clear when you are re-using the script to re-play the match. I can visualize mentally quite easily where the stone is placed looking at the absolute alias respect to the standard notation. On the other hand, it is also true that is not so easy (to me at least) find out immediately where the hoshi points are located in a board full of stones during the middle and the end-game. I donât know, I should try to record a real game to test it and replay the game starting from paper.
3 Likes
A hundred likes for this brilliant post!!
1 Like
This reminds me of Perl, and other write-only programming languages.
Minor savings in key strokes to write them, resulting in exponentially increasing times required to understand what was writtenâŚ
⌠I couldnât even understand the âand in long Englishâ version - it seems the coding of the shorthand requires the understanding of a whole language that is being coded, so your average person has a double decode (at least) needed to read it.
perl -Mstrict -we '$_ = "goto F.print chop;\n=rekcaH lreP rehtona tsuJ
+";F1:eval'
1 Like
I tried to make a program to convert Korschelt to your code, but my programming skills werenât up to the job. That was a waste of four hours or soâŚ
1 Like
Probably it was more simple scripting a little bit with Excel.
In 20 minutes I got thisâŚ
For the columns/rows where a double representation of the position is allowed, you have the relative column/row duplicated so that you can see both versions.
(link to the excel file)
(I checked and corrected some copy-paste error, now should be correct).
1 Like
I think even the original system requires some degree of recognizing the exact location of a move. Namely, it requires one to be able to identify which points are âsan-sanâ, âhoshiâ, âkomokuâ, etc., which is essentially analogous to recognizing them as 33, 44, 34, etc.
However, I think I see your point as being that the system should minimize the need to recognize the coordinates.
The corner relative systems that I put forward donât fully do that, since one still needs to be able to figure out the coordinates relative to the closest corner (e.g., from 11 to 99, and to recognize the positions on tenth line and tengen). While the corner relative systems donât fully remove the need to recognize coordinates, they do reduce the burden from absolute systems like Korschelt.
At first, I thought that it wouldnât be possible to completely remove coordinates from any system, but I think the latest method devised by @ayaros goes very far toward essentially accomplishing that. Granted, one still has to be able to recognize positioning relative to the nearest hoshi, but everything has been framed as recognition of relative shape rather than rote counting. Although I donât think this system is the most practical for recording a game, I do think it is a really nice demonstration of how the entire board can be linked together through familiar shapes.
2 Likes
The corresponding material to take quick notes on in Germany is â certainly â a beer mat (beer coaster). 
4 Likes