298Re: New SGF property: transposition / links
- Jul 30 8:08 AM
> Bill wrote:Not only that, but if the target node is pointed to by more than one
> TP is fine with me, but the requirement that it's target N appear
> before the matching TP is strange. Why have it?
> I tend to agree with Bill. I think that most of us agree that we
> should keep the SGF game tree a directed, non-cylic graph. However,
> as Bill pointed out, as soon as someone reorders variations the
> TP and subtree denoted by N would have to change place as well.
TP, you would have to make sure N comes before all of them.
> That is not exactly easy on programmers either.I guess it depends on what the program does. It wouldn't necessarily
be a problem if the program deals with an expanded tree instead of the
The purpose of TP is to make generation of a file manually with a text
editor a little less tedious. If you have software that can save a
file in SGF format from a game tree generated with a GUI, ***THERE
SHOULD BE NO NEED TO DEAL WITH TP.*** So as far as I can tell, the
problem of reordering a file is based on the assumption that this
reordering is done manually, with a text editor. Just out of
curiosity, what would be gained by doing this?
As was pointed out in another post, GUI issues and file loading and
saving issues should be regarded as independent of each other.
> Michal wrote:Sorry, I missed your point in my earlier post. But I'm not sure what
> 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.
scope you want this extra information to apply to. Does a joseki
dictionary file concern itself entirely with one corner of a 19x19
board? Or are you talking about referring to another corner of the
board which was explored earlier in the same file? If the full-board
positions are not effectively identical by axis/color transformation,
there could be a problem when software tries to evaluate this
position. Joseki battles are of course not independent of each other.
Also, do you generate this dictionary with a GUI or with a text editor?
> ... If we think of it as a macro that actuallyWhether TP is a macro call or a link, these same issues would crop up.
> copies/expands to the subtree denoted by N we "mostly" know how
> to display the result.
> But can we really copy all properties as is? E.g. if
> transformations are allowed (axes, colors) what about comments like
> "in the upper left corner" or annotation properties like GB/GW
> (good for black/white), just to name a few issues.
GB versus GW could be automatically taken care of. You could just
ignore all comments in an copied subtree, or not copy them in the
first place if there is any kind of axis/color change.
> Important issue: what about editing/writing such a file? Suppose IUnder what circumstances would you want to change one subtree but not
> don't want to write the expanded tree, but the compressed macro-
> version. How does the user control whether changing a node affects
> both subtrees (N's and TP's) or only one of them (if the
> display looks exactly the same)?
the other? I'm not asking about axis/color changes here. Why should
the user have this option to make the subtrees of the compressed file
> How do I tell the SGF program to create a new TP orIs this SGF program a text editor or a GUI? If it's a GUI which can
> remove/split/copy the tree denoted by N. I think the GUI issues
> (and therefore the usability of this extension) are not to be
save files in SGF format, why would you want to deal with TP calls?
> The semantics for links, the navigation, display, etc. are muchI don't mean to require programmers to treat TP one way or the other.
> easier for links than for macro-like TP.
The SGF definition should work for any way the programmer wants to use
it. I just used the "macro" analogy as a way of explaining what I was
talking about. Sorry if I wasn't clear about that.
> I'm also interested in the exact semantics of TP with respect toMy proposal is that the positions need not be identical as long as
> ko calculations. If two subtrees have different previous board
> positions (as opposed to the same previous board positions in a
> different order) their children may have different legal moves.
> This is mainly an issue when considering the endgame rather then
> the opening book, of course.
every move, position evaluation, and everything else that gets copied
or linked to is equally valid in both situations. If there are
"irreconcilable differences" then they should be different subtrees.
In a ko situation, and perhaps for the most part in Go, different
battles are arguably not truly independent of each other, because one
usually is more important than the others at any given point. So TP
calls might not be appropriate if the subtree in question is large.
Also I recommend you take a look at my LO proposal (in a separate
thread) for dealing with LOcal battles.
- << Previous post in topic Next post in topic >>