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

Suggestion on Time Property

Expand Messages
  • Shigeru Mabuchi
    Hello, I m currently working on a SGF browser and I have problems dealing with stuffs that FF[4] cannot handle. Here are some of the suggestions that I would
    Message 1 of 6 , Jan 31, 1999
    View Source
    • 0 Attachment
      Hello,

      I'm currently working on a SGF browser and I have problems
      dealing with stuffs that FF[4] cannot handle. Here are some
      of the suggestions that I would like to make:

      (1) Time for each move

      As you know, BL and WL does not provide info for the time taken for
      each move, due to the byo-yomi system. For instance, if you play a
      5 10 game on the net, and your remaining time is 4 minutes before
      you enter the first byo-yomi. Then, if you use 11 minutes for the
      next move, your remaining time is 3 minutes, which is the same as
      the remaining time when you think for only 1 minute. In both cases,
      BL or WL show the same value.
      This is very inconvenient in many situations, such as when you
      want to replay a game by simulating the actual game speed.
      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..)

      Some WING-support SGF browser has already taken care of TL[].
      I will be glad if you consider adding TL[] to FF[4].

      TL[] has an optional value to record the netlag. That is not important
      and can be deleted if you think unnecessary).
      I only added it in order to prevent client-time cheat, because the
      IGS protocol does not provide any checksum function for the client
      time feature. (You can think for hours and cheat it to 1 second
      by input the client time by hand)


      (2) Time properties to record the game time system

      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
      add some properties to record these time system numerically,
      instead of by text. In that case, advanced programs will be able
      to replay the game by real-time simulation, also, computer go
      programs can record the actual time if they play under a system
      with byo-yomi or extra time.
      Basically, most of the time system can be classified using
      the following parameters:

      (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,
      (C) Byo-Moves: Number of moves required to make in each
      Byo-yomi period.
      I guess OM[] is for this. (Overtime = Byoyomi?)
      (D) Length of Extended Thinking Time:
      FF[4] does not have properties for this.
      Used in many fast game system, such as NHK Cup, CCTV Cup..
      May require properties for B and W because it might differ
      in handicap games.
      Suppose we use EW[] and EB[] for this.
      (E) Number of Extended Thinking Period
      Same as (D).
      Suppose we use NW[] and NB[] for this.

      All time-system, as far as I know, can be represented by the
      above properities. Let's look at some examples:
      (Sorry if you are not family with the Titles and Tournament
      systems introduced here)

      Ex1: NHK Cup, CCTV Cup
      TM[0] OP[30] OM[1] EW[60] EB[60] NW[10] NB[10]
      Ex2: TV-Tokyo Fast-Go Tournament, and etc
      TM[0] OP[30] OM[1] EW[180] EB[180] NW[2] NB[2]
      Ex3: Standard 10 15 game on IGS
      TM[600] OP[900] OM[25] NW[0] NB[0]
      Ex4: Standard International Pro Game
      TM[10800] OP[60] OM[1] NW[0] NB[0]
      Ex5: Kisei/Meijin Challenging Match
      TM[0] OP[60] OM[1] EW[60] EB[60] NW[480] NB[480]

      Ex5 might be confusing. But logically it is true because
      all time record are measured in minutes and all moves made
      within 59 seconds are counted as no-time is consumed, even
      before the so-called 10 minutes-left byo-yomi starts..
      The 'byo-yomi' in this case make no difference, except that
      the timekeeper starts counting 'byo' (second) to alert the
      players.

      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[]

      NW and NB is unlimited in this case so we would need to
      define a default for such case, like NW[] or NW[-1] or NW[?]
      ... not sure which is most appropiate.

      .
      The above description might be difficult to understand if
      you are not familiar with the time-system used in most of
      the pro's title games. However, I think it is important to
      keep numerical time record for the game, and with TL[],
      an advanced program can replay a game honestly by
      real-time simulation, if all the time properties are input
      correctly..

      Please consider on adding these properties to FF[4].
      Any comment is welcome.

      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 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 2 of 6 , Feb 1, 1999
      View Source
      • 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 3 of 6 , Feb 1, 1999
        View Source
        • 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 4 of 6 , Feb 1, 1999
          View Source
          • 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 5 of 6 , Feb 1, 1999
            View Source
            • 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 6 of 6 , Feb 2, 1999
              View Source
              • 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.