# Question: Is AQ accounting for the number of handicap stones for score calculation? #84

Open
opened this Issue Feb 19, 2018 · 2 comments

Projects
None yet
2 participants

### pnprog commented Feb 19, 2018

Hi,

I am asking specifically when playing for Chinese rule. There is not 100% consensus regarding area scoring and handicap games, but it is usual to add the number of handicap stones to the points made by white. So that White score, after removing all dead stones, will be the sum of :

• the number of empty points surrounded by white stones only
• the number of living white stones on the board
• the value of komi (usually 0.5 point for handicap game)
• the number of handicap stones

For instance, Leela Zero accounts for it:
https://github.com/gcp/leela-zero/blob/5958e02cf539d42ee20704b664043036d5c3c18b/src/FastState.cpp#L150
And one can make the assumption that Leela does the same.
GNU Go does the same as well (http://git.savannah.gnu.org/cgit/gnugo.git/tree/engine/aftermath.c#n1185).

From what I can read in the code; AQ does not account for it:

Line 552 in 6902ab7

 double final_score = std::abs(score[1] - score[0] - tree.komi);

Could you confirm?

Owner

### ymgaq commented Feb 21, 2018

 Surely it is. It will be fixed in the next update.

Author

### pnprog commented Feb 21, 2018 • edited

 Hi! I crafted the enclosed SGF file (9 handicap stones, komi 11.5) and asked AQ to evaluate final_score. Result for AQ: B+132.5 In the same time, Leela, Leela Zero and GnuGo give B+112.5 If I count myself (Chinese rule): Black: area: 247 White: (area 114) + (komi 11.5) + (handicap 9) = 134.5 Result: B+112.5 Now, even without accounting for the handicap stone, it should be B+121.5 and not B+132.5 which seems to indicate that AQ does not accound neither for handicap (<- this might be ok, depending on rule set) neither for komi. pnprog-vs-pnprog.zip

Closed