Game moves statistics, any program for that ?

oca · #1

Hi, maybe it's a weird question but, did anyone know if it exists a programm that will be able to produce some kind of statistics on a given sgf file ?

for instance, I would give it "the_game_i_did_last_night_that_was_so_funny_even_if_i_loose.sgf" and it will tell me something like that :

black :
- nobi : 20 (xx % of the moves)
- kosumi : 40 (xx % of the moves)
- tobi : 30 (xx % of the moves)
- Niken-tobi : 5 (xx % of the moves)
- keima : 50 (xx % of the moves)
- Ogeima : ...
...

white:
- nobi : 37 (xx % of the moves)
- tobi : 12 (xx % of the moves)
- Niken-tobi :
- keima : 64 (xx % of the moves)
...

or even better with analysis of "things" like : tenuki, tsuke, peep, osae( maybe a bit difficult with one as I understand it more like beeing an intent not a move... or is it a move :scratch:

)

I know that only statistics (or statistics only) isn't enougth to judge a game, but I will still like that kind of tools.

[edit]
Finally I did try to write one... first try here : viewtopic.php?p=165330#p165330
[/edit]

EdLee · #2

Hi oca, not that I know of, but maybe it's an interesting idea to show broken shapes or other bad shapes.
(Of course, we sill need further analysis to determine if the shape is actually good or bad, locally and globally.)

For example, each of (a) and (b) below shows a local broken shape for W.
(a): Locally, pro consensus is the result is even. Needs global context.
(b): Locally, bad for W. Still needs global context.

Click Here To Show Diagram Code: [go]$$ $$ | . . . . . . . . . ? . . . . . . . . . | $$ | . . . . a . . . . ? . . . . b . . . . | $$ | . . . . . . . . . ? . . . . . . . . . | $$ | . . O . . . . . . ? . . . . . . . . . | $$ | . . . X . . . . . ? . . X X X X X . . | $$ | . . O X . . . . . ? . . . O X O . . . | $$ | . . O # # W . X . ? . . . O X O . . . | $$ | . . O W # . . . . ? . . . . X . . . . | $$ | . . . . . . . . . ? . . . . . . . . . | $$ -----------------------------------------[/go]

RBerenguel · #3

Pachi kind of, can. But hard to "convince it" to do it

EdLee · #4

Hi oca, on a related note, your original idea of the stats of various shapes in a game
is kind of like -- to borrow from something John recently wrote -- taking a Van Gogh painting
and getting the stats of the number of colors, the number of strokes, the number of strokes
sorted by varying degrees, the heights and widths and thickness of the strokes, etc.

Apparently, the kind of information above can be useful for software to analyze
potential forgeries -- comparing a questionable Van Gogh's stats to the real master's stats.

As far as trying to appreciate a masterpiece, the stats are not very interesting to me.

Attachment:

x.jpg [ 126.06 KiB | Viewed 10741 times ]

RBerenguel · #5

EdLee wrote:

Hi oca, on a related note, your original idea of the stats of various shapes in a game
is kind of like -- to borrow from something John recently wrote -- taking a Van Gogh painting
and getting the stats of the number of colors, the number of strokes, the number of strokes
sorted by varying degrees, the heights and widths and thickness of the strokes, etc.

Apparently, the kind of information above can be useful for software to analyze
potential forgeries -- comparing a questionable Van Gogh's stats to the real master's stats.

As far as trying to appreciate a masterpiece painting, the stats are not very interesting to me.

Attachment:

x.jpg

On a related note, fractal dimension of Jackson Pollock's paintings was used to detect a forgery (read in a SciAm issue I have at home, from around 2000 I guess)

EdLee · #6

RBerenguel wrote:

On a related note, fractal dimension of Jackson Pollock's paintings was used to detect a forgery (read in a SciAm issue I have at home, from around 2000 I guess)

Nice!

schawipp · #7

EdLee wrote:

Hi oca, on a related note, your original idea of the stats of various shapes in a game
is kind of like -- to borrow from something John recently wrote -- taking a Van Gogh painting
and getting the stats of the number of colors, the number of strokes, the number of strokes
sorted by varying degrees, the heights and widths and thickness of the strokes, etc.

