New born Go board program

[JKadreamer]

Dear Folks

I have created a Go board program as my personal project. Please visit

http://sites.google.com/site/goboardproject/

and let me know your opinion.

It works for edit and playing a game as a GTP client like other SGF editor. The main reason I made this program is to persue my own idea I used to have about Go strategy as a computational algorithmic approach, and I needed a program communicating with my analysis program. The most big difference can be seen on GoEngine Viewer that currently displays influence factor in some different ways, and I will add up more analytical functionalities on this package. My approach might be a bit different from other programs in this community, and I will document it as my job proceeds.

This is just a beginning, and I will try to communicate as much as I can regarding this matter.

Thank you in advance.

JK, A Sweet Dreamer

[karaklis]

I haven't checked it out yet, but I will definitely do it. From the description the feature "go engine to go engine" seems interesting. I've been looking for that for a long time.

Edit: Downloaded and installed. I wanted to try to run two programs against each other.
First GnuGo and Fuego: I copied the options for both engines from Drago. Fuego doesn't need any options, but in Wildcard options are required, so I entered space. A whitish screen appears ("GoBoard Status, Startup GoPlayers"), and after about a minute the program crashes, i.e. an OS message pops up that the program doesn't run properly any more. Then I read that Wildcard was only successfully tested with GnuGo and Aya, but the result was the same. A user-engine setup with any of these two engines again provided the same result.

I am using Windows 7.

[freegame]

looks nice. I was also very interested in the GoEngine Viewer.

I just tested it and...
It does not really do a good job handling dead stones.
in this example there are three more or less dead stones on the top of the board.


I just compared it with the same position in Moyo Go using the "influence" option there.
It has very similar flaws. I does a little bit better job in that it takes into account the edges of the board,
but it does not visualize the result as nicely. It also mishandles "dead" stones.

Cyber Oro has a very good score estimate that analyses a board position like this, but I don;t have that installed on this computer.

[JKadreamer]

karaklis and freegame

Appreciate for your quick response!

karaklis
My program has been tested on Windows XP and Vista, not Windows 7 yet. I am not sure if the problem was caused by OS, and I will try to find another computer of windows 7. I wish I can give you another answer soon. For your information, I have attached some screen shots.
Fuego04 has some different GTP textout compare to GNU Go. This is the reason I haven't worked for GTP interface with Fuego.
Another picture is the GoPreference setup for GNU Go and Aya634e. With this, it works fine on my Windows XP desktop. Please try this and let me know if the problem doesn't go away.

freegame
You are right, and I would say you are a step ahead of me.
With influence factor, the program doesn't do "Life and Dead" analysis or "Territory" evaluation yet. And I still have many questions regarding this matter. One of the questions I have is how a go engine (or even human being) should understand the influence on the board.

Let say that "almost captured stone" should not have any influence. Then, how could a go engine find that the stone is still valuable in a specific situation? From your screen shot above, the white stone at F17 and the black stone at H16 are, I believe, considered dead. However, what if a Ko case occurs somewhere later and player want to pull it out from the location?

Actually, I am working on this matter now as a homework. The analysis will include influence factor, stability of stone (group) and board reading. I would say it is a huge matter, and I wish I can give you soon some reasonable resolution regarding this.

Thanks again.

[JKadreamer]

The program has been revised to "7" as of Aug. 8 on my time.
This was about the correction of SGF file writing error in GoBoard program.

Regards,

[CarlJung]

Let say that "almost captured stone" should not have any influence. Then, how could a go engine find that the stone is still valuable in a specific situation? From your screen shot above, the white stone at F17 and the black stone at H16 are, I believe, considered dead. However, what if a Ko case occurs somewhere later and player want to pull it out from the location?

IMO if it's dead right now it should not have influence. It may play an important role later, but that's for later.

[Li Kao]

If you're writing a MC engine then how about just counting how often each point ends up white/black and use that to print the influence?

[karaklis]

The result is exactly the same. In the process list it is always the second "goplayer.exe" that crashes when clicking the "new game" button.
When I setup a user-engine match, it doesn't crash, but it doesn't do anything.

The engine setup outputs the following text:

First Aya:

<< White Engine Exe: C:\pgm\go\Aya\Aya.exe
<< White Engine Arg: --mode gtp
<< White Engine Name: Aya2
<< Board Size: 19 x 19
<< Handicap: None
<< Komi: 6.5
<< Time: 1 Hour
<< WhitePlayer GoBoard WhiteUserID Read
> GoBoard GoPlayer Show

Then I changed it to GnuGo, and that's the output:

> GoBoard WhiteUserID TrUserID
<< Referee Engine Exe: Find and place the Go engine..
<< Referee Engine Arg: No information yet..
<< Referee Engine Name: No information yet..
<< Black Engine Exe: C:\pgm\go\Aya\Aya.exe
<< Black Engine Arg: --mode gtp
<< Black Engine Name: Aya1
<< White Engine Exe: C:\pgm\go\gnugo\gnugo-mingw-36.exe
<< White Engine Arg: --mode gtp
<< White Engine Name: GnuGo
<< Board Size: 19 x 19
<< Handicap: None
<< Komi: 6.5
<< Time: 1 Hour
<< WhitePlayer GoBoard WhiteUserID Read
> GoBoard GoPlayer Show

