TOTAL Refactor

Well, I was making lots of new things to my program and it started failing everywhere, so I decided to document all while recheck my code and change lots of things.

This will be hard, but I want my program working good again in some days.

Day 130: At least it worked

Well, I was having lots of problems with KGS connection, but as I suspected, the problem was not with KGS, it was with me. Every command that don't need a return at least should have an empty string return. Komi command didn't return it so all commands coming from behind were queued.

Solved that, but saw that KO rule was working bad, so I will have to redesing it. I have an idea. I will create a new class for KO, because ko rule will not only need to prevent illegal moves, but start some things in the future.

Day 125: Starting with 0.01F

Some things that I am seeing:

• There were some variables from the pre-gtp era like a hardcoded humanColor and engineColor. With gtp it is not needed, The engine should know what to do in a given circumstance with any color.
• Engine should have an array with the moves of the game, I think this will give me more things to analize.

Getting the engine play better: 

• Will start to try to make the computer see basic eyespace. 
• Some things about corners.
• More about jumps. ->Will try jumps to the center.

Day 124: Games with 0.01E

Well, Evil Tesuji played a game without errors (heavy testing needed, I KNOW, it will crash eventually). A 9x9 game (I will not let it play 19x19 for some time). Playing bad on porpouse Evil Tesuji was destroyed. But it is a start, I know some day it will do it better.

(;FF[4]CA[UTF-8]AP[GoGui:1.4.5]SZ[9] KM[6.5]PW[Evil Tesuji]DT[2012-12-12]RE[B+69.5] ;B[gc];W[dc];B[ff];W[gf];B[gg];W[dg];B[cg];W[ce];B[dh];W[cd] ;B[eg];W[fd];B[gd];W[ge];B[hg];W[df];B[fe];W[bc];B[fc];W[ed] ;B[ec];W[ac];B[bf];W[ig];B[ih];W[hh];B[if];W[hf];B[he];W[ie] ;B[id];W[hf];B[eb];W[ge];B[be];W[bg];B[cf];W[gh];B[fh];W[ag] ;B[de];W[ee];B[ef];W[dd];B[bd];W[hc];B[ca];W[ic];B[cb];W[ch] ;B[bh];W[ia];B[];W[])

White is Evil Tesuji. I know, it plays, horrible, but I know it will be better.

Day 120: The ship is sinking

This projet is not easy, it never was, but sometimes it gets frustrating. The BIG mistake I made all this time was to test it on 19x19, just to see some moves.

I tested yesterday on 9x9 and found LOTS of problems: Hangs, illegal moves (ko, suicide), problems when the player passes and moves in the border. Most of them are being saved, but it is taking me a lot of work to solve all of this. Well, back to work!

Day 119: Testing 0.01D

This is a first test of some moves against 0.01D:

(;FF[4]CA[UTF-8]AP[GoGui:1.4.5] KM[6.5]PW[Evil Tesuji]DT[2012-12-07] ;B[dd];W[pp];B[pd];W[dq];B[co];W[pq];B[jc];W[cc];B[cd];W[cp] ;B[do];W[eq];B[ck];W[qp];B[qj];W[nq];B[jj];W[kq];B[hq];W[po] ;B[ch];W[qc];B[pc];W[gq];B[gr];W[lc])

Hard to say if better or not, by chance it made some interesting moves, but... well, who knows...

Day 117: Readers always are right

On my day 99 post, a reader, Steve, pointed at something that is right. I am using a lot up, down, left and right, so, it is better to create methods for that. I will create them in board class.

public int up(int move){
        int play;
        play=this.getMove(move-this.getBoardSize()+1);
        return play;
    }
    
    public int down(int move){
        int play;
        play=this.getMove(move+this.getBoardSize()+1);
        return play;
    }
    
    public int left(int move){
        int play;
        play=this.getMove(move-1);
        return play;
    }
    
    public int right(int move){
        int play;
        play=this.getMove(move+1);
        return play;
    }

