A problem invented by GoTools

GoTools -- the Tsume-Go program



Try it out   Features   Current limitations   Overall strength   Comparison   Award   Hardware requirements   References   How to get it?   Thanks


Try it out

"A picture tells you more than 1000 words", or "Try it out instead of reading a description". Thanks to Jean-Pierre Vesinet there is now an Applet available where you can type in (preferably closed) life & death positions in the game of go and have them analysed. The analysis is done by the program GoTools described below.

Features

This program for PC-compatibles has been specially designed to perform a number of functions relating to life and death problems.

It has a data base consisting of 2 sets of 12,000 problems each. You can solve the problems by going through the problems yourself, or by asking the computer to show you the correct sequences, or by playing the life and death problems against the computer like a game. The opportunity to play through any possible sequence and to get a direct reply from the computer makes a qualitative difference compared with learning life/death fighting from books where the number of displayed diagrams and variations is necessarily limited.

You can set up your own positions for life and death, store them in different formats and ask the computer to solve them. The interactive play and the solving mode can be useful as a research tool to solve difficult problems or to find new unknown solutions as happened at the 70th aniversary of the Nihon Kiin in Tokio 1994 when running GoTools together with Sirae Haruhiko (5th Pro Dan).

GoTools has different output formats, one is suited for desktop publishing with LaTeX.

You can also test your Go strength by guessing best moves to randomly selected problems. The computer grades your answer and gives you a score based on your performance. According to your strength you can choose different difficulty levels. This mode is well suited for beginners .

Finally there is an automatic problem generation feature that can generate about 100 problems on a PC 486 overnight.

Each day two of the life/death problems generated by GoTools are displayed in "Tsume Go Of The Day" - a page created by Bill Shubert.

Current limitations

The main current limitation is that the program can solve only fully enclosed positions. Another feature is that life and seki are both equally treated as alive. 

Overall strength

The strength of the program compared with human strength depends on the difficulty of the problem. Very simple problems are solved in only one ore two seconds. More difficult problems like
  6  | . . . . . . . . . . .
  5  # # # # . . . . . . . .     Black to move
  4  O O . # . . . . . . . .     =============
  3  O O # # # # # # # . . .
  2  | . O O O O O O # # # .
  1  #-#-#---------#-----#---   GoTools: Black F1 gives Ko.

     A B C D E F G H I K L M    (<1 sec on a 800 MHz Pentium 4)
(also as pretty picture with solution) take about 10 seconds to solve which is still probably unbeatable by humans. For very difficult problems of professional level the computer may take hours or more where higher Dan players may be faster. The following problem needs 2 min on a 800 MHz Pentium III.
      A B C D E F G H I
  19  ----#-------O----
  18  # . . . # . O . .
  17  | . # . . . O . .          White to kill unconditionally
  16  | . . . . . O . .          =============================
  15  O O O O O O O . .
  14  | . . . . . . . .
(or as picture with solution).  This problem has been discussed in [10] and further extensions of the boundary in [11]. The second article is availabe as (PostScript document) and thanks to Darren Cook also online.
In [4] Denis Feldmann rates the overall strength to be of Dan level and in [5] Okasaki Masahiro (correspondent to the Nihon Kiin and semi-professional 6th Amateur Dan) rates the program as 5th Dan.

Comparison with other Life/death programs

The main difficulty in writing a tsume go program is to have an accurate program which does not miss strange looking winning moves and which is still efficient. This can only be achieved by adding more Go knowledge and improving searching techniques. The price is that easy problems are solved slower than before which is no problem because this is a matter of one or a few seconds only. To compare programs one therefore has to compare the times for solving simple, medium _and_ difficult problems.

Another criterion is the accuracy. Whereas a game-playing program is not required to be 100% correct with speed having a higher priority, a life/death program should give a correct solution. By cutting the search tree, GoTools can be speeded up considerably and still have a correctness of, say 80% but not 99-100%. Therefore it makes little sense simply to compare running times if the accuracy is not also checked and compared for hundreds (or, preferably, thousands) of problems. Many problems are necessary to check a program -- some errors in GoTools were found only after years of running correctly with thousands of other problems.

Comparisons were made with life/death programs written by Torsten Harling and Dave Dyer. Running times were comparable for easy problems but for medium and difficult problems GoTools was considerably faster. (The strength of Torsten Harlings program must be related to his short development time of 1/2 year). Because all three programs were run with the same problems (a part of the 40,000 problems which GoTools had generated earlier) this was a good opportunity to find errors which otherwise would, almost certainly, never have been found. All three programs profited from it. 

An award

In 1997 I received the first of the yearly Awards of the Japanese Computer Go Forum. 

Hardware requirements

The program runs on an IBM PC (or compatible) -- from 8088/8086 to Pentium III. The program runs under MSDOS, an MSDOS window under Windows 3.x and under Windows 95 and Windows 98 if booted as MSDOS and with DOSEMU under LINUX. The MSDOS program works inside the 640Kb memory limit.

As the program needs at least about 500 kB, there should not be too many permanently resident programs. The more memory is available, the faster harder problems are solved due to a bigger hash table.

The program runs with all graphics cards in textmode. For computers with a VGA (or SVGA) card a pseudographics mode allows a considerably improved display of stones, and the display of hoshi points. 

Due to a bug in Borland Pascal in the initialization of the delay function, older versions of GoTools will not run on fast Pentium II processors. A patch is available.

References

References below deal with GoTools exclusively or at least to a substantial degree. A more detailed description is given in [3] which is available here as a 14-page PostScript document (75kb file). However this paper does not take into account the latest improvements. The Go-diagrams were generated using the LaTeX facilities described above. [Warning - this file will print correctly on a printer, however it does not work well with all screen previewers. If your browser does not let you view PostScript files you will have to Load to Disk this file, and then send it to a printer]. A report about problems in generalizing GoTools to handle open positions is given in [4], a second PostScript document (100kb file). Thanks to Shigeru Mabuchi, there is a 16 page manual for GoTools available in Japanese (480kB file).

How to get GoTools?

Thanks

A number of people contributed directly or indirectly to this program over the years. I am especially thankful to Volker Wehner who was involved in early stages and Volkmar Liebscher for checking many computer generated problems in early days "by hand" and in connection with the LaTeX facilities. Further I am thankful to David Fowler, Torsten Harling, Dorothea Meisel, Bertram Hoffmann, Iveta Kutscherova, Anders Kierulf, Denis Feldmann, David Dyer, Richard Arundell, Harry Fearnley, Shigeru Mabuchi, Jean-Pierre Vesinet and the many others who found bugs and made suggestions.

This page is maintained by Thomas Wolf

Last updated 20 Nov 2001