Day 71: Fuseki and Statistics.

Something that I red on Senseis:

Occurrence in Professional play

The following are statistics for how often the given enclosure was found in professional games in an otherwise empty 10x10 corner. The database used was GoGoD2009 winter edition (with games up to december 2009). Results have been rounded to two significant decimal places:

Enclosures with a 3-4 stone:

• 5-3 Small knight's move: 19000 times
• 5-4 One point jump: 6700 times
• 6-3 Large knight's move: 4300 times
• 6-4 Two point jump: 330 times
• 3-7 Two point jump other side: 11 times

Enclosures with a 4-4 stone:

• 3-6 Small knight's move: 3100 times
• 3-7 Large knight's move: 2900 times
• 4-6 One point jump: 730 times
• 4-7 Two point jump: 380 times
• 3-8 Very large knight's move: 310 times
• 3-5 Kosumi: 24 times

Enclosures with a 3-3 stone:

• 4-6 Large knight's move: 290 times
• 4-5 Small knight's move: 150 times
• 3-6 Two point jump: 29 times
• 3-5 One point jump: 7 times

Enclosures with a 3-5 stone (excluding those already covered):

• 5-4 High small knight's move: 320 times
• 6-4 Large knight's move: 150 times
• 5-5 One point jump up: 130 times
• 6-3 Two by three jump: 53 times
• 5-3 Elephant's jump: 7 times

Enclosures with a 4-5 stone (excluding those already covered):

• 4-5 3-9 Very large knight's move: 50 times
• 4-5 3-8 Large knight's move: 9 times

Maybe I can use this in the near future...

Day 70: Some things about fuseki V -making fuseki a little better-

Well, just a theory for fuseki:

