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.
Labels:
baduk,
computer go,
design,
go,
main loop,
programming,
rules,
weiqi
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!!!!!)
Labels:
baduk,
computer go,
design,
go,
igo,
ko,
programming,
rules,
weiqi
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.
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
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... :(
Labels:
baduk,
computer go,
frustrating,
go,
gtp,
igo,
KGS,
Personal,
problems,
weiqi
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:
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.
White is Evil Tesuji. I know, it plays, horrible, but I know it will be 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...
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.
This IS hard.
Labels:
baduk,
computer go,
go,
ko,
problems,
programming,
weiqi
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!
Labels:
baduk,
computer go,
engine,
frustrating,
go,
igo,
ko,
problems,
programming,
weiqi
Friday, December 7, 2012
Day 119: Testing 0.01D
This is a first test of some moves against 0.01D:
Hard to say if better or not, by chance it made some interesting moves, but... well, who knows...
(;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.
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; }
Labels:
baduk,
computer go,
engine,
go board,
java,
programming,
weiqi
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:
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:
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.
Labels:
baduk,
computer go,
engine,
go,
igo,
java,
programming,
weiqi
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:
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:
If you have more pro/cons, just tell me.
- 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.
Labels:
baduk,
computer go,
go,
igo,
Personal,
programming,
weiqi
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:
Maybe I can use this in the near future...
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!.
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:
Labels:
baduk,
computer go,
fuseki,
igo,
java,
programming,
weiqi
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!
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.
Labels:
baduk,
computer go,
engine,
fuseki,
go,
igo,
programming,
weiqi
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".
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".
Labels:
baduk,
computer go,
engine,
LifeAndDeath,
programming,
weiqi
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.
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!
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.
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.
Labels:
baduk,
board,
computer go,
design,
engine,
frustrating,
LifeAndDeath,
problems,
programming,
rules,
weiqi
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.
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.
Labels:
baduk,
computer go,
engine,
frustrating,
igo,
problems,
weiqi
Day 64: Some things about Fuseki IV -Komoku-
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;
}
Labels:
baduk,
computer go,
design,
engine,
fuseki,
go,
igo,
java,
programming,
weiqi
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.
I know is not the best way to do it, but, with time and complexity this will change.
Let's see the result:
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:
Labels:
baduk,
board,
computer go,
engine,
fuseki,
go,
go board,
igo,
java,
programming,
weichi,
weiqi
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.
Labels:
board,
computer go,
design,
engine,
fuseki,
igo,
programming,
weiqi
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.
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).
Labels:
baduk,
board,
computer go,
design,
engine,
go,
igo,
java weiqi,
programming,
weiqi
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.
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.
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:
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:
- Make less logging (just log the same info but writing less).
- 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.
- 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 :).
Labels:
baduk,
computer go,
frustrating,
gtp,
igo,
log,
problems,
programming,
weiqi
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:
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.
Labels:
baduk,
computer go,
design,
go,
gtp,
log,
programming,
weiqi
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:
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.
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:
Maybe tomorrow I will continue coding, or today if I have some time (I wish I can).
- 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:
- The number of liberties of the group if I play this move == 0?
- If not, move is allowed
- if yes, try to kill groups of the other color.
- If kills, move is allowed
- 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):
public boolean isSuicide(Board board,int move, int color){
boolean suicide=false;
ArrayList group = new ArrayList<>();
ArrayList liberties = new ArrayList<>();
int killedStones=0;
board.setMove(move, color);
if(color==1){
killedStones=board.tryToKill(2);
}else{
killedStones=board.tryToKill(1);
}
//If there are no killed stones
if(killedStones==0){
group=this.getGroup(move, board);
liberties=this.getLiberties(group, board);
//If no liberties found, then it is suicide.
if(liberties.isEmpty()){
suicide=true;
}
}
return suicide;
}
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:
- Log any String I want.
- Log the date and time
- 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...
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.
Labels:
baduk,
board,
design,
engine,
go,
gtp,
java,
programming,
translator,
weiqi
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.
Subscribe to:
Posts (Atom)