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 <[email protected] > 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 > [email protected] > http://dvandva.org/cgi-bin/mailman/listinfo/computer-go >
_______________________________________________ Computer-go mailing list [email protected] http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