For example: If I play 4-4 point, playing 3-4 point is useless (at least at fuseki stage, don't count any joseki, etc.), so in those cases the score for 3-4 should be lowered. 3-3 point is less useless, but should lower the points of being played.

Now, this will make me change some things in my fuseki code. A lot more if's are coming!.

Day 70: Implementing shimari and kakari

This is the way I programmed what I showed in the last posts about shimari and kakari:

public int keimaShimariKakari(int move,Board board,int color){ int n=board.getBoardSize(); boolean fivethree=false; int points=0; ArrayList<integer> positions=new ArrayList<>(); ArrayList<integer> komoku=new ArrayList<>(); //103-64 in 19x19 positions.add((n+1)*5+3); komoku.add((n+1)*3+4); //65-83 positions.add((n+1)*3+5); komoku.add((n+1)*4+3); //117-76 positions.add((n+1)*6-4); komoku.add((n+1)*4-4); //74-97 positions.add((n+1)*4-6); komoku.add((n+1)*5-3); for(int i=0;i<positions.size();i++){ fivethree=oneDependsOnAnother(move,positions.get(i),komoku.get(i),board); if(fivethree==true){ if(board.getMove(move)==color){ points=WeightValues.keimashimari; }else{ points=WeightValues.keimakakari; } break; } } return points; }

What is oneDependsOnAnother? Well... it is to see if the move is in a position and to make something it depends on another move. For example, to make this shimari you need first a komoku. If there is that komoku move and the move is in the 3-5 then return true. Let's see this in code:

public boolean oneDependsOnAnother(int move,int moveEvaluated, int moveDepend, Board board){
        boolean isGood=false;
        if(move==moveEvaluated && board.getMove(moveDepend)!=0){
            isGood=true;
        }
        return isGood;
    }

I can do the same now with other combinations, methods should be similar.

Day 69: Errata in 3-5 positions.

Ok, This is bad. Positions for the "lower part of the board" in 19x19 (103,65,117,74 are good) are:

303: (n+1)*15+3
345: (n+1)*17+5
317: (n+1)*16-3
335: (n+1)*17-5

Next, CODE!

Day 68: Some things about fuseki V: Shimari

Back to fuseki, let's talk about shimari. The most common shimari is the keima for the 3-4 point (Point 5-3). Again, this is about 8 formulas:

In 19x19:

103=(n+1)*5+3
65=(n+1)*3+5
117=(n+1)*6-3
74=(n+1)*4-6

283=(n+1)*(n-5)+3
324=(n+1)*(n-3)+4
297=(n+1)*(n-4)-3
335=(n+1)*(n-2)-5


I think that this will be valid only for boards... let's say... bigger than 13x13.

So, if a stone is played in a komoku, maybe a shimari is a good move.

Day 66: L&D II

Two things that can be done to make a little better the L&D part:

Right now if a group is in atari, the program gives a lot of points to the move that takes the group out of the atari. Well, here is what I was thinking: "Is the same if the group have 1 stone or 20?" In some cases could be, but in most cases the group with more stones is worth more (well this can lead the program to lose all the ladders, but, this is still the beginning.

The other thing is, to make something similar about killing stones. If the group of the other color is in atari, if adding a stone of that color saves the group the program should give lots of points to the move that kills the group.

for both cases it should be: x+1*stones (x is the number of points given to "kill" or "save".

Day 65: Another video

As promised, here is the video of how Evil Tesuji works now. As you see it plays in the corners and escapes from atari.




Next: Some changes to L&D.

Day 65: Bugfixing and a promise.

Well, fixed the bug I saw in the last post. When I wake up, I will upload a video with the actual state of the program!

Now, time to sleep! cu!

Day 65: L&D I

Let's begin with the most basic thing about Life and Death: Prevention of an atari.

The first approach that I see (I will correct it as long as I think of it) is:

Look at the positions that limit the stone.
If some of them have a stone of the same color, see how many liberties have that group.
If the group have 1 liberty, add that stone and count the liberties again.
If still have 1 liberty quit points, else add points.

This is a very bad approach, but I can evolve from this I think (maybe I am wrong, but... let's try).

NOTE: Ok... while trying this, a wild bug appeared! A suicidal stone was played. Do not know if this happened because the new code ruins all or if there was always that bug.

Day 64: Deadlines & Problems

Sometimes we need deadlines to present something, and I put 15D (december 15th.) as the day that Evil Tesuji will start playing in KGS. I don't think that the program will make a lot and is more to test it. There are some volunteers to test Evil Tesuji from 30 kyu to 5 kyu (I will contact a 4 dan to).
Is obvious that the program will be crushed in every single game, but it can be good as a starting point.

In other notices, yesterday I was trying to test Evil Tesuji against GnuGo, just for fun and to test if the program can end a game (doesn't matter the result). It is really hard. gogui-twogtp didn't work, cgos neither. I will keep working on that.

Day 64: Some things about Fuseki IV -Komoku-

With the same spirit as the last posts, let´s focus on komoku points (3-4). The difference can be that there are 8 points. This will make me create more formulas, but, it's allright.

In the 9x9 board, komoku are in the points: 34, 36, 43, 47, 74, 76, 63 and 67.

For point 34: (n+1)*3+4.

For point 36: (n+1)*4-4.

For point 43: (n+1)*4+3.

For point 47: (n+1)*5-3.

For point 74: (n+1)*(n-2)+4.

For point 76: (n+1)*(n-1)-4.

For point 63: (n+1)*(n-3)+3.

For point 67: (n+1)*(n-2)-3.

This works for every size.

Day 63: Little things

Moves that are not contemplated have a random weight (between 1 and 5) but, a little thing that I can do to make it a lot better is that if the move is in the first line it should quit 2 points and in second line should quit 1. Later if it is a matter of L&D I will add enough points so the program doesn't miss it.

Just to make this a little longer: GnuGo vs. GnuGo.

Day 63: Some fuseki things III: Hoshi

This is about playing hoshi at fuseki, of course, just talking about 4-4 point. The formulas should be similar to 3-3 point.

In 9x9 the points are: 44, 46, 64 and 66.

Let's see, for 44 the formula (n+1)*4+4 works.
For point 46 the formula is (n+1)*5-4.

For point 64: (n+1)*(n-3)+4= 10*6+4=64
For point 66: (n+1)*(n-2)-4= 10*7-4=66.

Thinking in a 19x19 board, positions are: 84, 96, 324 and 336.

(n+1)*4+4= 20*4+4=84

(n+1)*5-4=20*5-4=96

(n+1)*(n-3)+4= 20*16+4= 324

(n+1)*(n-2)-4 = 20*17 -4= 336

Like in the San San method let's create a isHoshi method:

public boolean isHoshi(int move,Board board){
        boolean isHoshi=false;
        int n=board.getBoardSize();
        if(move==(n+1)*4+4 || move==(n+1)*5-4 || move==(n+1)*(n-3)+4 || move==(n+1)*(n-2)-4){
            isHoshi=true;
        }
        return isHoshi;
    }

Day 63: Some fuseki things II -San San-

Forget what I posted yesterday about san san, that was all wrong, let's supose again (but according to the array) the 9x9 board:

00 01 02 03 04 05 06 07 08 09
10 11 12 13 14 15 16 17 18 19

20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39

40 41 42 43 44 45 46 47 48 49
50 51 52 53 54 55 56 57 58 59

60 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79

80 81 82 83 84 85 86 87 88 89
90 91 92 93 94 95 96 97 98 99
00 01 02 03 04 05 06 07 08 09 10

San San points are 33,37,73 and 77

I can say that point 33 can be reached by the formula (n+1)*3+3 (n is the size in this case 9)= 33.
Point 37 can be reached with formula (n+1)*4-3.

Point 73 can be reached with formula (n+1)*(n-2)+3= 10*7+3=73.
Point 77 can be reached with formula (n+1)*(n-1)-3= 10*8-3=77.

Now, let's see if this works for other sizes:

In a 6x6 board:

00 01 02 03 04 05 06
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31 32 33 34
35 36 37 38 39 40 41
42 43 44 45 46 47 48
49 50 51 52 53 54 55 56

San san points are: 24, 25, 31 and 32 (a square in the board).

(n+1)*3+3 = 7*3+3=24
(n+1)*4-3 = 7*4-3=25
(n+1)*(n-2)+3 = 7*4+3=31
(n+1)*(n-1)-3 = 7*5-3=32

In 19x19 San san points (yes, yo lazy to "draw" the board) are 63, 77, 343 and 357


(n+1)*3+3 = 20*3+3=63
(n+1)*4-3 = 20*4-3=77
(n+1)*(n-2)+3 = 20*17+3=343
(n+1)*(n-1)-3 = 20*18-3=357

Right now I think this will work.

So, I will make a method in a class "ShapeRecognizer" called sanSan.

public boolean sansan(int move,Board board){

        boolean isSanSan=false;

        Translator translator=new Translator();

        int n=board.getBoardSize();

        if(move==(n+1)*3+3 || move==(n+1)*4-3 || move==(n+1)*(n-2)+3 || move==(n+1)*(n-1)-3){

            isSanSan=true;

        }

        return isSanSan;

    }

I know is not the best way to do it, but, with time and complexity this will change.

Let's see the result:

Day 62: Horrible Notice

Just red that the person that thought me how to play go, Franklin Bassarsky died. I am really sad and don't know what to say, is just... a terrible notice. I really enjoyed his classes. Well... this is sad.

Day 62: Some Fuseki things

I just want to start giving points to moves, so let's start seeing where are some fuseki points.

Let's imagine a 9x9 board:

9x9 board = 11*10+1=111 positions

01 02 03 04 05 06 07 08 09 10
11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30
31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70
71 72 73 74 75 76 77 78 79 80
81 82 83 84 85 86 87 88 89 90
91 92 93 94 95 96 97 98 99 00
01 02 03 04 05 06 07 08 09 10 11

Borders are at 1,2,3,4,5,6,7,8,9,10,11,21,31,41,51,61,71,81,91,101,102,103,104,105,106,107,108,109,110,111

For San-San

So, our "san san points" (3-3) are at 34, 38, 74 and 78.

The point is that I need a generic way to calculate san san. 

How do I know that ar 34 I have a san san? 

(Note: n in this context is the size of the board, in this case 9).

point-3 = border. 
point-3*(n+1)=border
For 38:

point+3=border
point-3*(n+1)=border 

For 74: 

point-3 = border.
point+3*(n+1)=border

For 78


point+3 = border.
point+3*(n+1)=border

This will search for borders at 3 spaces: 

• For 34 will search for 31 and 4
• For 38 will search for 41 and 8
• For 74 will search for 71 and 104
• For 78 will search for 81 and 108

I think This works for every board size.

For Hoshi in fuseki

What you red, change 3 with 4.

Day 60: 1000 visits!

I like to thank you all for visiting this blog. It is a lot of work for me and your visit, comments and mails give me strength to continue.

I Hope this project grows.

Day 58: To the next step

First of all I want to thank you all that read, comment and send me mails, this gives me a lot of strength to continue with this hard project. Special thanks this time to Xavier and Lic. Sergio that made me see a way to make the code run faster and better.

Here is the way this will continue to start getting less randomization: all the valid moves that the engine have should have a score. There will be a method givePoints that will give points to the move. There I will call all the methods that will have te logic to assign the move some points. Let's say, all moves start with 0 points. To that I will sum a random number from 1 to 5. Then the program will sum and rest points according to the logic that I will give to the program.

Let's start with something simple, then I will make it more and more complex. The first thing I will implement to give points is if the move is in the first turns playing in the corners will give the move 15 points. Closing a Shimari 17 making a kakari 17 (I know in the future I will need to change those values, but let's see).

Day 58: Back ups

You know, I didn't made a lot of back ups, so the risk was that losing my pendrive with this development would cost me the project :). The last backup is really far from where I am now.

So, I just opened a Dropbox account to make a daily backup. Maybe in the future I will share some files.

By the way: how could this be day 58? I missed the count somewere.

Day 57: Thinking.

Just writing what I think, so maybe this will not be the final version of this:

I was thinking that when the machine has all the possible moves, next step should be assigning a score for all the moves

For example, I know that in the beggining some points are better than others, so those poins will have a better score, and the one with the highest (don't know if adding a random score) will be played.

Then I can do whatever I want to put those scores. 

Day 57: First video and log

As I promised, here is a video of how is the program working so far.

The program is SLOW, this is because I am logging a lot, it is running on an overcharged computer and is running from a pendrive. So, to save this I should:

1. Make less logging (just log the same info but writing less).
2. Sometimes I should run this from a computer that works well, it just plays random moves, it shouldn't take so long to choose a valid move.
3. Run it from a hard disk XD.

But, right now what bothers me is how to continue.

The log (10 moves... 206kb.), that is something impossible to keep.

Day 56: Thinking about eyes

Yesterday I think I solved the problems that I had and I promised a log, a video and those things. Maybe at night I will do it.

So, the first part of the problem is solved. The program plays "random go". It evaluates all the possible moves (legal ones) and choose one and plays it.

Second stage is making it "think" a little about what to play.

First thing that came out of my mind was "Computer should know about eyes", so first thing I did (what every programmer should do) is google about it.

First thing I found was this paper and then a lot of advices about what will happen to my eyes when I keep looking at the monitor.

Then I went to senseis and saw this article about eye definition.

I think that this will take some time of me :(, but NEVER SURRENDER!

Day 55: Eureka!

Finaly solved the problem, well, two problems. In suicide the data was persisting somehow, so, inexistent groups were being compared. The other was in how it searched for suicide.

Next: A little video with random moves and a log :).

Day 55: Errors in logic...

When I saw the error that I posted before, I just started to log all. Now I think I understand where this is happening: The tryToKill function: public int tryToKill(int color){ Ruleset ruleset=new Ruleset(); int killed=0; //return the number of killed stones ArrayList<integer> group=new ArrayList<>(); ArrayList<integer> liberties; boolean isDead; for(int i=0;i<this.getMainBoard().size();i++){ if(this.getMove(i)==color){ group=ruleset.getGroup(i, this); liberties=ruleset.getLiberties(group, this); //isDead=ruleset.TryKillingGroups(group, this); //if(isDead==true){ //if dead KILL! if(liberties.isEmpty()){ //if dead KILL! killed=group.size(); //first add dead stones to the "bowl" if(color==1){ //Add black stones to the bowl this.blackDeadStones=this.blackDeadStones+killed; }else{ // this.whiteDeadStones=this.whiteDeadStones+killed; } for(int j=0;j<group.size();j++){ this.setMove(group.get(j), 0); } } } } return killed; }
 Here should be the problem. And I guess there is a problem counting libertir There is the problem. And what I see is that tryToKill maybe is changing the main board. public ArrayList<integer> getLiberties(ArrayList<integer> group, Board board){ //given a group, I should count liberties. ArrayList<integer> liberties=new ArrayList<>(); //int groupPointer=0; for(int i=0;i<group.size();i++){ //search to the right if(board.getMove(group.get(i)+1)==0){ if(liberties.contains(group.get(i)+1)==false){ liberties.add(group.get(i)+1); } } //search to the left if(board.getMove(group.get(i)-1)==0){ if(liberties.contains(group.get(i)-1)==false){ liberties.add(group.get(i)-1); } } //search up if(board.getMove(group.get(i)-(board.getBoardSize()+1))==0){ if(liberties.contains(group.get(i)-(board.getBoardSize()+1))==false){ liberties.add(group.get(i)-(board.getBoardSize()+1)); } } //search down if(board.getMove(group.get(i)+(board.getBoardSize()+1))==0){ if(liberties.contains(group.get(i)+(board.getBoardSize()+1))==false){ liberties.add(group.get(i)+(board.getBoardSize()+1)); } } } return liberties; }

More news soon...

Day 54: Rethinking how "possible moves" should work

Let's think this again, I added a lot of code and stopped working, so, maybe some rework (making this better) will clear the scenario. Without details, this is basically the big idea:

Thanks to logs I saw the problem of the last post, somehow in some moves, the machine puts almost all the stones in White... I think that when I finish adding all the logs I will know more about this.

Day 54: This is getting bad...

All was going good until I saw this:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at Elements.Board.getMove(Board.java:65)
at Actors.Ruleset.getGroup(Ruleset.java:62)
at Elements.Board.tryToKill(Board.java:80)
at Start.MainLoop.startGame(MainLoop.java:58)
at Start.Principal.main(Principal.java:14)

I think i feel like: