Game moves statistics, any program for that ?

[RBerenguel]

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]

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 :

...
...
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: Select all

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: Select all

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]

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 :

...
...
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: Select all

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: Select all

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]

...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

"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: Select all

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]

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

[oca]

Yes... that's true... that's just that I last touched C at school 20 years ago... and I would like to concentrate on go, not on learning C (again)...

All I need (at least in a first time) is a function that can take a move, a pattern and a game and see if the pattern apply to the move...
so I think doing that in javascript will be faster for me then learning C...

[RBerenguel]

Yes... that's true... that's just that I last touched C at school 20 years ago... and I would like to concentrate on go, not on learning C (again)...

All I need (at least in a first time) is a function that can take a move, a pattern and a game and see if the pattern apply to the move...
so I think doing that in javascript will be faster for me then learning C...

Well, no. Because sgfinfo (from sgfutils) already does this: there's no need to rewrite the pattern-matching. But well, go on. I also prefer tinkering javascript than C (I just commented whole sections of what I have called sgfrender.c for sgfutils and well, C... I also have a toy SGF parser in JS and some other pieces round here, but I eventually rewrote it in go because I wanted to explore +500 games and use a database and I'm more proficient with go than with node) so I'd be happy to play with it when it's a little more "code dense."

[SmoothOper]

Yes... that's true... that's just that I last touched C at school 20 years ago... and I would like to concentrate on go, not on learning C (again)...

All I need (at least in a first time) is a function that can take a move, a pattern and a game and see if the pattern apply to the move...
so I think doing that in javascript will be faster for me then learning C...

That's how these things always get started. I would chime in and say. I am charged with maintainance hundreds of pages of classisic asp, vb+HTML+JavaScript and thousands of lines of vb.net thinking to myself if they had only had enough spine to write something strongly typed this would be so much easier to maintain and extend. Of course all the people who made these decisions jumped ship.

[oca]

That's how these things always get started. I would chime in and say. I am charged with maintainance hundreds of pages of classisic asp, vb+HTML+JavaScript and thousands of lines of vb.net thinking to myself if they had only had enough spine to write something strongly typed this would be so much easier to maintain and extend. Of course all the people who made these decisions jumped ship.

I understand your point, and quiet agree... but I don't expect to have a large code base... if so I may have choose Haskell or Java + OSGi. But for that "small" project, I think node.js is just fine.

Like in go, we sometimes need a solid connection, and sometimes a faster one...

[oca]

That starts to be funny ...
very first results (still a bit wrong I think...)

Code: Select all

Plugin : plugin_count_moves.js
Plugin : plugin_moves.js
----------------------------------------
Found 1 games in file 'sgf/handicap.sgf'
----------------------------------------
PLUGIN : COUNT MOVES

294 moves
----------------------------------------
PLUGIN : MOVE STATISTICS

                  black   white
                  -----   -----
           Nobi :    88      75
         Kosumi :    13      20
           Hane :    29      36
     Ikken tobi :    52      39
     Niken tobi :    17      16
        Kogeima :    11       6
         Ogeima :     2       4
    Daidaigeima :     3       7
    Bamboo join :     5       4
      Cross cut :     1       0
          Tsuke :     7       9
   Shoulder hit :    12      24
            Cut :     7      12

=============================================================
Not identified :
Black : 0

White : 3
MOVE : 1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 
  +--------------------------------------+
0 |. . . . . . . . . . . . . . . . . . . |
1 |. . . . . . . . . . . . . . . . . . . |
2 |. . . . . . . . . . . . . . . . . . . |
3 |. . . X . . . . . X . . . . . X . . . |
4 |. . . . . . . . . . . . . . . . . . . |
5 |. . . . . . . . . . . . . . . .(O). . |
6 |. . . . . . . . . . . . . . . . . . . |
7 |. . . . . . . . . . . . . . . . . . . |
8 |. . . . . . . . . . . . . . . . . . . |
9 |. . . X . . . . . X . . . . . X . . . |
0 |. . . . . . . . . . . . . . . . . . . |
1 |. . . . . . . . . . . . . . . . . . . |
2 |. . . . . . . . . . . . . . . . . . . |
3 |. . . . . . . . . . . . . . . . . . . |
4 |. . . . . . . . . . . . . . . . . . . |
5 |. . . X . . . . . X . . . . . X . . . |
6 |. . . . . . . . . . . . . . . . . . . |
7 |. . . . . . . . . . . . . . . . . . . |
8 |. . . . . . . . . . . . . . . . . . . |
  +--------------------------------------+