Actually, there is an artist who is specialized on these kind of things: http://innovajo.blogspot.com/2011/09/ocd-artist-ursus-wehrli-16-photos.html ;-)

John Fairbairn · #8

A long time ago, probably in days of rec.games.go, I posted ideas about a program that would detect the type of move just made and then offer a list of proverbs or even articles that apply to that type of move. It was meant for humans but had obvious applications in computer play, too.

I implemented a version that worked for a handful of move types such as monkey jumps, but it was just too much work to cover the whole gamut. But I still think it's doable and useful.

RBerenguel · #9

In a very simple-case scenario, this is doable with some shell scripting, patience and using sgfutils. No need to reinvent the wheel in this case, just build the car on top of some neat wheels. I.e. quick example

create an SGF file with a stone at hoshi and a keima approach. Name it hoshi-keima-kakari.sgf (for instance)
create an SGF file with a stone at hoshi and a 1pt jump approach. Name it hoshi-1-jump-kakari.sgf (for instance)
create an SGF file with a stone at hoshi and a ogeima approach. Name it hoshi-ogeima-kakari.sgf (for instance)
[...]

[Note: IIRC, for sgfutils to recognise proper kakaris with otherwise empty corners, i.e. proper kakari and not just an approach to a developed corner later, we'd also need to add "empty" for the non-related areas in the quadrant where the hoshi is]

Loop through all these files using sgfinfo -pat={patternfile} -alltra -trunc50 file_to_analise.sgf to check kakaris only for the first 50 moves or so, then output the relevant info. So, if sgfinfo matches hoshi-keima-kakari.sgf, return in the data "Played a keima kakari to a hoshi stone."

Actually this could be made much more interesting by (afterwards) automatically looking up joseki choices in kogo's joseki dictionary.

----

This is vaguely close to a minor project I have to study 9x9 games in more detail, using sgfutils and my relatively large collection of (relatively) high level amateur play & pro play. Specifically I want to check common shapes and openings used, as well as relatively specific tactics that come in play. So far it's essentially an idea because I'm not sure how to handle part of it (specifically checking middle game situations is very hard unless using pachi's pattern-checking & making systems, and I'm not sure if it handles 9x9 well)

oca · **#10**

Marcel Grünauer wrote:

Getting back on topic, I'm also thinking about such a program. The difficulty might be to assign a type to a move (is it nobi, nozoki, oki etc.); maybe some moves can have several types.

Let's say we have this sequence, where :b5:

is both a nobi from :b1:

and a from keima :b3:

...

I would say the program should show this :

Code:

black : 
   - hoshi : 1
   - Ogeima : 1 
   - nobi : 1  
   - keima : 1 

white :
  - is there anybody here ? ;) 

Marcel Grünauer wrote:

It would then also be interesting to look at sequences (e.g., "empty corner star point > keima kakari > two-space high pincer > keima kake > nobi" etc.) and use these sequences as the basis for a new kind of positional search by asking "which games contain these sequences?", thereby identifying kinds of fights etc.

Yes, that would be fine too to indentify kakari, shimari and so on...

oca · **#11**

EdLee wrote:

Hi oca, not that I know of, but maybe it's an interesting idea to show broken shapes or other bad shapes.
(Of course, we sill need further analysis to determine if the shape is actually good or bad, locally and globally.)

For example, each of (a) and (b) below shows a local broken shape for W.
(a): Locally, pro consensus is the result is even. Needs global context.
(b): Locally, bad for W. Still needs global context.

Click Here To Show Diagram Code: [go]$$ $$ | . . . . . . . . . ? . . . . . . . . . | $$ | . . . . a . . . . ? . . . . b . . . . | $$ | . . . . . . . . . ? . . . . . . . . . | $$ | . . O . . . . . . ? . . . . . . . . . | $$ | . . . X . . . . . ? . . X X X X X . . | $$ | . . O X . . . . . ? . . . O X O . . . | $$ | . . O # # W . X . ? . . . O X O . . . | $$ | . . O W # . . . . ? . . . . X . . . . | $$ | . . . . . . . . . ? . . . . . . . . . | $$ -----------------------------------------[/go]

