Loading ...
Sorry, an error occurred while loading the content.

298Re: New SGF property: transposition / links

Expand Messages
  • David Bush
    Jul 30 8:08 AM
    • 0 Attachment
      > Bill wrote:
      > 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.

      Not only that, but if the target node is pointed to by more than one
      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
      compressed file.

      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:
      > 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.

      Sorry, I missed your point in my earlier post. But I'm not sure what
      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 actually
      > 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.

      Whether TP is a macro call or a link, these same issues would crop up.
      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 I
      > 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)?

      Under what circumstances would you want to change one subtree but not
      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
      different?

      > How do I tell the SGF program to create a new TP[] or
      > remove/split/copy the tree denoted by N[]. I think the GUI issues
      > (and therefore the usability of this extension) are not to be
      > underestimated.

      Is this SGF program a text editor or a GUI? If it's a GUI which can
      save files in SGF format, why would you want to deal with TP calls?

      > The semantics for links, the navigation, display, etc. are much
      > easier for links than for macro-like TP[].

      I don't mean to require programmers to treat TP one way or the other.
      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.

      syeates said:
      > I'm also interested in the exact semantics of TP[] with respect to
      > 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.

      My proposal is that the positions need not be identical as long as
      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.
    • Show all 12 messages in this topic