RE: [computer-go] Dealing with aji in go programs

[Arend Bayer <arend.bayer@xxxxxx>]

> > -----Original Message-----
> > From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> > [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of Arend Bayer
> > Sent: Sunday, December 05, 2004 6:50
> > To: computer-go
> > Subject: [computer-go] Dealing with aji in go programs
> >
> >
> >
> >
> > On Sat, 4 Dec 2004, Mark Boon wrote:
> >
> > > current Go programs. Recognising and evaluating aji is one. An important
> > > concept that I don't think any program handles well, if at all
> > (Goliath has
> > > a half-hearted attempt in it.) Properly estimating the effect
> > on the score
> >
> > Do you mind explaining how you tried to do this in Goliath? I have
> > been sporadically thinking about how to do this for GNU Go since I
> > joined the project 3 years ago.
> >
(...)
> 
> I actually had to go back to the code to see what was there, as I didn't
> remember exactly. There are two main things. One is a board-array that has
> some aji-values (the aji[] array :). These values are a simple feauture
> counter, where each type of feature contributes to one single number. These
> features are typically things like, dead stones but not tactically dead,
> number of atari's without putting oneself into atari, weak groups with less
> than one and a half eye (where the bigger the group,the more it contributes
> to aji), etc. Note that these are actually examples of 'bad' aji.

I see. What I vaguely have in mind is s.th. like the following:

   A B C D E F G H J K L M N O P Q R S T
19 . . . . . . . . . . . . . . . O . . . 19
18 . . . . . . . . a a O . X X O . O . . 18
17 . . . . . . . . a a a O O O X O O . . 17
16 . . . + . . . . a a X X X O X X X . . 16
15 . . . . . . . . . . . . O X . . . . . 15
14 . . . . . . . . . . . b . X . . . . . 14
13 . . . . . . . . . . . . . . . . . . . 13
12 . . . . . . . . . . . . . . . . . . . 12

The two black stones at the top are tactially dead, but every dan player
would see immediately (even if he didnt know this joseki) that they have
a lot of aji. He would explain this to a kyu player by the fact that all
of the moves 'a' are threatening to rescue them (and a few more after
black has added a stone at 'b').
This should be easy to find out for a program. The natural way to
represent this knowledge in a go progam should be to block the influence
of the White stones from propagating along the top side.


> The other thing in Goliath is not computing aji, but it's a principle
> designed to reduce bad aji. Whenever the opponent plays a move that seems to

Yes, GNU Go (and I guess most go programs) also has a couple of
heuristics like that.


Arend

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/