In-game score estimator bugged

The in-game score estimator seems to be wildly over-estimating white’s score in many of my games.

Pictures of games in progress, please don’t comment on moves.

1 Like

after game ends, there is better score estimator

while your game is in progress, only crazy estimator is available

Yes, but this is something different. Crazy score estimator by what it shows on the board vs in the calculation at the bottom seems to be different.
It says white ahead by 219 points in the last picture, but look at the points it shows for each color on the board.

At first I thought komi was mistakenly set at 65 instead of 6.5 or something like that but the discrepancy is not consistent across different games.

As far as I can tell, it is always white being given bonus points, regardless of whether I am white or black, so it may still be something to do with komi

1 Like

try to close all borders in analyze mode and then press estimate

If your games are still in progress, we are not allowed to comment them even through the eyes of the score estmator.

Now i looked a bit the three first ones. I’m not going to answer directly, i would just say that the estimation is completly wrong ok but it’s up to you to take it as it is and modify it by your own assessments on group status, sure territories and endgame etc…
I never use this misleading SE myself, better do the real thing as being at the mercy of misconceptions.

I ll be fine to debate later, when games finish if there a white’s bias or not.
Happy gaming!

I am not talking about whether or not the estimator is counting groups or territory correctly.

If you count what the estimator shows as white and black on the board and compare it to the number at the bottom, you do not get the same thing. Something is going wrong with the arithmetic.

Here is one with borders closed.

1 Like

Can’t say if it is always in white favor (or a trend). In this hypothetical position the counting (difference between territories) is quite wrong yes. SE doesn’t know how to count beyond its assessment of territories.
To be sure even if obvious, i counted grossly black territories (using chinese rules).
like 164ish so white is around 200ish and so the difference can’t be 200. (Komi won’t matter)

looks like a bug I never seen before

1 Like

Yes the score estimator has always been bad, but now it’s completely off. In one of my games I played out all moves until the end, including dames. The score estimator says I’m winning by 41.5 but when I count manually I’m actually losing by 12.5 points.

1 Like

Are you white or black in that game?

Going through my games list, I don’t see the bug in my games that have chinese scoring though I have less of those compared to japanese rules

Just to be clear, i didn’t make any assessment of which way the SE is working (if it’s linked to rulesets).
I used chinese myself just because i’m more confortable here to evaluate :blush:

It’s a game in which I’m black, Japanese rules.

Ok so the bug is in counting captures, which is why it doesn’t show up in Chinese rules.

Below boards only differences in the bottom right around S5. And look at number of captures at the top

Seems like a captured stone is worth 20 points. It could be an interesting Go variant

3 Likes

20x20 review uses old estimator for everyone:


4 Likes

In case it helps, here is what we fixed about two years ago to make the in-game score estimator follow Japanese rules:

I don’t see any recent changes in the same part of the code though.

1 Like

I made some changes to the score estimator a few weeks back, they may have been deployed recently. I’ll take a look, and sorry in advance if I borked it!

Just so I understand correctly, the issue only happens with Japanese scoring, and its because captures are incorrectly accounted for?

4 Likes

That’s what seems to be going on, yes. Captures are being counted at 20 pts each. The demo board by @stone.defender shows it nicely.

Dead stones on the board are counted correctly though

2 Likes

I think I found the cause and submitted a fix for review (goban#142). I also included a test that will hopefully prevent bugs like this in the future. Thanks all for the clear report and investigation on this!

20 pts

It ended up being height! The (very silly) bug looked something like this:

for (let y = 0; y < height; y++) {
    for (let x = 0; x < width; x++) {
       ...
    }

    // these lines were supposed to stay outside the for block
    score += engine.getWhitePrisoners();
    score -= engine.getBlackPrisoners();
}
6 Likes

Thanks for the laugh.

3 Likes