computer-go: About Viking

[magnus.persson@xxxxxxxxxx]

On 8 Jan 01, at 9:59, Anders Kierulf wrote:

> Can you provide some information on your Viking program? The 
web site in
> your signature doesn't appear to have been updated since 1997...

Yes, the homepage is completely uninteresting and will be for 
some time. I am spending all my spare time now to beat gnugo on 
NNGS... :-)

I have been interested in computer go for 10 years, but it is not 
until recently I have made a program that is not utterly bad.

My approach first was to never use patterns for anything in my 
program but 1 1/2 year ago I switched and made a fairly general 
patternmatcher, which I now use for everything except tactics. I 
guess the general approach is more or less similar to most 
programs. There are no neural nets or something exotic in it just 
algorithms and pattern knowledge for go.

The version playing on NNGS now does not know very much about 
eyes and nakade. I am now rewriting the representation of groups 
such that such pattern knowledge can be used. 

The main idea is to have a very good an accurate evaluation 
function, and make at least one whole board evaluation for each 
possible move on the board. It does about 0.5 to 6 wholeboard 
evaluations per second. (If it ran on a slower computer than 500 
Mhz it would be painfully slow). The tactical reader can do about 
5000 nodes a second. 

-- Now my few cents on computer languages

I am programming in  object pascal with Delphi 5 Standard. 
Originally the code was written in C, then ported to C++ and then 
finally to Pascal.

Delphi is as efficient as C++, not as complex but complex enough 
to take advantage of object oriented programming - and it is very 
easy to write user interface code with it. I make a visual inspection
window for every datastructure I use which make it much easier to 
debug the code. Most of the cases the code is more or less 
correct before it is used to play games. (Then I have to redesign he 
code because ideas was bad... but thats another story) 

-- On the discussion of raw representation of the board:

 It is very complex (I think it is similar to what Manyfaces uses - 
that was my impression when I read Fotlands paper on it), and is 
designed to sacrifice memory for speed as it was originally written 
for an 1Mhz Amiga. 

Making and unmaking moves is completely irrelevant for the 
performance of my program. 

The fundamental bottleneck is the patternmatching, with only 
patternmatching used it takes a few seconds to play a move. 

With tactics on it needs up to 40 seconds to play well in messy 
middlegame situations. The increase in strength from adding 
tactics is about 4 stones.

I am now also writing a tactics-reader that should be able to handle 
any kind of fighting much better. But this will be slow. I would be 
very happy if it can make even 500 nodes/second. Perhaps I will 
use that in some kind of emergency mode and not in the normal 
whole board evaluation. The philosophy is that if it is very accurate 
it can be as slow (node per second) as a dan-player. That is 
dreaming of course. But thats my philosophy right now. Some 
years ago it was write to spend 10000 of nodes on local tactical 
search, but then I realised that this was perhaps very important for 
10 to 20 moves in a game. But for the rest something different was 
needed.  

I almost forgot my main principle:
There should be no compromises in how the program represents 
things. Either a chain of stones is connected or it is not, and 
the program should now exactly why.

And there is no joseki-library. The idea is that the program should 
be prepared for any move you play against it. A joseki-library is the 
last thing I will implement in my program - that is: never since there 
will never be a last thing to do....

I hope the blurb above is informative enough for your curious minds!

best wishes
Magnus