detecting broken shape would be so cool, but seems very difficult... maybe we can just spot "obvious one", but then we need a definition for what "an obvious broken shape" is... :scratch:

anyway... what would be cool is that the program can have some kind of "plugin", so that we can plug modules...
- a module for detecting simple moves,
- a module for broken shape
- a module for known bad shapes (which can be good sometimes... headache again...)
etc...
[edit]
- a module to count sacrificed stones, once again very easy to do :-?

....
- a module to mesure aji...

ok stop here with impossible things, let's focus on doable one
[/edit]

Bonobo · **#12**

schawipp wrote:

[..] there is an artist who is specialized on these kind of things: http://innovajo.blogspot.com/2011/09/ocd-artist-ursus-wehrli-16-photos.html ;-)

Thanks for that great “OCD art” link, muchly appreciated (and widely shared) :-D

Greetz, Tom

hyperpape · **#13**

I'm not sure how I feel about the fact that the twigs are not straight up and down in the seventh work.

gowan · **#14**

Couldn't Kombilo be used in some cases? Say look for keima, ikken tobi, ogeima, etc. It might work if you cut down the empty space around the shape that is the search key.

daal · **#15**

This isn't exactly what you're looking for, but your question reminded me of the go style estimator, which did offer some analysis of the types of moves a player tends to make. Unfortunately, it seems no longer to be working.

RBerenguel · **#16**

daal wrote:

This isn't exactly what you're looking for, but your question reminded me of the go style estimator, which did offer some analysis of the types of moves a player tends to make. Unfortunately, it seems no longer to be working.

The go style estimator used pachi's patternmatching abilities, this is where I got the idea and after checking the source found all the little bits and pieces used (or "enough" at least)

oca · **#17**

Finally I decided to try to build my own program for that... Not sure I can do it all, but
at leat I will learn something about go terms, and trying to detect broken shap in a program should at least help me to have that concern in mind when playing real game which is allready a good point...

So.., where to start ?

Something that is easy to write,"script" oriented.
Something that is modular, so that I can build small steps, one after the other.
Something where I can reuse some work like the sgf parser for instance.

=> Choice : javascript with node.js

SGF parser :

cloudbrows in topic 'For developers: Easy ways to render nice stone graphics' wrote:

...
...
Collaborations can be great, but what I'm focused on more now is trying to make smaller, reusable components. For instance, there's no reason that developers need to keep reinventing a parser for SGF files, which is why I made one available on NPM: https://www.npmjs.org/package/smartgame. Hopefully it's documented well enough that the next person to happen on it will find it usable, rather than making their own, anyway, like... well, like I did. (There's already a parser here. https://www.npmjs.org/package/sgf To be fair, it's almost totally undocumented.)

I want to work on making other components easy for others to use that are a little more complicated.

Super nice parser, I will use this one !