MOVE : 19
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 
  +--------------------------------------+
0 |. . . . . . . . . . . . . . . . . . . |
1 |. . . . . . . . . . . . . . . . . . . |
2 |. . . . . . . . . . . . . . . . . . . |
3 |. . . X . . . . . X . . . X . X . . . |
4 |. . . . . . . . . . . . . . . . X . . |
5 |. . . . . . . . . . . . . . X O O X . |
6 |. . . . . . . . . . . . . . O . . . . |
7 |. . . . . . . . . . . . . . O X X X . |
8 |. . . . . . . . . . . . . . . O O O . |
9 |. . . X . . . . . X . . . . . X X O . |
0 |. . . . . . . . . . . . . . . . . O . |
1 |. . . . . . . . . . . . . . . . . . . |
2 |. . . . . . . . . . . . . . . . . . . |
3 |. .(O). . . . . . . . . . . . . X . . |
4 |. . . . . . . . . . . . . . . . . . . |
5 |. . . X . . . . . X . . . . . X . . . |
6 |. . . . . . . . . . . . . . . . . . . |
7 |. . . . . . . . . . . . . . . . . . . |
8 |. . . . . . . . . . . . . . . . . . . |
  +--------------------------------------+

MOVE : 57
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 
  +--------------------------------------+
0 |. . . . . . . . . . . . . . . . . . . |
1 |. . . . . . . . . . . . . . . . . . . |
2 |. . X O O . . O . X .(O). . . . . . . |
3 |. . X X . . . . . X . . . X . X . . . |
4 |. . . . . . . . . . . . . . . . X . . |
5 |. . . . . . . . . . . . . . X O O X . |
6 |. . X . . . . . . . . . . . O . . . . |
7 |. . . . . . . . . . . . . . O X X X . |
8 |. . . . . . . . . . . . . . . O O O . |
9 |. . . X . . . . . X . . . . . X X O . |
0 |. . . . . . . . . . . . . . . . . O . |
1 |. . . . . . . . . . . . . . . . . . . |
2 |. O . . . . . . . . . . . . . . . . . |
3 |. . O . X . . . . . . . . . . . X . . |
4 |. O X . . . . O . O . . . . . . . . . |
5 |. . . X X . . X O X . . . . X X X . . |
6 |. . O O X . . X O X . . . O X O O . . |
7 |. . . . X . . X O . . . O . O X X . . |
8 |. . . . . . . . . . . . . O . . . . . |
  +--------------------------------------+

----------------------------------------

hoshi, komoku, sanssan, kakari, etc...  still to be implemented...

Moves are detected using simple pattern String... so that we can express them wihtout knowing that much of coding... the pattern is rotated and mirrored by the program to get all possibilities.

Code: Select all

Ogeima :
  pattern = [
     "...X",
     "1..."
   ]


Shoulder hit :
  pattern = [
    ".O",
    "1."
  ]

where "1" is the position of the last played stone, "X" is a stone of same color then "1" (which can be black or white, not as in go diagram...) and "O" is a stone of other color then "1".
"." is a free intersection.

I still have to add things like "?" for "anything" and "#" for any stone color.

Here are the patterns for now, as they appear in the code (should be readable I hope ...).

