online-go / score-estimator Goto Github PK

The SSL connection fails as such:

requests.packages.urllib3.exceptions.SSLError: hostname 'ggs.online-go.com' doesn't match either of '*.idviu.io', 'idviu.io'

I tried fetching with http but no luck there either. http://ggs.online-go.com/napi/game-state/8605720/ just shows READY with no actual game info.

o and _ for player stones result in text output which is not easily read by human eyes. Capital O and capital X are more readable.

Cosmetic but, simple to change, for the sake of human readability...

in function: bool Goban::is_eye(Point pt, Color player) const

the original code:
if (board.countEqual(corners, -player) >= (corners.size >> 1) && board.getMinLibertiesOfSurroundingGroups(pt) <= 1) {
i think it should be
if (board.countEqual(corners, -player) >= (corners.size >> 1) || board.getMinLibertiesOfSurroundingGroups(pt) <= 1) {

any condition may cause false eye, so it should be ||, not &&?

Another option which could be worth investigating for scoring finished games is to use Zen:
It has the best playout policy imaginable for this: perfect handling of sekis, semeais, basic life and death i guess also ... Running just a few playouts would probably be enough to get the same accuracy as gnugo in a fraction of the time.

Getting it to run on linux might be a bit convoluted though, best would be to work out a deal with them.
If price looks like an issue i'm thinking if it's a one time cost all it takes is one generous donator =)

Hi, i was looking at jmgilmer/GoCNN and then noticed in the training pipeline he used gnugo to figure out dead stones and determine the final board position.

It strikes me now, a lot of people use it for that purpose because it's really good at it actually.
Has it been tried on ogs before ?

I did a quick test on ogs estimator test suite, it got every single test right. It even found some scoring mistakes i had not noticed when scoring manually !

I used this to get a peek at scores:

gnugo --chinese-rules --level 10 --score aftermath -l game.sgf

Getting dead stones is easy:
convert sgf to gtp first, add a final_status_list dead command and run:

gnugo --chinese-rules --level 10 --mode gtp < file.gtp

In the training pipeling he used:

gnugo --chinese-rules --capture-all-dead --score aftermath -l game.sgf --outfile final.sgf

To play the game to the end. This pretty much gives the board ownermap.

Ok, i tried a quick and dirty proof-of-concept hacking Pachi into an ogs estimator to see if that would help. It's in ogs_estimator_v1:

git clone https://github.com/lemonsqueeze/pachi
git checkout ogs_estimator_v1
make

The resulting 'estimator' binary uses same input/output format as ogs score estimator.

If i understand correctly there's no komi or handicap information here so returned score is not the actual game score. I guess the server is mostly interested in stones status and computes the score on its own later on.

Usage: estimator [-n simulations] [-d debug_level] file.game

Notes

• Default number of mc simulations is 1000 but might be more reliable with more.

• Can run with -d 3 to have Pachi-style boards printed on stderr.

• Pachi playouts handle most sekis and short-of-liberties-but-safe stones, so by itself that would fix a number of scoring issues compared to random playouts.

• Most of the code compiled is not used, this is just a quick and dirty hack on top of current Pachi. Only uses Pachi playouts actually.

• Running single-threaded atm.

Safe to score
I added a 'Safe to score' field in the output which will be either

• Safe to score: 1 if game looks ok to score, or something like
• Safe to score: 0 (unclear groups) if it's not (msg describes the reason)
  This is roughly the logic that Pachi uses to decide if passing and going to scoring is safe or not.

Scoring a Safe to score: 0 game is almost certainly meaningless, so server could use it in chinese-rules games to ask players to resume play and clarify the situation after showing current stones status. I think this should solve the issue for bot games as long as there's one human player involved. (bot-bot games may have both players decide to pass again endlessly but i guess these are rare cases. can be flagged for moderator attention or something).

Results on score estimator test suite
t-ogs/results.

All bad pachi scores are flagged not safe to score,
and the ones that are not flagged are good (not always the case, but here yes).

To make the score estimator more accurate, would it be plausible to consider training a fast and small policy network based on online-go game database to suggest "plausible" moves rather than completely random ones. The idea would not to select the "best" moves but just some indication of moves that may get played in practice.

A sufficiently small network may be able to concentrate the search space without too terrible computational overhead - potentially also dampened as the number of playouts could be reduced.

I'm basically mostly asking if there are reasons why this idea would be a non-starter or if it could be worth pursuing.

In one game [1], ogs score estimator made 11 points of Black territory neutral points.

Could you please confirm there's a bug and fix it when you have time.

1: https://online-go.com/game/8075913