(Black is actually set to "user", but the engine settings for Aya are still visible).

[topazg]

Let say that "almost captured stone" should not have any influence. Then, how could a go engine find that the stone is still valuable in a specific situation? From your screen shot above, the white stone at F17 and the black stone at H16 are, I believe, considered dead. However, what if a Ko case occurs somewhere later and player want to pull it out from the location?

IMO if it's dead right now it should not have influence. It may play an important role later, but that's for later.

I agree. Also, I have a belief that influence is only part of the picture. Stones inside enemy territories create aji, and having a way of representing the aji is just as useful and relevant as influence - neither are useful on their own I think (having toyed with such things before - my memory was a French programmer had a website that did something similar?)

[CarlJung]

I agree. Also, I have a belief that influence is only part of the picture. Stones inside enemy territories create aji, and having a way of representing the aji is just as useful and relevant as influence - neither are useful on their own I think (having toyed with such things before - my memory was a French programmer had a website that did something similar?)

Yes. In this case aji and influence is closely related. Being able to distinguish between what stones have aji and what stones are 100% dead is a very difficult task to program, and probably not very productive. It's easier to treat somewhat dead stones where aji still exists as dead.

[CarlJung]

Woah, you're still using Visual C++ 6.0?
(that's what PEiD says at least)

[topazg]

I agree. Also, I have a belief that influence is only part of the picture. Stones inside enemy territories create aji, and having a way of representing the aji is just as useful and relevant as influence - neither are useful on their own I think (having toyed with such things before - my memory was a French programmer had a website that did something similar?)

Yes. In this case aji and influence is closely related. Being able to distinguish between what stones have aji and what stones are 100% dead is a very difficult task to program, and probably not very productive. It's easier to treat somewhat dead stones where aji still exists as dead.

I'm not so sure. A lot of aji is in typical shapes, with obvious followups to those that know the sequences. Having a tool that can work out whether those sequences look contextually playable is very valuable - especially as that's the sort of thing I'm actually doing with over 50% of my reading time on a Go board.

[CarlJung]

I agree. Also, I have a belief that influence is only part of the picture. Stones inside enemy territories create aji, and having a way of representing the aji is just as useful and relevant as influence - neither are useful on their own I think (having toyed with such things before - my memory was a French programmer had a website that did something similar?)

Yes. In this case aji and influence is closely related. Being able to distinguish between what stones have aji and what stones are 100% dead is a very difficult task to program, and probably not very productive. It's easier to treat somewhat dead stones where aji still exists as dead.

I'm not so sure. A lot of aji is in typical shapes, with obvious followups to those that know the sequences. Having a tool that can work out whether those sequences look contextually playable is very valuable - especially as that's the sort of thing I'm actually doing with over 50% of my reading time on a Go board.

It would be useful if you could somehow query for what those sequences are. It's very interesting and would involve writing a pattern matcher, kind of the one moyogo has. But it's a gargantuan effort if it's only for displaying pretty graphics. That's where the not productive part came from.

[freegame]

My program has been tested on Windows XP and Vista, not Windows 7 yet.

I'm running Win 7 64 bit and had no problems so far, but I did not test everything. (did not play with/against bots for one thing)

However, what if a Ko case occurs somewhere later and player want to pull it out from the location?

then he can still not safe the stone if correctly responded to the treat, so the "dead" stone has should have no color on your mad. It does however have aji. This could be put in the program by reducing the amount of influence of the other player in the direction of the liberties that the "dead" stone has left. The number of liberties can give the amount of reduction.

taking my earlier example: H16 has only 1 lib left facing the center, the stone itself is dead and should have no color. but it has aji in that there is a forcing move at H14. this means that black can reduce the influence of the white stones on the side where there is still a liberty left. but it's only a small reduction. there is only 1 lib left, so after the first forcing move at H14 black has a weak stone attached to the strong white stones.
O17 is also not alive (so no red color). However this stone still has 3 libs left. Therefore there is a lot of aji. White can threaten to connect to the bottom, threaten to pull it out, or threaten with something like M18. each example is threating to use the aji of the O17 stone in one of the direction it still has liberties left. and because it has 3 libs left, the amount of aji is a lot bigger then in the H16 case.

If you're writing a MC engine then how about just counting how often each point ends up white/black and use that to print the influence?

this would be a great too to detect the "dead" stones, and to use as general support for the methode you are using now. (it will most likely also correct for the edges of the board.

[JKadreamer]

karaklis

The result is exactly the same. In the process list it is always the second "goplayer.exe" that crashes when clicking the "new game" button.
When I setup a user-engine match, it doesn't crash, but it doesn't do anything. ).

I have tried to make same situaton you have. A screen shot is attached below, and I believe that this is your current setup. I run GoBoard in game play mode, and it works fine again.

karaklisSetup.jpg (57.3 KiB) Viewed 12342 times

I have no idea yet, but I suspect one thing below.

<< White Engine Exe: C:\pgm\go\gnugo\gnugo-mingw-36.exe

I don't know the detail of "MingGW", and I would suggest you that windows executable of GNU Go is available at
http://gnugo.baduk.org/

Those GNU Go 3.6 and 3.8 in Zip file were tested on my program.

Regards,