Day 105: some changes

Well, some fuseki problems that I was seeing in the last days are being solved. giving 17 points to a fuseki position and quitting only 15 if it is a bad move (for example, playing komoku in a corner with a hoshi played by the same color) is something wrong, because it still have 2 points + random number (1,5).

So, first I changed 15 to 25, but still there was something I needed to change: quitting 25 points putting the integer 25 is kind of hardcoding now, so I added a variable in my weightValues class "badFusekiMove" or something like that, giving the value 25.

 So, this is how it played now:

(;FF[4]CA[UTF-8]AP[GoGui:1.4.5] KM[6.5]PW[Evil Tesuji]DT[2012-11-22] ;B[pp];W[dq];B[dd];W[cp];B[nc];W[qq];B[qd];W[cc];B[dc];W[pc] ;B[qc];W[co];B[cj];W[eq];B[qj];W[oc];B[nd];W[bc];B[ob];W[fq] ;B[pb];W[iq];B[pd];W[mq];B[pq];W[po];B[qp];W[nq];B[qr];W[rq])

It is not something to be proud of, but... is slight better.

Day 99: Extending

This is just an idea, but, extending from a stone is something usefull to create a wall and to escape from a contact stone.

I know this method will change a lot but let's begin with a simple idea. If a stone contacts a limiting stone of my color, I will add a couple of points to this one.

For example:

       X
     E0

I am 0 and E is the move I am evaluating. I will add a couple of points to the evaluated move. Maybe a random between 1 and 3.

This is the first approach:

/**
     * If someone puts a stone that quits a liberty maybe it needs to extend.
     * @param move The move
     * @param board The Actual board
     * @param color The color of the move
     * @return 
     */
    public int extend(int move, Board board, int color){
        //this will make that any contact move makes the player extend.
        boolean trueAdjacent=false;
        int points=0;
        Random rand=new Random();
        
        if(board.getMove(move-1)==color){
            trueAdjacent=searchAdjacent(move-1,board,1,color);
            if(trueAdjacent==true){
                points=rand.nextInt(4);
                trueAdjacent=false;
            }
        }
        if(board.getMove(move+1)==color){
            trueAdjacent=searchAdjacent(move+1,board,1,color);
            if(trueAdjacent==true){
                points=rand.nextInt(4);
                trueAdjacent=false;
            }
        }
        if(board.getMove(move+board.getBoardSize()+1)==color){
            trueAdjacent=searchAdjacent(move+board.getBoardSize()+1,board,1,color);
            if(trueAdjacent==true){
                points=rand.nextInt(4);
                trueAdjacent=false;
            }
        }
        if(board.getMove(move-(board.getBoardSize()+1))==color){
            trueAdjacent=searchAdjacent(move-(board.getBoardSize()+1),board,1,color);
            if(trueAdjacent==true){
                points=rand.nextInt(4);
                trueAdjacent=false;
            }
        }
        return points;    
    }



I need to create the searchAdjacent method, so this is what I thought:

/**
     * Search for x stones adjacents to one stone.
     * @param move The move
     * @param board the actual board
     * @param number The number of stones that are searched
     * @param color The color of the stone analized
     * @return returns true is number=number of stones ajacents
     */
    public boolean searchAdjacent(int move, Board board,int number, int color){
        boolean adjacents=false;
        int counter=0;
        int opponentColor;
        if(color==1){
            opponentColor=2;
        }else{
            opponentColor=1;
        }
        if(board.getMove(move+1)==opponentColor){
            counter++;
        }
        if(board.getMove(move-1)==opponentColor){
            counter++;
        }
        if(board.getMove(move+board.getBoardSize()+1)==opponentColor){
            counter++;
        }
        if(board.getMove(move-(board.getBoardSize()+1))==opponentColor){
            counter++;
        }
        if(counter==number){
            adjacents=true;
        }
        return adjacents;
    }



Of course I still did not test this... maybe later.

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