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

Re: Answers, Questions, and Thoughts

Expand Messages
  • 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 1 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 2 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 3 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.