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

Re: Suggestion on Time Property

Expand Messages
  • Robert Jasiek
    ... I agree that time properties should be specified more clearly. ... What about special rules that count no time for certain moves? E.g. a so called token-go
    Message 1 of 6 , Feb 1, 1999
    • 0 Attachment
      > (1) Time for each move

      I agree that time properties should be specified more clearly.

      > All time-system, as far as I know, can be represented by the
      > above properities.

      What about special rules that count no time for certain
      moves? E.g. a so called token-go or even just a normal
      handicap go game might have no time recording for the
      initial passes respectively handicap plays. Also during
      the late stages of the game time can stop and resume in
      different ways. (Not to mention spectecular adjournment
      rules.)

      Also amateurs like to experiment with all kinds of time
      systems, e.g. mutually exchanged times.

      Such things can be recorded with TM[] if entered manually,
      but this can be a nasty job. IMO, given the rules and the
      move context, a property should detect the resulting times
      automatically.

      > A very peculiar case is the Ing's Cup, due to the komi-
      > penalty when a player used up his/her time. However, it
      > still can be grouped as
      > TM[10800] EW[180] EB[180] NW[] NB[]

      Then how is the penality komi deducted from EW[] and EB[] ?
      With current Ing rules it would be clear, however, with
      slightly different rules it can vary. So one would need
      some PP[] property in move nodes for penality points of any
      kind. I.e. PP are additional komi collected during a game.

      --
      robert jasiek
      http://www.snafu.de/~jasiek/
    • Arno Hollosi
      Dear Shigeru, thanks for your suggestions on time extensions for FF[4]. I think it s true that FF[4] doesn t have sophisticated features for recording time.
      Message 2 of 6 , Feb 1, 1999
      • 0 Attachment
        Dear Shigeru,

        thanks for your suggestions on time extensions for FF[4].
        I think it's true that FF[4] doesn't have sophisticated
        features for recording time.

        Please see my next email about my basic attitude torwards
        new properties.

        About your suggestions:

        > Therefore, I added a property TimeLapsed on WING, in order to
        > replay a game on the server at the actual speed (or by double speed..)
        > TL[] has an optional value to record the netlag. That is not important
        > and can be deleted if you think unnecessary).

        Seems sensible.
        So the definition is TL[client time][netlag time]?
        This property relies on the order of the values, e.g.
        client time HAS to be first, and netlag time second.
        I think this is dangerous as some programs may change
        the order of the values. Therefore I suggest either
        omitting netlag time, or using a compound type value
        TL[client time:netlag time].


        > There are many types of time system used in Go games. I am not
        > sure if you are aware of it. I would like to suggest that we

        We are aware of it. That makes it so difficult to create a
        small, efficient set of properties. That's why we reduced
        timing properties to an absolute minimum in FF[4].
        You might have missed that we plan to remove OT and make
        TM[] a SimpleText value without mandatory format.

        > (A) Intial Time Limit:
        > FF[4] already has it. TM[ ]
        > (B) Byo-yomi: Length of each Byo-yomi Period
        > I'm not sure but guess that OP[] means it,

        OP isn't part of FF[4]. OP was introduced in FF[3] and
        isn't used any longer. Instead we created OT[] which should
        describe the byo-yomi system (moves/time etc.)
        But as pointed out above, we think about abandoning OT and
        move that information into TM as well.

        > (C) Byo-Moves: Number of moves required to make in each
        > Byo-yomi period.
        > I guess OM[] is for this. (Overtime = Byoyomi?)

        OM was defined in FF[3] and is no longer used in FF[4].

        > (D) Length of Extended Thinking Time:
        > (E) Number of Extended Thinking Period

        As Robert pointed out there are even more cases to think about.
        Your extensions seem to cover most systems used in professional
        tournaments.
        I understand your need for the TL property, but why do you
        need a computer-readable form of the byo-yomi system?
        It's not essential for replaying.


        /Arno
      • Shigeru Mabuchi
        Thanks for your response. ... I didn t consider very special case or local rules used by amateurs because absolutely there is no chance to standardize them.
        Message 3 of 6 , Feb 1, 1999
        • 0 Attachment
          Thanks for your response.

          Robert Jasiek wrote in [sgf-std] Re: Suggestion on Time Property:

          >What about special rules that count no time for certain
          >moves? E.g. a so called token-go or even just a normal
          >handicap go game might have no time recording for the
          >initial passes respectively handicap plays. Also during
          >the late stages of the game time can stop and resume in
          >different ways. (Not to mention spectecular adjournment
          >rules.)
          >
          >Also amateurs like to experiment with all kinds of time
          >systems, e.g. mutually exchanged times.

          I didn't consider very special case or local rules used by
          amateurs because absolutely there is no chance to standardize
          them.

          >Such things can be recorded with TM[] if entered manually,
          >but this can be a nasty job. IMO, given the rules and the
          >move context, a property should detect the resulting times
          >automatically.

          I guess TM[] still can be used as a simple text property,
          if we use it in a form like TM[3600 : whatever ].
          For now, we can do nothing with the TM property because
          it is defined as Simple Text type and if it almost
          behaves as a private property. Some uses TM[1 hour]
          and some uses TM[30 minutes] and there is no way to
          retrieve numeric info from TM[] if we need to resume a game
          >from an SGF file with the clock continues.

          And the above sentence is also an answer to Arno's question
          on "What do we use those Time System definition properties for?".

          A very simply example is, suppose ,just suppose :-), we want to
          use a byo-yomi system for the next FOST cup (like 5 seconds
          per move, in order to prevent program from losing on time while
          leading an overwhelmihng game because her stupid opponent does not know
          how to resign, instead of the programmer or the judge demanding for a
          resign. If these properties are in effect and the program keeps it,
          a game can be resumed correctly if it happened to be adjourned by accident.

          Although there are still many go programs don't even care keeping their
          clock working correctly or can't even keep a proper SGF record, that
          does not mean that no standardization is required, right?
          And if you create a good standard, definitely many programmers would
          know what to work for, in order to improve their programs. As a
          matter of fact, many programmers give up on taking care of this
          time record becuase the current SGF format gives no proper guideline.

          >> A very peculiar case is the Ing's Cup, due to the komi-
          >> penalty when a player used up his/her time. However, it
          >> still can be grouped as
          >> TM[10800] EW[180] EB[180] NW[] NB[]
          >
          >Then how is the penality komi deducted from EW[] and EB[] ?
          >With current Ing rules it would be clear, however, with
          >slightly different rules it can vary. So one would need
          >some PP[] property in move nodes for penality points of any
          >kind. I.e. PP are additional komi collected during a game.

          I guess we should use KM[] to keep the final komi for
          scoring purpose. Then, perhaps we can use GC[] or C[] in the
          related move (when time was extended and komi penalty added)
          to keep track of how the komi changed?



          Shigeru Mabuchi

          ======= W ======= I ======= N ======= G ======
          World-wide InterNet Gokaisho
          ==============================================
          Shigeru Mabuchi (mab 2d* on WING)
          http://wing.home.ml.org/
          WING Server Address: wing.brlnet.net 1515
        • Shigeru Mabuchi
          Hi, Arno, ... Actually, I added TL[] before I read the complete document on FF[4]. I thought the FF[4] document in the CGF Journal (Japanese only) was the
          Message 4 of 6 , Feb 1, 1999
          • 0 Attachment
            Hi, Arno,

            Arno Hollosi wrote in [sgf-std] Re: Suggestion on Time Property:

            >About your suggestions:
            >
            >> Therefore, I added a property TimeLapsed on WING, in order to
            >> replay a game on the server at the actual speed (or by double speed..)
            >> TL[] has an optional value to record the netlag. That is not important
            >> and can be deleted if you think unnecessary).
            >
            >Seems sensible.
            >So the definition is TL[client time][netlag time]?
            >This property relies on the order of the values, e.g.
            >client time HAS to be first, and netlag time second.
            >I think this is dangerous as some programs may change
            >the order of the values. Therefore I suggest either
            >omitting netlag time, or using a compound type value
            >TL[client time:netlag time].

            Actually, I added TL[] before I read the complete document on FF[4].
            I thought the FF[4] document in the CGF Journal (Japanese only) was
            the newest and complete doc, but realized that it was only a summary
            of the very first FF[4] lately. (OP[] was still introduced as a FF[4]
            property there)

            Therefore, I use OP[] for Byo-Time and OM[] for Byo-Move in SGF
            file issued by WING, because it is the only possible property I can find.
            And, since there wasn't any Property Format guideline introduced in
            the CGF journal, TL[] was designed as TL[mm,nn] where mm is the
            time lapsed and nn is the net-lag. Of course, now I know it
            should be TL[mm:nn] or TL[mm][nn] if I want to pack them together.

            Anyway, to follow the guideline, perhaps we can use

            TL[integer:integer] or simply
            TL[integer]

            and use a new property (or OV[]?, which seems to have same
            meaning) for the net-lag..

            What do you think?

            >OP isn't part of FF[4]. OP was introduced in FF[3] and
            >isn't used any longer. Instead we created OT[] which should
            >describe the byo-yomi system (moves/time etc.)
            >But as pointed out above, we think about abandoning OT and
            >move that information into TM as well.

            I agree that using TM[text] is the easiest solution, but
            meanwhile it also means to give up on searching a digital
            solution and put everything in analog, the old fashion.
            (Not always bad) :-)

            Although it is impossible to illustrate every types of
            time systems, especially those minor one used in Amateur
            games, at least, if possible and reasonable, why don't
            we focus on the pro's game and major amateur events and
            build a standard on it?

            To be frank, I hate writing long sentences into TM[] for
            every pro games I entered, with each TM[] line slightly
            different in each SGF file. :-)
            In fact, in the SGF browser I am working on, the users
            merely need to type the keyboard even if he wishes to
            enter a large variety of game infos. Many PC beginners,
            includeing high-dan Pro of Nihon-kiin, has been asking
            for such a SGF browser so that they can handle easily.
            Most infos are stored in database and can be recalled
            by a few mouse clicks.

            >> (C) Byo-Moves: Number of moves required to make in each
            >> Byo-yomi period.
            >> I guess OM[] is for this. (Overtime = Byoyomi?)
            >
            >OM was defined in FF[3] and is no longer used in FF[4].
            >
            >> (D) Length of Extended Thinking Time:
            >> (E) Number of Extended Thinking Period
            >
            >As Robert pointed out there are even more cases to think about.
            >Your extensions seem to cover most systems used in professional
            >tournaments.
            >I understand your need for the TL property, but why do you
            >need a computer-readable form of the byo-yomi system?
            >It's not essential for replaying.

            Please refer to my last response for my answer.

            There is one more reason that I'm sticking on this.
            (Actually more to come) :-)

            As you know, Nihon Kiin is not using SGF for their game record,
            because of the software they use. However, they are interested
            in using SGF because the current UGF format isn't as sophisticated
            as SGF. I have talked to Sakai 9p of Nihon Kiin a few time and
            to keep pro's game into a useful database, we need to
            consider the pro's demand. Infos which look unimportant to us
            like judges(mediators), timekeeper, recordkeeper, are important
            infos for them. I don't want to write everything at a time
            so I'll write again later.


            Shigeru Mabuchi

            ======= W ======= I ======= N ======= G ======
            World-wide InterNet Gokaisho
            ==============================================
            Shigeru Mabuchi (mab 2d* on WING)
            http://wing.home.ml.org/
            WING Server Address: wing.brlnet.net 1515
          • Robert Jasiek
            ... I agree. Currently that would be yet more information to be put in GC[]. Adding more and more properties for such needs is possible but not too pleasant,
            Message 5 of 6 , Feb 2, 1999
            • 0 Attachment
              > Infos which look unimportant to us
              > like judges(mediators), timekeeper, recordkeeper, are important
              > infos for them.

              I agree. Currently that would be yet more information to be put
              in GC[]. Adding more and more properties for such needs is
              possible but not too pleasant, either. AYK, I like general
              properties. E.g. we seem to need something like IP[] for
              involved persons that could read like

              IP[black:Beauty Belle][white:Marc Whale][judge:Jane Jerome]
              [judge:Bill Benefit][timekeeper:Timothy Trust]

              The same would be possible for other classes of properties,
              e.g. markups or comments or conditions (incl. time). Thereby
              an FF[5] would be well structured.

              While SGF is the most powerful go file standard, the
              current situation is a little ridiculous. E.g. each
              coordinate can have at most one markup, but the standard
              includes many properties for assigning one possible markup.

              --
              robert jasiek
            Your message has been successfully submitted and would be delivered to recipients shortly.