Hello, I support this extension vry much, but I believe that the
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.
On Tue, Jul 29, 2008 at 10:48 AM, Stuart A. Yeates <syeates@...> wrote:
> Great idea Anro
> Is he plan to extend sgfc to cover this and optionally expand trees?
> The idea of common subtrees is very common in computer go. I'm not
> sure whether any of the computer go programs externalise their search
> trees though. May I suggest that his issue is also raised on the
> computer go mailing list?
> I've forgotten what the exact SGF terminology is, but could we
> 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
> On Tue, Jul 29, 2008 at 7:53 PM, Arno Hollosi <ahollosi@...> wrote:
>> Dear all,
>> I have been approached (again) with a proposal to add links to the SGF
>> standard. As I clearly see the need for this, I would like to add it to
>> core SGF FF specification. I'd like your input on this issue before
>> finalizing the syntax.
>> Here's the proposal from David Bush, author of the Twixt SGF spec:
>> TP[ simplestring ] is a node annotation property. It means this node
>> represents an identical position by TransPosition of moves to another
>> node in the tree. The value is the same as the N property of a target
>> node which must be listed earlier in the file, and must not be an
>> ancestor of the TP node. This might be useful for an opening library,
>> or anywhere that alternate move orders are plausible. A TP node should
>> be a leaf node in the file.
>> Effectively, TP is like a macro call. The intention is for the software
>> to copy the subtree of the target node to the location of the TP node.
>> Strictly speaking, the two positions need not be completely identical,
>> as long as this copied subtree with all its moves, evaluations, and
>> every other property is valid in this new location.
>> comparing this with e.g. last years idea from Andre (Kogo's Dictionary)
>> Oftenly identical positions of stone result from different orders of
>> placements of these stones which are to be found in very idfferent
>> branches of joseki. In such a case, the following joseki variations are
>> included only once, and after the other order of placements a reference is
>> given. But this reference is only a description, not a hyperlink, and that
>> is unnecessarily complicated for me as author and the users and frustrated
>> to search through the branches instead of simply clicking
>> like in HTML.
>> I propose the following syntax:
>> AC[example] Anchor
>> LI[example] Link
>> The anchor is hidden to the viewer. The simplextext of the Link is
>> displayed in like that of C and underlined. Clicked, the sgf viewer
>> jumps to the move in the branch where the Anchor with the same simpletext
>> My currrent favourite option is to use N as the anchor, and LI/TP
>> have to decide on a name) as single property in a node. Also, we could
>> about allowing links inside C.
>> I'd like to hear your opinions.