[computer-go] Remarks on the Indigo-Paper

Chrilly c.donninger at wavenet.at
Sat Jun 17 14:01:27 PDT 2006


>>
>> It can be found at this address, on the website of Bruno Bouzy:
>> http://www.math-info.univ-paris5.fr/~bouzy/publications/bouzy-chaslot-cig05.pdf
>>
>> Sorry, either the link is wrong or I am too stupid to access it. I land 
>> on
>> some wikipedia-page.
>
> ...or not stupid enough?  I can access the .pdf just fine through that 
> URL.
>
> Weston
Thanks I succeeded to download it now.
The - for my work - interesting part is only described shortly. How is the 
4-way tree organized? Does one follow the spiral? How is the spiral limited. 
E.g. with the 15-K best mode it would mean in the opening to spiral almost 
along the whole board.

Vincent's law is: Every change in a weak programm is an improvement. I know 
only the Indigo of the Graz Olympiad 2003. At least this version was a weak 
programm. I was mostly impressed by the UUI (Unusable User Interface). I 
found it strange that someone is working for years on a programm and has 
such an interface. A good GUI is very important for developement. But one 
can write no paper about it.

If one buys enough tickets one always wins in the lottery. It is very 
instructive to play with "different" versions which are in fact completly 
identical against each other. One also gets a significant improved version. 
We have therefore in the Hydra team the rule: If a new version makes a top 
score, the 140 test-games are repeated. In many cases the big improvement 
disapears. It was just a statistical effect.
It is also well known that autoplay is the worst possible improvement 
measurement. Very minor changes/improvements are exaggerated by autoplay.

Generally I think that this automatic extraction of Pro-Dan games is 
pointless, because the current programms and the Pro-Dans play completly 
different games. A lot of patterns in 15 Kyu play are never seen on Pro-Dan 
level. And on the other hand it is many cases a desaster to play some short 
sequences (e.g. Josekis) of Top-Players. Theses patterns are beyond the 
scope of the programm (same happens if one learns as a weak player some 
josekis or chess-openings). Although current chess programms are as strong 
as top-humans, a lot of human opening lines are for the programms not really 
playable. E.g. we played in Bilbao 2005 against Kazimshanov on purpose a 
closed King-Indians just to see if we can even play this opening. We knew 
beforehand, that this system is not really playable. Kazimshanov got a very 
good position, but was then tactically crashed by Hydra. We have therefore a 
very small hand-picked book of about 4000 positions which fit to the style 
of the programm. This is much more effective then creating from the 
ChessBase MegaBase an automatic book with 1MPos..

It has some comic in the paper, that a sequence of autoplay is shown. This 
only proves that the program knows its own patterns. But - as is stated in 
the paper - one 10 Kyu move and Indigo would answer with its "natural" XX 
Kyu knowledge.

A programm is in my opinion best improved by (the points are sorted by 
priority):
1) Making a good development environment. E.g. a good GUI, a database to 
store test positions, a set of testcases, a well defined procedure to test 
the versions, Coding standards.
2) Keeping the bug-rate as low as possible. Which means besides doing 
carefull work and point 1: KISS.
3) Having an efficient and especially simple representation of the basic 
entities (e.g. in chess of the board-state).
4) Eliminating the biggest blunders.
5) Having from time to time some good idea, and try it out as long as it 
does not violate point 1-4.

All these points are unfortunatly not respectable in the academic world. 
E.g. I do not know of any systematic threatement of point 1). At a best some 
remarks about the measurement problem are made (and then ignored like in 
this Indigo-paper). Therefore have strong programms no impact on the state 
of the academic art and the academic art has also almost no influence on the 
state of the programms.

Chrilly



More information about the computer-go mailing list