291Re: New SGF property: transposition / links
- Jul 29 7:35 AM
> Hello, I support this extension vry much, but I believe that theDuplication by reflection and/or rotation is certainly important, but
> restriction of the identical position is too restrictive, when I was
> making my private sgf extension to solve this, I made the
> Label/Pointer tags but the pointer tag also contained information
> about transformation (axes, colors), so the dictionary joseki didn't
> need to repeat any variations with same logic.
this could usually be settled after the first two moves of the game.
Maybe a separate property should deal with this, which is restricted
to the beginning of the tree, maybe even in the game info node. You
might even use an existing property such as ON. Besides naming the
opening, the value in ON could indicate how the actual game is
oriented compared to the moves listed in the file. The
TP property should be allowed throughout the file, subject to two
restrictions listed below.
> I've forgotten what the exact SGF terminology is, but could weSince the first variation listed is the main variation, this request
> restrict the positions where this can occur so that the main line of
> play has no TP in it? That would keep it easy for "simple" programs.
> Since the full tree needs to appear somewhere, that doesn't seem
is covered by my two restrictions:
1. The target node must be listed before the TP node in the file.
2. The target node must not be an ancestor of the TP node.
This implies that the main variation cannot contain a TP property,
because all the nodes previous to a main node are ancestors of that node.
Regarding the issue of whether TP functions as a link or as a macro
call, I suppose that would be up to whoever writes the software that
uses it. The above restrictions are intended to avoid any endless loop
of references. That's not very likely in Go, but SGF is for many games.
- << Previous post in topic Next post in topic >>