Search

Friday, December 28, 2012

Day 140: Back!

Well, I am back after some days with conjunctivictis (both vacterial and viral) :( I am not 100% fine, but will try to continue with all the refactoring.

Thursday, December 20, 2012

Day 132: More refactoring


One more thing that I won't need anymore: The tryToKill method called in the main loop. It will be easier for me if in the setMove method I kill the stones.

This will make me do more refactoring: Suicidal rule will change to.

Wednesday, December 19, 2012

Day 131: 0.01G

Ok, this is changing fast. I am refactoring a lot. So, this is what I think now:


  • The array with the game moves should be in a new class Game. It will be easier to make reference to the game moves if all the methods that manipulate the game array are there.
  • I Created a new package for rules. Every rule will have a class, it is for the future. Some things should change when the engine finds a ko or a suicide.
  • Some old code that I commented is now deleted.
I found console class (Good bye console!!!!!)

Tuesday, December 18, 2012

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.

Monday, December 17, 2012

Day 129: Made me this


Just for fun, this days should come home this tshirt :)

I will feel better while seeing my program being destroyed.

Day 129: Problems with KGS

Ok, the engine works playing using goGui, but not in KGS, I will try to write what happens:


  • I connect with my user account Draculinio
  • Connect Evil Tesuji using his account on KGS.
  • Start a game.
  • KGSGTP says something about opponen left the game and returns
  • From what I see in my log, some commands are sent, like komi.
  • No genmove or play commands sent :(
So, here are my problems... :(

Sunday, December 16, 2012

Day 128: The failure after 15D

Well, some good things and some bad things.

Connection worked!
So, I saw Evil Tesuji there:


And almost played:


And then, my little daughter started to cry, and couldn't play the game, then, we went to a birthday party :( But, first thing done. Now, let's try again.


Thursday, December 13, 2012

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.

Wednesday, December 12, 2012

Day 124: Readers are always right part II



A reader sent me a suggestion about the last "Readers are always right" post. The variable play is not needed, it only needs what I sent to that variable. So, now it is corrected.

Thanks Sergio!

If you still think, "why the picture?" Sergio is a big fan of the band.

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.

Tuesday, December 11, 2012

Day 123: Passing working

Well, I just solved the passing. Still waits for the other player to pass so it will pass. Not a big thing but, is better than nothing. I still don't know how to force a ko or a suicide shape to see if it works.

So, let's continue with the development. One step forward, one step back... the hard truth...

Monday, December 10, 2012

Day 122: This is getting hard

I think I solved some issues, but to get a stable version is another thing. Sometimes ko method is not working at all, I will test it again tonight and make loads of changes. So, the debut will be with 0.01E for now. Suicide seems to be working.

This IS hard.

Saturday, December 8, 2012

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!

Friday, December 7, 2012

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 119: Preparing Evil Tesuji for debut

Well, right now I am reading how to connect my engine to KGS, I am trying very hard to run first tests without me playing by Dec. 15th.

For now I think that the version 0.01D (the actual) will be playing, I will continue to develop version 0.01E and if it is stable by then, then let it play :)

There is a tutorial on how to set up bots in kgsgtp file, and there is another one here, so, I if you are often on KGS maybe in next days you will see Evil Tesuji account connecting and desconecting all the time :).

I know Evil Tesuji will be destroyed in every single match. But I am really wanting to see it play, it is just a starting point for this.

Thursday, December 6, 2012

Day 118: Going further with last post

Thinking about last post I saw that lot of things can be redone using new methods. In-which-line-is-the-move  guesser can be done. And I will use it for jumping later.

Tuesday, December 4, 2012

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; }

Friday, November 23, 2012

Day 106: Get group size

Until now all I have is a method returning an array of stones of the same group, but any time I needed to know how many stones are in the group I needed to get the group and count the array positions. I created a new method for that, so I don't have to do this in all the methods that need a size of a group. Why? I saw that I will need something like this in methods like "Jump".

Thursday, November 22, 2012

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.

Wednesday, November 21, 2012

Day 104: Playing 0.01C

I just played some moves against Evil Tesuji 0.01C. I see I still fail in some things at fuseki stage. I thought it should work with latest changes but still... Well, here is the thing:


