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

Re: Suggestion on Time Property

Expand Messages
  • 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 1 of 6 , Feb 1, 1999
      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 2 of 6 , Feb 1, 1999
        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 3 of 6 , Feb 1, 1999
          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 4 of 6 , Feb 2, 1999
            > 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.