[Computer-go] Japanese byoyomi in SGF files (possible KGS Bug?)
chaz.gwenapp at gmail.com
Sun Jul 28 18:50:53 PDT 2013
I would have expected "BLOB" more than "BLOB". 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 BLOB 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]OBWL[timeremaining]OW 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.
On Sun, Jul 28, 2013 at 8:42 AM, Erik van der Werf <erikvanderwerf at gmail.com
> 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
> 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
> 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 "BLOB"
> 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 "BLOB", 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.
> Computer-go mailing list
> Computer-go at dvandva.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Computer-go