(;FF[4]CA[UTF-8]AP[GoGui:1.4.5] KM[6.5]PW[Evil Tesuji]DT[2012-11-21] ;B[pd];W[cp];B[qp];W[eq];B[qj];W[cd];B[jc];W[cq];B[cj];W[pq] ;B[qq];W[po];B[qo];W[dp];B[cg];W[nq];B[jp];W[qc];B[qd];W[dc] ;B[cm];W[pp];B[qn];W[cc];B[pn];W[dq])
Will try to solve fuseki problems first, that last move hurted.

Friday, November 16, 2012

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 99: Writing code on blogger

It is hard to post code on blogger, until now I just made some HTML tricks, so I was needing to do something else.

I am trying now BlogTrog, let's try with getGroup method:

/** * Gets all the groups by a color * @param board The board where the game is played * @param color The color that wants to be analyzed. */ public void getGroups(Board board,int color){ Ruleset ruleset=new Ruleset(); ArrayList<Integer> group; ArrayList<Integer> liberties; //Console console=new Console(); for(int i=0;i<board.getMainBoard().size();i++){ if(board.getMove(i)==color){ group=ruleset.getGroup(i, board); liberties=ruleset.getLiberties(group, board); } } }
Wow, it is good. Let's keep it for now.
BlogTrog website

Wednesday, November 7, 2012

Day 90: To Git or not to Git, that is the question

This last days I was thinking if it is a good idea to upload the code to github or something like that. There are some points:

  • The need of sharing code. 
  • I don't want to have in the future 1000's of clones running on KGS like GnuGo, I don't care about people modifying code and uploading them, but why does KGS have only clones? 
  • It will be easier for me to document code. 
  • Will have to read about licences, I will obviously choose some really open licence, but have to read a lot.

If you have more pro/cons, just tell me.

Monday, November 5, 2012

Day 88: Returning and Javadocs

Returning after some days is hard with not well documented code, so, these days I will be doing some javadocs. Here is a video (in spanish)of Javadocs in NetBeans In such a big program is good to have this VERY well documented. This is not the only thing that I will be doing, because on Dec. 15th. this bot will make his first games on KGS. So, I need to work hard.

Friday, October 19, 2012

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

Thursday, October 18, 2012

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:



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.

Wednesday, October 17, 2012

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!

Tuesday, October 16, 2012

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.

Sunday, October 14, 2012

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

Saturday, October 13, 2012

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.

Friday, October 12, 2012

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.

Thursday, October 11, 2012

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:


Wednesday, October 10, 2012

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.



Monday, October 8, 2012

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.

Friday, October 5, 2012

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.

Thursday, October 4, 2012

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.


Wednesday, October 3, 2012

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!

Tuesday, October 2, 2012

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

More news soon...

Monday, October 1, 2012

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:


Friday, September 28, 2012

Day 51: More code deleted and state


As I said some days before, "human" class didn't have any more sense in the program. Now I saw that "console" class have the same problem. The only console I need is the gtp console, so console class can be out of here (but I will make a backup of the class, just in case some day for some weird reason I want to add a parameter to show the game in console).

Now, this is how classes are right now:


So, one part of the boring update is on, now, let's continue logging. Next post will have a log.


Thursday, September 27, 2012

Day 50: Back to work!

After some days without touching code, I am back!


Now is time for some boring work:


  • Log everything in the system. I just want that all what the machine "thinks" keeps logged. That is because it is hard to find bugs in another way. 
  • Redo the class draw. I really love coding and sometimes being a lot analyzing how it should work is boring. BUT NEEDED.

Tuesday, September 18, 2012

Day 41: Deleting unused code

A lot of things changed when I decided to use GTP. Human class is not needed anymore, so I am deleting it.  I had lots of problems with code, so these days I made some changes, reorganized and fixed some bugs.

I am slow nowadays, raising a baby, working and returning to university having 34 years is hard, but I promise that in 2 days I will be back with more computer go.

Monday, September 10, 2012

Day 33: Implementing suicide, the hard part is comming



Sorry my programming is a little slow now, but I am adapting myself to be a father and this is a hard job (but the best one). These days I will post more and will increase productivity.

Last time I made a "Suicide Rule method". Now is time to implement it. The boolean possibleMove will be back to false after verifying ko rule (well, it can be in false when reaches this part, but who knows...). Then possibleMove=isSuicide(bla bla bla). If true, the move is not playable.

With this, rules about possible moves are over. Now I have to make the program understand "eyes", "territory", "points" and all this... The hard part is comming.

Thursday, September 6, 2012

Day 29: Suicidal rule

Until now I was filtering possible moves by two things:


  • Spaces with a 0 (Empty)
  • There is no Ko
But, there are other spaces that could be not allowed to be played, let's see suicidal rule:


In most common ruleset, suicide is forbidden, so for now it will be for my program (maybe some day I will do something for the other rulesets).

So, there is how I will implement it:

  1. The number of liberties of the group if I play this move == 0?
  2. If not, move is allowed
  3. if yes, try to kill groups of the other color.
  4. If kills, move is allowed
  5. if not, this is a suicide move and can't be played.
I just created a method to see if a move is suicide (this is my first aproach, not tested yet):



Maybe tomorrow I will continue coding, or today if I have some time (I wish I can). 

Monday, September 3, 2012

Day 26: Logging


To see if all what I want to control on the engine is working the way I like, I need to log all that it does. This is the first approach to this:

Important: In Windows 7 you need to run GoGui in Administrator Mode.
I made methods to:


  1. Log any String I want.
  2. Log the date and time
  3. Log the board as it is in the moment.

 

I have to make some changes but the basic idea works. Now I can delete console class and replace it with this.

Saturday, September 1, 2012

Day 24: Stupid errors, the most common and hard.



I really think that the stupid errors the most obvious are sometimes the hardest to find and correct. In the old days a ";" were a problem and now some "logic" errors in big messes are a big deal. As I said I was changing all the main loop (and will change more things to organize and make code clearer) and implementing GTP commands. When I ran the program using GoGui it sent me inexistent positions in the board and when I ran the program using my console the result was good. After a lot of research of "what the hell is going on", the error was that I implemented the clear board command using boardInitialize of my board class and it added more positions to the arrayList. So, now I can play with goGui randomly and not using the suicide rule.

Day 24: The reason of my absence.

Four days without appearing here! I had the best time of my life, my first Daughter was born. Right now I feel like the happiest man on the world, she is the most beautiful baby I've ever seen. This is a short post because I don't have the words to describe how happy am I.


Tuesday, August 28, 2012

Day 20: Logger



I am having some errors with the change to GTP, so, I need to see what is happening in the program every time this moves. I will need it anyway to study what the program does now, I don't have the console anymore to see results because now I write to the GTP console.

So, I am working on a class to log whatever I want.

Day 20: Problems, problems everywhere...



From the begining I knew this was going to be hard. Now, this is getting harder, I just don't understand what the hell is happening. When I run my program sending manually the command "genmove w" it worked fine, but with gogui, sometimes it sends incorrect data. I am just confused, don't know what is happening, I will try to fix this to continue. I also want to log all what the engine does. I can't use the console for this, I will do it in a file or something...

Monday, August 27, 2012

Day 19: GTP, starting the hard things



The day has come, in the weekend I was reading how GTP works and was thinking how to make it work on my program. I will try to implement a simple command to see if it works...

MAYOR UPDATES MADE IN THE main loop, this is hurting. 

Ok, I downloaded and installed GoGui, to see how it works. As the people of computer-go mailing list told me, GTP uses standard IO so just used inputStreamReader (with the bufferedReader) and System.out.Println().

Right now I implemented:  play, name, version, protocol_version, list_commands, boardsize and clearboard. For now boardsize just returns true, it is hardcoded to 19 so, every game I start will be 19x19 (I can hardcode it to whatever). boardsize calls board initialize.

This is what I get in GoGui:


Well, next have to make it play and then some refactor to make the code more clear.

Friday, August 24, 2012

Day 16: GTP, standard I/O and stuff



So, now it's time to start thinking about GTP, but first, there is the need of understanding standard input & output in java.

So, some tutorials of Java IO:

From Oracle site

Dick Baldwin

GTP:

Site

GnuGO GTP

GTP if you like it un Ruby

Day 16: Ko, part III



Well, something like a ko was implemented in the program, but still couldn't test it.

First I changed tryToKill from void to integer and return number of killed stones:



So now, main loop will take the result when killing stones.

And now I have to pass as parameters the last board, number of killed stones in the last turn and the color to evaluate. So I changed the getPossibleMoves method:



Now I know that the engine should send more parameters to the getPossibleMoves method of the ruleset:


So, last thing to show is the "isKo" method, that returns true if the move is a ko and false if it is not:

Next: I know I should start with suicide rule, but... I want to see it on a better graphic interface so I will work on GTP and loging.