[Computer-go] Japanese byoyomi in SGF files (possible KGS Bug?)

Chaz G. chaz.gwenapp at gmail.com
Sun Jul 28 18:50:53 PDT 2013


Hi Erik,

I would have expected "BL[2]OB[0]" more than "BL[2]OB[3]". Ultimately, it's
a bug in sgf, not KGS.

I think that BL (WL) and OB (OW) were documented with Canadian byo-yomi in
mind, where BL[120]OB[3] meant that Black has 120 seconds to play 3 stones.
The length, format, and number of Byo-yomi periods in a game should be
tagged under OT. With Japanese byo-yomi, the literal interpretation of sgf
properties would store BL[timeremaining]OB[0]WL[timeremaining]OW[0] for all
periods of byo-yomi play. Using OB(OW) to mark the number of byo-yomi
periods left is not the documented interpretation of sgf files but allows
for a more plausible recreation of the game.

Best,
-Chaz

On Sun, Jul 28, 2013 at 8:42 AM, Erik van der Werf <erikvanderwerf at gmail.com
> wrote:

> Hi All,
>
> I was just looking at how Japanese byoyomi time information is stored in
> sgf files. The spec at http://www.red-bean.com/sgf/properties.html tells
> us:
>
> Property: BL (WL)
> Function: Time left for black (white), after the move was made.
> Value is given in seconds.
>
> Property: OB (OW)
> Function: Number of black (white) moves left (after the move of this node
> was
>  played) to play in this byo-yomi period.
>
> Now let's say we're playing in Japanese byoyomi, e.g., with 3 periods of
> each 12 seconds. It's our turn, we think for 10 seconds and then make a
> move. In this case I would have expected the game record to show that we
> thought about it for 10s (2s left) using the BL/WL property. I.e. I would
> have expected "BL[2]OB[3]"
>
> However, this is not what's happening when I look at some sgf files I got
> from KGS. What happens there is that after the move is made the clock
> resets to 12 seconds (the time available for the next move), and that value
> is stored in the sgf. So, once in Japanese byoyomi the sgf just shows a
> long list of "BL[12]OB[3]", which in my opinion is not very informative
> (all it tells us is that the move was completed within the period, but not
> exactly how much time it took).
>
> I'm tempted to think that this is a bug, but since it might also be a
> difference of interpretation of the spec I'd like to hear what others
> believe is the correct implementation.
>
> Best,
> Erik
>
>
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20130728/de152fef/attachment.html>


More information about the Computer-go mailing list