var patterns = [
{
name : "Nobi", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = ["X1"];
return p.isPattern(pattern, stone, game) ;
}
},{
name : "Kosumi", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
".1",
"X."];
return p.isPattern(pattern, stone, game);
}
},{
name : "Hane", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
".X",
"1O"];
return p.isPattern(pattern, stone,game);
}
},{
name : "Ikken tobi", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = ["X.1"];
return p.isPattern(pattern, stone,game);
}
},{
name : "Niken tobi", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = ["X..1"];
return p.isPattern(pattern, stone,game);
}
},{
name : "Kogeima", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
"..X",
"1.."];
return p.isPattern(pattern,stone,game);
}
},{
name : "Ogeima", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
"...X",
"1..."];
return p.isPattern(pattern,stone,game);
}
},{
name : "Daidaigeima", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
"....X",
"1...."];
return p.isPattern(pattern,stone,game);
}
},{
name : "Bamboo join", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
"X.X",
"1.X"];
return p.isPattern(pattern, stone, game );
}
},{
name : "Cross cut", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
"....",
".OX.",
".1O.",
"...."];
return p.isPattern(pattern, stone, game );
}
},{
name : "Tsuke", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
".O.",
".1."];
return p.isPattern(pattern, stone, game );
}
},{
name : "Shoulder hit", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
".O",
"1."];
return p.isPattern(pattern, stone, game );
}
},{
name : "Cut", black : 0, white : 0,
is : function(move, stone, st_group, game, st_groups) {
var pattern = [
"OX",
"1O"];
return p.isPattern(pattern, stone, game );
}
}

Still a bit of cleaning and I will post a first beta version for whose who may want to play with it...

[quantumf]

...thousands of lines of vb.net...if they had only had...strongly typed this...

Code: Select all

' Enable VB.Net strong typing 
Option Strict On

They didn't do this, then?

[SmoothOper]

...thousands of lines of vb.net...if they had only had...strongly typed this...

Code: Select all

' Enable VB.Net strong typing 
Option Strict On

They didn't do this, then?

What's next is someone going to point out how you can actually write object oriented VB. Sigh

If dumb response then
With sarcasm

let's all write object oriented strongly typed code in a language that wasn't designed for it, boy that'll be easy...

End with sarcasm

[quantumf]

As VB.NET is equivalent to c# in essentially every way, it's clearly an object oriented language by design. It has the flavour of basic, with it's terms and symbols, and in a concession to VB6 programmers, it allows a procedural, non-OO form. I have developed multiple large (object oriented) systems with VB.NET, and find it a perfectly comfortable OO language

[SmoothOper]

As VB.NET is equivalent to c# in essentially every way, it's clearly an object oriented language by design. It has the flavour of basic, with it's terms and symbols, and in a concession to VB6 programmers, it allows a procedural, non-OO form. I have developed multiple large (object oriented) systems with VB.NET, and find it a perfectly comfortable OO language

On error resume next

On erro goto....

Clearly not OO or easy to manage in large projects. I find these constructs especially discomforting, and especially error prone, for anything but the simplest of code. Not to mention, that sooner or later in large projects you have to do an N^2 or N*log(n) operation like sorts or searches, then it pretty much crawls to a halt. Furthermore, VB programmers like many single language programmers fail to recognize the relative disadvantages of their language, and are generally thin skinned and uncool about it. After all if it were object oriented then they shouldn't feel that it is too difficult to use another language in the first place, but again this is not the case.

[RBerenguel]

As VB.NET is equivalent to c# in essentially every way, it's clearly an object oriented language by design. It has the flavour of basic, with it's terms and symbols, and in a concession to VB6 programmers, it allows a procedural, non-OO form. I have developed multiple large (object oriented) systems with VB.NET, and find it a perfectly comfortable OO language

On error resume next

On erro goto....

Clearly not OO or easy to manage in large projects. I find these constructs especially discomforting, and especially error prone, for anything but the simplest of code. Not to mention, that sooner or later in large projects you have to do an N^2 or N*log(n) operation like sorts or searches, then it pretty much crawls to a halt. Furthermore, VB programmers like many single language programmers fail to recognize the relative disadvantages of their language, and are generally thin skinned and uncool about it. After all if it were object oriented then they shouldn't feel that it is too difficult to use another language in the first place, but again this is not the case.

Like object-orientedness was the panacea to solve everything. Lisp programmers are pretty much happy without ever resorting to CLOS. Go has interfaces and structs and it works pretty well. The example above? This is error handling. Error handling is good, and there's no need to add object-mumbo-jumbo to do it. Quite likely the problem this code had was orthogonality, or quite more likely, a bad maintainer.