Life In 19x19

I've been doing some hacking on some SGF files. I found a bug in my code: I have always assumed that Komi is always a whole multiple of 0.5 which causes it to panic when given a file from SmartGo's collection (from the iOS) version that contains:
as the Komi value. The file also contains
so this, presumably, is actually supposed to be 7.5 Komi.

Is it usual or the norm to encode Komi values in this way for Chinese rule SGF files? I.e. to record half the real Komi value in the `KM` property?

Would it make sense to detect that the Komi is a multiple of 0.25 and not a multiple of 0.5 and to correct the value by doubling it (for Chinese rules only) or would it make more sense to just ignore the value, use it in its incorrect form, and relax my sanity checks which reject values that are not whole multiples of 0.5?

The SGF FF[4] "Spec." (https://www.red-bean.com/sgf/go.html#KM) is not helpful as far as resolving this conundrum is concerned so I'm interested to know how everyone else deals with these oddities.

GoGoD (which is the source of SmartGo's database for a while now) tends to use 3.75 for Chinese games. If you do the Chinese half counting in units of "zi" as black's score distance from 180.5 instead of points then 3.75 is what you need on that scale.

Uberdude wrote:GoGoD (which is the source of SmartGo's database for a while now) tends to use 3.75 for Chinese games. If you do the Chinese half counting in units of "zi" as black's score distance from 180.5 instead of points then 3.75 is what you need on that scale.

This style causes problem with Go software. I've seen the komi value rounded to 3.8 in some packages which is really strange.

I'm interested to know how everyone else deals with these oddities.

What I find it odd is that you should regard as odd the practice of the nation that probably has more go players than the rest of the world put together.

Here is a typical example of how Chinese publications give the game metadata.
Komi is given as "Black gives 3¾".

As far as I can see, the only reason you need to mess around computationally with the komi value (as opposed to just displaying what is there in KM[]) is if you are calculating the score. But there are some genuine oddities in that case.

1. There are cases where the komi is integer and the result is decimal. For example, the a game in te quarter-finals of the 1s Ing Cup had 8 komi (Ing Goe) and the result was that Black won by one and five sixths (which I rounded to 1.83). There were other similar cases. Taiwanese magazines used to have to give extra diagrams just to explain the final count.

2. There are many cases where the komi was given as "5 but White wins jigo". This was not the same as "5.5" because a win without jigo ranked (in tournament ties) higher than a win with, and this was the reason why Go Seigen never became Meijin. It also had financial implications for individual games.

3. You cannot compute the score properly unless you know the rules. Some rule sets count points in seki; some don't. Some require an adjustment for handicap stones; others don't. One rule set (old Korean) require removal of non-boundary stones at the end.

4. There are many cases in Chinese games up to and including the 20th century where you cannot compute the score properly unless you take account of group tax, which cannot be specified properly in the sgf standard.

5. There are also many current cases (Ing sponsored events) where you can't compute the score accurately unless you know how many penalty points have been paid for extra time. Again the sgf standard does not allow proper recording of this (beyond devising a private setting).

6. There is also negative komi BTW.

This style causes problem with Go software. I've seen the komi value rounded to 3.8 in some packages which is really strange.

No. What causes such problems is sloppy, incompetent or idiosyncratic programming. Even the commonly used Eidogo program used on this forum often makes a hash of game metadata. The are major programs that use KO instead of KM, TE instead of EV. The use of C and GC is a worldwide mess. Etc, etc, etc.

One of the worst programming faults, in my view, because it involves changing the actual or potential result, is where programmers insist on making KM non-zero. This is especially common in handicap games where KM[0.5] is routinely added but happens also in no-komi even games.

Ultimately, the problem may lie in the historical fact that go in the west came mainly (though not initially) via Japan and Japanese (non-universal) practice has taken hold in many ways. It has been compounded here, though, by numbers-oriented people insisting on making go fit the software. This a classic case of the tail wagging the dog. Grrrr!

First, you need to understand the difference between full counting (komi) and half counting (komi):
http://home.snafu.de/jasiek/int.html
See also moku versus zi as counting unit:
https://senseis.xmp.net/?Moku
https://senseis.xmp.net/?Zi

Second, you must interpret a stated komi value for a stated ruleset whether it is a full or half counting value. Usually, komi with a fraction multiple of 1/4 is a half counting value and other komi are full counting komi, however, there is no guarantee for this. If all you have is a Chinese Rules statement and a value that looks like a half counting komi then probably it is. It is also possible that a full counting value is stated for a Chinese Rules game. Therefore, automatic conversions of komi values are bound to produce mistakes.

Third, do not confuse Ing Rules or - different! - Taiwanese Rules with Chinese Rules.

John Fairbairn wrote:No. What causes such problems is sloppy, incompetent or idiosyncratic programming.

...

This a classic case of the tail wagging the dog. Grrrr!

Ok. You've convinced me. I'll just let the Komi be and use it, verbatim, without trying to do anything fancy to it.

I'll silently ignore whole multiples of 0.25 in Chinese rule files and demote all Komi validation errors to warnings so that even the extremely strange values that you describe will pass without hindrance.

This agrees with my "round-trip" philosophy when dealing with oddities in SGF files: whatever I do, the output should match the input in all cases that aren't documented or that I don't fully understand.

Charlie wrote: I'll silently ignore whole multiples of 0.25 in Chinese rule files and demote all Komi validation errors to warnings so that even the extremely strange values that you describe will pass without hindrance.

I've bid 2 pi as komi in the Maidenhead tournament which uses komi bidding.

RobertJasiek wrote:First, you need to understand the difference between full counting (komi) and half counting (komi):
http://home.snafu.de/jasiek/int.html
See also moku versus zi as counting unit:
https://senseis.xmp.net/?Moku
https://senseis.xmp.net/?Zi

Second, you must interpret a stated komi value for a stated ruleset whether it is a full or half counting value. Usually, komi with a fraction multiple of 1/4 is a half counting value and other komi are full counting komi, however, there is no guarantee for this. If all you have is a Chinese Rules statement and a value that looks like a half counting komi then probably it is. It is also possible that a full counting value is stated for a Chinese Rules game. Therefore, automatic conversions of komi values are bound to produce mistakes.

Third, do not confuse Ing Rules or - different! - Taiwanese Rules with Chinese Rules.

The problem, here, is that the SGF standard isn't really a good standard.

Even fully understanding all of these concepts doesn't help much because different implementations of SGF interpret the definition of the properties differently and, in some cases, there aren't standard properties to store relevant information.

Uberdude wrote:

Charlie wrote: I'll silently ignore whole multiples of 0.25 in Chinese rule files and demote all Komi validation errors to warnings so that even the extremely strange values that you describe will pass without hindrance.

I've bid 2 pi as komi in the Maidenhead tournament which uses komi bidding.

What would you have done if your opponent demanded two pies on entering the counting stage?

Charlie wrote: The problem, here, is that the SGF standard isn't really a good standard.

It is dormant, and does not correspond very closely to present reality.
Some years ago I collected a very large number of SGF files from the net.
The page sgf.html has statistics on what was frequently found, and recommendations on what to write.

John Fairbairn wrote:

Scan0001.jpg

Komi is given as "Black gives 3¾".

Well, this actually translates to "Black gives 3¾ stones" with the unit clear stated. We do not have a field for the unit in SGF. And the SGF specification says "KM Komi game-info (Go) real" - komi is defined in real values not 'simpletext'. So you cannot say "sloppy, incompetent or idiosyncratic programming" when people try to follow standard. Of course the standard might be a bit sloppy but that is a different story.

aeb wrote: The page sgf.html has statistics on what was frequently found, and recommendations on what to write.

Fascinating!

I'd been using this (https://www.red-bean.com/sgf/) as my primary reference for SGF, along with personal observations from SGF files saved with the set of Go software that I personally use, but any extra resources are welcome and this link wasn't in my collection until now.

Thank you.