lightvector wrote:
The only way to get around the 25x25 restriction for a particular GUI program or match-playing software is to request that program or match-playing software to implement a way to handle coordinates for larger sizes compatible with the way KataGo extended the GTP protocol for coordinates. The way I had KataGo implement seemed like by far the most natural way to extend the protocol for coordinates, and is the same as a common choice that board editing GUIs or even spreadsheets like Excel/Google Sheets use to label more coordinates - namely, after Z, you get AA, AB, AC, .... but I'd also be open for adding minor hacks to do a different format if necessary to be compatible with something else.
Relative coordinates (
https://senseis.xmp.net/?Coordinates) are infinitely scalable. The symmetries of the goban are integral to this coordinate system; it
may be perfect for developing go engines. However I guess that current code might have to be completely re-written to take advantage of that. All points on the goban may be written in the form
ij, ij*, i*j, i*j*, ji, ji*, j*i, & j*i* (summarised as
i^j^ & j^i^). This illustrates how
all points described with identical numerals (that is all variants of
i^j^& j^i^)
are in the same position relative to their corner, taking all symmetries into account (including those across the goban's two main diagonals.)
I'm posting this on the off chance that experts such as
lightvector might see something worthwhile here.