Rule engine (as SGF doesn't tells you which stone you must remove...)
-> ???, I will use a quick and dirty one I used to do...

General idea :
A main routine will walk into an sgf file, and then call each plugins for each of the moves.
if games contains variations, only the first path is taken.

Plugin should be easy to write... here is an example of a plugin that just count the moves :

Code:

FILE : plugin_count_moves.js

var nb = 0;

exports.getTitle = function() {
   return "Count Moves";
};

exports.onMove = function(move, stone, st_group, game, st_groups) {
   nb ++;
};

exports.onFinish = function() {
   console.log (nb+" moves");
};

which gives the following results :

Code:

D:\dev\js\movestat>node main.js  handicap.sgf
Plugin found: plugin_count_moves.js
Plugin ignored: _plugin_moves.js
----------------------------------------
Found 1 games in file 'handicap.sgf'
----------------------------------------
PLUGIN : COUNT MOVES

294 moves
----------------------------------------

Next step : let's start small, and try to count the solid extensions, "nobi"
and allready a lot of cleaning in the code

...

[edit]main code is still to buggy to post, but I definitly will share it soon if someone is interested[/edit]

RBerenguel · **#18**

oca wrote:

Finally I decided to try to build my own program for that... Not sure I can do it all, but
at leat I will learn something about go terms, and trying to detect broken shap in a program should at least help me to have that concern in mind when playing real game which is allready a good point...

So.., where to start ?

Something that is easy to write,"script" oriented.
Something that is modular, so that I can build small steps, one after the other.
Something where I can reuse some work like the sgf parser for instance.

=> Choice : javascript with node.js

SGF parser :

cloudbrows in topic 'For developers: Easy ways to render nice stone graphics' wrote:

...
...
Collaborations can be great, but what I'm focused on more now is trying to make smaller, reusable components. For instance, there's no reason that developers need to keep reinventing a parser for SGF files, which is why I made one available on NPM: https://www.npmjs.org/package/smartgame. Hopefully it's documented well enough that the next person to happen on it will find it usable, rather than making their own, anyway, like... well, like I did. (There's already a parser here. https://www.npmjs.org/package/sgf To be fair, it's almost totally undocumented.)

I want to work on making other components easy for others to use that are a little more complicated.

Super nice parser, I will use this one !

Rule engine (as SGF doesn't tells you which stone you must remove...)
-> ???, I will use a quick and dirty one I used to do...

General idea :
A main routine will walk into an sgf file, and then call each plugins for each of the moves.
if games contains variations, only the first path is taken.

Plugin should be easy to write... here is an example of a plugin that just count the moves :

Code:

FILE : plugin_count_moves.js

var nb = 0;

exports.getTitle = function() {
   return "Count Moves";
};

exports.onMove = function(move, stone, st_group, game, st_groups) {
   nb ++;
};

exports.onFinish = function() {
   console.log (nb+" moves");
};

which gives the following results :

Code:

D:\dev\js\movestat>node main.js  handicap.sgf
Plugin found: plugin_count_moves.js
Plugin ignored: _plugin_moves.js
----------------------------------------
Found 1 games in file 'handicap.sgf'
----------------------------------------
PLUGIN : COUNT MOVES

294 moves
----------------------------------------

Next step : let's start small, and try to count the solid extensions, "nobi"
and allready a lot of cleaning in the code

...

[edit]main code is still to buggy to post, but I definitly will share it soon if someone is interested[/edit]

I'm all for reinventing the wheel as often as we can (I wrote a post about it that was a hit in Hacker News a few years ago,) but in this particular case, why not use sgfutils and/or pachi's codebases, which have already all pieces needed (and much more)?

oca · **#19**

RBerenguel wrote:

...I'm all for reinventing the wheel as often as we can (I wrote a post about it that was a hit in Hacker News a few years ago,) but in this particular case, why not use sgfutils and/or pachi's codebases, which have already all pieces needed (and much more)?

Well..., I did a quick look on them but, without going a code level, I don't know how to use them to do what I want...
and unfortunatlly, C langage is now just

Gotye wrote:

"somebody that I used to know" tu... tu... tu... tu... tu tu tu tu tu... pom... pom pom...

Let's say I want to detect the solid extension... that will look something like that :

Code:

var TITLE = "Move stats";
var nobi_black = 0;
var nobi_white = 0;

exports.getTitle = function() {
   return TITLE;
};
   
exports.onMove = function(move, stone, st_group, game, st_groups) {
   if (stone === null) return; // "pass" move lead to null stone. just ignore
   var isNobi = _isNobi(stone, st_group);
   if (isNobi) {
      if (stone.c == 1) {
         nobi_black ++;
      } else {
         nobi_white ++;
      }
   }
};

exports.onFinish = function() {
   console.log("Black");
   console.log("  Nobi : "+nobi_black);
   console.log("White");
   console.log("  Nobi : "+nobi_white);
};

function _isNobi(stone,st_group) {
   // first try :
   // if the played stones belong to a group 
   // of 2 or more stones, then this is a nobi shape... (is it ? ;) )

   return (st_group.stones.length>1);
}

I don't know how to do something like that with patchi and/or sgfutil without compiling C code ...

RBerenguel · **#20**

Well, compiling C code is not the end of the world. There are compilers for Windows...

Game moves statistics, any program for that ?

Who is online