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

Answers, Questions, and Thoughts

Expand Messages
  • Arno Hollosi
    Hi there, answers to some questions which popped up recently: ... Not really. So I think we should allow both: HA[0] and HA[1]. ... No. Should we define it?
    Message 1 of 4 , Jan 7, 1999
    • 0 Attachment
      Hi there,

      answers to some questions which popped up recently:

      Francois Mizessyn wrote:
      > Moreover, if HA[0] is allowed, does to forbid HA[1] make sense? :-)
      Not really. So I think we should allow both: HA[0] and HA[1].

      Martin Mueller wrote:
      > is it specified in the standard whose turn it is to play by default
      > after a setup property?)
      No. Should we define it?
      What's wrong with using either PL[W] or PL[B] where necessary?
      I might want to set up positions with noone to play :o)

      William M. Shubert wrote:
      > SY was once part of the standard. ... I should get rid of it ...
      Not to my knowledge. Maybe it was a computer-go property?
      Yes, you should change it to AP[].


      About problem sets and marking the right solution:

      I agree with Martin that TE[3] isn't good. Apart from using
      TE[] or BM[] how about using the V[] property instead?
      V[]'s value type is Real. Assume that all positive numbers
      solve the problem, and all negative numbers fail. You could
      have higher scores for 'better' solutions, e.g. in a life&death
      situation two moves save the group. But one gives the defender
      more territory or leaves less ko threats. The computer could
      add the values of various problems to give you a score
      (e.g. you reached 156 of 245 possible points).

      About where to set up the position (root node).

      Both types have advantages. I agree with David that if I load
      a problem file I'd like to see the problem immediatly. Btw,
      even in this case you can have more than one problem per file:
      SGF allows multiple gametrees in a file (see EBNF definition or
      Martin Muellers Honinbo collection.) Unfortunatly few programs
      support multiple Gametrees. I fail to see why.
      As Wms pointed out, it might be interesting how the problem
      arose, especially if it's some kind of joseki-problem.

      About variation levels (siblings or children) and marking the
      next move: FF[4] provides the ST[] property which solves these
      issues. Just set the ST[] in your problem files accordingly.

      Wms wrote:
      > Maybe on the SGF web pages we could have a collection of problems, not
      > really to solve, but just to see the different ways that problems may be
      > presented with SGF?

      I'm willing to add those files if I get some files for other "styles"
      as well. David? Martin?

      I think it would be nice if we could agree on one style, so that
      problem-collections may be spread among different programs.


      Btw, I made a first update to the SGF spec.
      Please have a look at
      http://www.sbox.tu-graz.ac.at/home/h/hollosi/sgf/history.htm
      to see what's new. Any comments?


      There are still some unresolved issues:

      - remove OT property and remove mandatory format for TM?

      - allow non-standard entries in strictly defined game-info
      properties if (and only if) the case is not covered by the
      definition


      Feedback welcome!

      /Arno
    • William M. Shubert
      ... I think that SY was proposed once to mean StYle , so you could tell the application that wrote the SGF file. It may have never made it into an actual
      Message 2 of 4 , Jan 7, 1999
      • 0 Attachment
        Arno Hollosi wrote:

        > William M. Shubert wrote:
        > > SY was once part of the standard. ... I should get rid of it ...
        > Not to my knowledge. Maybe it was a computer-go property?

        I think that "SY" was proposed once to mean "StYle", so you could tell the
        application that wrote the SGF file. It may have never made it into an actual
        standard; in any case, I'll take it out of my SGF files.

        > Both types have advantages. I agree with David that if I load
        > a problem file I'd like to see the problem immediatly. Btw,
        > even in this case you can have more than one problem per file:
        > SGF allows multiple gametrees in a file (see EBNF definition or
        > Martin Muellers Honinbo collection.) Unfortunatly few programs
        > support multiple Gametrees. I fail to see why.

        Cgoban doesn't support multiple gametrees because as far as I could see it
        added complexity with no benefit. If I want multiple game trees, I just put
        them in separate files all in one directory, then when I load the SGF file I
        can choose which one to see. With multiple game trees per file, you have to
        first choose the file, then choose the game tree within the file; why? Why
        not just choose them both at once? It seemed like adding the complexity of
        parsing multiple game trees and selecting game trees and building
        multi-game-tree files would be a waste of time.

        > I think it would be nice if we could agree on one style, so that
        > problem-collections may be spread among different programs.

        I have pretty mixed feelings about this. I make problem sets for my own use.
        If somebody else can find use for them, fine, but I'm not doing it for other
        people, so I want them to look exactly the way I like, and if the problem
        definition isn't the way I like things I'll probably just ignore it. In
        addition, I don't think you can define a standard problem set format that
        will well describe all the different types of problems (eg joseki vs.
        tsume-go problems).
        --
        Bill Shubert (wms@...)
        http://www.hevanet.com/wms/
      • David Fotland
        ... Since these are just machine readable comments and don t actually put stones on the board, I have no objection. ... I assume black to move at the root node
        Message 3 of 4 , Jan 7, 1999
        • 0 Attachment
          At 05:49 PM 1/7/99 +0100, Arno Hollosi wrote:
          >From: Arno Hollosi <ahollosi@...-graz.ac.at>
          >
          >
          >Hi there,
          >
          >answers to some questions which popped up recently:
          >
          >Francois Mizessyn wrote:
          >> Moreover, if HA[0] is allowed, does to forbid HA[1] make sense? :-)
          >Not really. So I think we should allow both: HA[0] and HA[1].

          Since these are just machine readable comments and don't actually
          put stones on the board, I have no objection.

          >
          >Martin Mueller wrote:
          >> is it specified in the standard whose turn it is to play by default
          >> after a setup property?)
          >No. Should we define it?
          >What's wrong with using either PL[W] or PL[B] where necessary?
          >I might want to set up positions with noone to play :o)

          I assume black to move at the root node if there is no PL[]. I think
          this is reasonable to add to the standard.

          >About problem sets and marking the right solution:
          >
          >I agree with Martin that TE[3] isn't good. Apart from using
          >TE[] or BM[] how about using the V[] property instead?
          >V[]'s value type is Real. Assume that all positive numbers
          >solve the problem, and all negative numbers fail. You could
          >have higher scores for 'better' solutions, e.g. in a life&death
          >situation two moves save the group. But one gives the defender
          >more territory or leaves less ko threats. The computer could
          >add the values of various problems to give you a score
          >(e.g. you reached 156 of 245 possible points).

          I changed back to TE[2].

          >
          >Wms wrote:
          >> Maybe on the SGF web pages we could have a collection of problems, not
          >> really to solve, but just to see the different ways that problems may be
          >> presented with SGF?
          >
          >I'm willing to add those files if I get some files for other "styles"
          >as well. David? Martin?

          I'll mail you a couple.

          >
          >I think it would be nice if we could agree on one style, so that
          >problem-collections may be spread among different programs.

          Agreed. The next Many Faces has an improved problem-set editor
          (based on multiple game trees in a single file). I hope that
          people start making and exchanging problem sets.

          >
          >
          >Btw, I made a first update to the SGF spec.
          >Please have a look at
          >http://www.sbox.tu-graz.ac.at/home/h/hollosi/sgf/history.htm
          >to see what's new. Any comments?
          >
          >
          >There are still some unresolved issues:
          >
          >- remove OT property and remove mandatory format for TM?

          Yes.

          >
          >- allow non-standard entries in strictly defined game-info
          > properties if (and only if) the case is not covered by the
          > definition

          Yes.

          David
          >
          >
          >Feedback welcome!
          >
          >/Arno
          >
          >------------------------------------------------------------------------
          >To unsubscribe from this mailing list, or to change your subscription
          >to digest, go to the ONElist web site, at http://www.onelist.com and
          >select the User Center link from the menu bar on the left.
          >------------------------------------------------------------------------
          >SGF spec: http://www.sbox.tu-graz.ac.at/home/h/hollosi/sgf/
          >Moderator: Arno Hollosi <ahollosi@...>
          >
          >
        • David Fotland
          ... I agree. This is why Many Faces doesn t support multiple game trees. I d rather have each game in a separate file in a directory so the user can use the
          Message 4 of 4 , Jan 7, 1999
          • 0 Attachment
            At 11:02 AM 1/7/99 -0800, you wrote:
            >Arno Hollosi wrote:
            >
            >> William M. Shubert wrote:
            >
            >Cgoban doesn't support multiple gametrees because as far as I could see it
            >added complexity with no benefit. If I want multiple game trees, I just put
            >them in separate files all in one directory, then when I load the SGF file I
            >can choose which one to see. With multiple game trees per file, you have to
            >first choose the file, then choose the game tree within the file; why? Why
            >not just choose them both at once? It seemed like adding the complexity of
            >parsing multiple game trees and selecting game trees and building
            >multi-game-tree files would be a waste of time.

            I agree. This is why Many Faces doesn't support multiple game trees. I'd
            rather
            have each game in a separate file in a directory so the user can use the
            interface they already know for selecting which one to open.

            Problem files are a special case, since a set of problems are examined
            sequentially, or just identified by number. This works very naturally
            with problem sets. I use .prb instead of .sgf for problem sets
            to make them easy to find. (And because I still support the old
            .prb MFGO format, which was compressed Ishi format).

            >
            >> I think it would be nice if we could agree on one style, so that
            >> problem-collections may be spread among different programs.
            >
            >I have pretty mixed feelings about this. I make problem sets for my own use.
            >If somebody else can find use for them, fine, but I'm not doing it for other
            >people, so I want them to look exactly the way I like, and if the problem
            >definition isn't the way I like things I'll probably just ignore it. In
            >addition, I don't think you can define a standard problem set format that
            >will well describe all the different types of problems (eg joseki vs.
            >tsume-go problems).

            I don't expect to see may problem sets, since there are copyright issues
            involved. If you enter a problem set from a book, I don't think you get
            the right to distribute them electronically. I don't expect many people
            to make up new problems. I'll have a lot more problems in the next
            Many Faces, but I had to get permission from the copyright owners.

            David

            >--
            > Bill Shubert (wms@...)
            > http://www.hevanet.com/wms/
            >
            >
            >
            >Attachment Converted: "c:\eudora\attach\wms5.vcf"
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.