@1
 1 1 80 24

          GoTools - a program for solving life/death problems in Go.
          __________________________________________________________

 0. Before starting

   Although the program can solve many difficult problems rather efficiently
 one should not expect wonders and as with all Go-software, there is always
 something to improve. If the program estimates during solving a problem, that
 it will take, say, 10 times as long as you are willing to wait then the
 problem is simply too difficult for the current version of the program.

   A general hint is that the program should be run under MSDOS, not WINDOWS
 or OS2, to have all time-measurement facilities (time bar in `Daily Exercise'
 and clocks in the `Play' mode) available. Depending on how much memory is
 available (not occupied by memory resistant programs) the program can
 allocate a bigger or smaller data base. A big one will remember more of the
 positions solved during a long calculation. This will speed up the solution
 of difficult problems. You can check the size of your database by selecting
 `Run | clear dBase'. Optimal are 16,000 entries, good are 8,000 entries.

   Functions described below might be of varying interest for different users,
 for example depending on their playing strength. Problems generated in the
 `daily Fresh' mode might be too simple for strong players but just the right
 for weaker players. On the other hand these functions are mainly independent
 and could therefore be ignored if they are not of interest.

   If your version of the program is a demo version then all features of the
 full version are included. The restriction is that only very simple problems
 can be solved. This also means that the running times are very short and that
 you have no time to inspect the graphic display of the tree search (by
 pressing `g') unless you can switch your computer to lower speed. Further,
 the demo version has included only a set of about 200 of the simpler
 problems.

 1. A short guided tour:

   For a quick start select `File | load Random', choose a low difficulty (to
 have quick response times afterwards) and try to solve the loaded problem
 yourself first.  Then you may step through its solution by selecting `Run |
 shoW solution' or you can ask the computer to solve it by choosing `Run |
 crack Specific'.  You will be asked a number of questions, like how fast and
 accurate the calculation shall be.  The answers given will be stored and
 doing calculations later by calling `Run | crack Default' will use the
 specifications of the previous run.

   Another possibility of checking a solution is to play the problem against
 the computer by choosing `Run | Play'.  To try this out now, press <ESC>,
 afterwards come back to `Info'.

   If you want to change a position by adding or removing stones, select
 `Edit | Position' which will, as a side effect, delete the solution of the
 problem to edit, if you had assigned or calculated a solution before.  To
 specify which side should move first in the displayed problem or to add
 a solution to the problem on the board, chose `Edit | Solution'.  Then you
 could save the problem under a name of your choice with `File | Save', clear
 the board with `Edit | Erase' and reload the problem with `File | Load'. With
 `Run | shoW solution' you can convince yourself that the solution was stored
 as well.

   Whereas the status of a position together with a sequence of moves is
 always stored through `File | Save', the whole search tree, or at least a
 major part of it is stored as a hash table only if specified after calling
 `File | Save'.  The hash table is loaded automatically later if the problem
 is loaded with `File | Load'.  It is a good idea to save the hash-table
 together with the problem, if one wants to play the problem with `Run | Play'
 after loading it and does not want to recalculate it.

   The menu entry `File | Load' loads problems which are stored each in an
 individual file. To save more than one problem in a file or to read a problem
 from such a file use `File | sAve/del packed' and `File | load Packed'. When
 loading packed problems you must either know the problem name in the packed
 file or its position, e.g. being the 10'th or 115'th problem in the file.
 This allows you in principle to go through all the problems in the packed
 files lv1\lv1.1 ... lv1\lv1.14 ... . When saving a problem to a packed file
 you must specify a name for the problem which starts with the letter `p'
 followed by maximally 7 digits. If you want to list the names of all problems
 within a packed file, choose `File | lisT packed'.

   The menu entry `Modify' provides you with functions to do specific changes
 to positions.  `Modify | Close' adds stones if necessary to completely
 surround a position.  By choosing `Modify | Trim' stones which are not
 relevant are removed and with `Modify | Rotate' you can rotate, shift or
 mirror the whole board.  You also can switch colors.

   To really practise evaluating positions quickly and to check your strength
 you can select `Run | daily Exercise'.  With this menu item you have to guess
 the best move to a number of pre-calculated problems and you obtain marks
 according to your performance.  The number of problems to be solved and the
 available time, can be changed.  The problems used in this exercise are
 stored in packed form.  Hint: If one of the problems should turn out to have
 a wrong solution then you can note its name and the file name in which it is
 stored, then load it using `File | load Packed', solve it by hand or with
 `Run | Crack' and store it with `File | saVe/del packed' under the same
 names.  You also can delete it with `File | saVe/del packed'.

   To print a position on paper there are two commands available which write
 the position into an appropriate file.  One way is to use the command `File |
 write Ascii' which generates a simple ASCII file.  The second version is
 to use `File | write laTeX' which generates a LaTeX file.  To compile the
 resulting LaTeX file, a special LaTeX style file as well as some font files
 are necessary.  Those are available on an extra disk which can be obtained
 together with this program or separately.

   Finally, under the menu point `Run | daily Fresh', new life/death problems
 are automatically generated.  As this generation procedure requires some time
 it should be run when the computer would otherwise be idle, e.g. at night.

   To summarize quickly, there are different ways to use the program:
 - If you want to test yourself whether you can guess the best move then
   choose `Run | daily Exercise'.
 - If you want to have an own problem solved and you are interested mainly in
   the solution then type in the problem under `Edit | Position' and solve it
   with `Run | crack Default' or `Run | crack Specific'.
 - If you do not only want to know the solution but to analyse a problem, i.e.
   to try out different moves, then choose `Run | Play'. This mode might be
   slower than the previous mode because here effort is spent to select one
   of a number of winning or losing moves.
 - Finally you can generate new problems over night using `Run | daily Fresh'
   and inspect them the other day with `File | Load' in the directory c4\d1
   or in following ones.

 2. Restrictions which apply to the current version:

   The program knows about simple and multiple KOs.  It determines the winner
 if no external KO-threat is played, and after that it determines how many
 external KO-threats the loser would have to ignore in order to win.
 The following limitations apply to the solution routines:

 - The main restriction is that so far only positions with a completely closed
   boundary can be investigated.  As a consequence, open problems will be
   closed before evaluation.  If this automatic closure provides a boundary
   which is too wide the computing time may become unnecessarily high.  If the
   boundary is too tight then the status might be affected by the new extra
   boundary stones.  Then one should close the boundary manually by choosing
   the menu point `Edit | Position'.

 - The program can determine one winning move as well as all winning moves in
   the Run | Crack mode. To increase efficiency, for the followup moves always
   only one winning move is determined, i.e. the moves of the winner in the
   winning sequence of moves need not be the quickest way to win and the way
   the loser played need not be the optimal way to postpone the loss.

 - Whenever the side who wants to kill can not capture the other stones, the
   position is regarded as being alive, regardless whether it is unconditional
   life or seki, double Ko or triple Ko (which usually is regarded as a draw).

 - In KO situations, the program determines only the number of exterior KO-
   threats which one side needs to win, and not whether this number results
   from interior KO-threats of the other side or because a multi-step-KO
   occurs.  This can be justified because, after all, the number of external
   KO-threats that have to be won is a measure of the price paid and which
   must be compensated by the gain i.e. the value of the position.

 - No special semeai playing abilities are incorporated so far.  A well formed
   problem has only one colour on the "outside". Many semeais can be converted
   to this standard form, however you should do so with care.  Sometimes these
   converted semeais can take a long time to solve.

 3. Acknowledgement

 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 providing 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 Daniel Audet.

 4. Disclaimer

 Because of the complexity of the program, no guarantee of the correctness of
 its results can be given.  If any error is detected, please send the position
 and a description of the error to Thomas Wolf, 2 McDonagh Cresent, Thorold,
 L2V 4C3, Ontario, Canada, or using email, to T.Wolf@brocku.ca. Later versions
 of GoTools will profit from it.  Please note the following disclaimer.

    GoTools is supplied as it is.  The author of GoTools disclaims all
    warranties, expressed or implied, including, without limitation,
    the warranties of merchantability and of fitness for any purpose.
    The author assumes no liability for damage, direct or consequential,
    which may result from the use of the software.
                                                        Enjoy it!
@2
45 5 80 16
In order to use this program, the
boundary of the problem had to be
closed. If the new boundary is too
wide then the solution will be
unnecessarily slow or if the boun-
dary is too tight then the status
might have been changed. In either
case press <ESC> and Edit|Position
to close the boundary by hand.
Otherwise proceed with <Enter>.
@3
18 7 62 14
 Choose one number with cursor and <ENTER>
 or mouse. Each number is the bonus you get
 if you solve the problem correctly. The
 higher the number, the more difficult is
 the problem and the greater the risk of
 getting nothing.
@4
4 2 77 22


 In the following exercise you need to find the best starting move
 to     life/death problems. You have the choice between easy problems
 worth 100 points if correctly solved, and harder problems worth a
 maximum of 500 points. You get half the bonus if your move results in
 KO and either it is not the best KO, or there was an unconditional win.

 For maximum marks you get at first      sec to solve each problem.
 After that you get another     sec during which your bonus gradually
 shrinks to zero.

      -----> BLACK always plays first in these problems! <-----

 To play, select a field with the cursor or mouse, then press <ENTER>
 or click a mouse button.

 To start the Daily Exercise now, press <ENTER>, for changing the
 number of problems to solve or the available time press any other key.
@5
46 11 78 15
You need to put in a life/death
position before calling this
function.
@6
25 11 56 14
For help select the menu item
or subitem and press F1.
@7
3 2 78 20



 In the `daily Fresh' mode the computer generates new life/death problems
 randomly. The name convention and place of storage is as follows:
    All problems will be stored in a directory C \ and subdirectories of
 it where the ` ' may be any digit in the range 4..9. (Digits 1 and 2 are
 already in use for the problems in the `Daily exercise' and 3 is
 reserved). Since you can choose this digit, you are advised to have
 different digits on different computers on which you run GoTools to avoid
 name clashes of an otherwise unique naming convention.
    To have not too many files in one directory, single problem files are
 stored in subdirectories C \D1, C \D2,.. . Whenever such a directory
 includes 256 problem files, they are packed into one single file which is
 stored in C \ under the consecutive names d 001p, d 002p, .. . To free
 disk space, from time to time delete individual files which are already
 packed.
@8
3 2 78 20
    As long as the problems are stored separately, each in a single file,
 you can use the menu item `File | Load' to load them into GoTools. Once
 they are packed you can use `File | load Packed'. The convention for the
 problems in packed form is that the file Ca\DabcdP stores the problems
 Pabcdefg where
 `a'   is a digit which is fixed and should be different for different
       computers on which problems are generated,
 `bcd' is a 3-digit number running from 001 to 999 which counts the gene-
       rated packed files,
 `efg' is a 3-digit number running from 001 to 256 counting the problems
       in each packed file.
 These 3 numbers are stored in a file RANZ in the order efg bcd a. If this
 file is accidentally deleted, then the next problem would be P4001001,
 overwriting previously generated problems. To start `daily Fresh' now,
 press <ENTER>, for changing the number `a' (the computer index) press any
 other key.
@9
% This is a LaTeX2e file.
\documentclass{article}
\usepackage{diago}
\begin{document}

\Large\golength0.045\textwidth\gothinness0.8pt\gothickness2pt
% The above line gives a large board with large letters and numbers.
% This line can be omitted for a smaller board.
% \gothinness0.8pt sets the thickness of inner lines on the board.
% \gothickness2pt  sets the thickness of the edge of the board.
% for more comments see the file test.tex
\goboardini
\board1--19/1--19/
@10
4 5 76 19
 The two numbers after `all/ver. leaves:' characterize the size of the
 search tree where the first is the number off all leaves of the tree
 searched and the second is the minimal number of leaves to be searched
 if heuristics had been optimal.

 The number after `overhead:' gives the amount of unnecessary search
 due to imperfect heuristics which is the ratio of the above numbers
 minus 1.

 The number after `curiosity:' is the rank which the first move shown
 had in the very first heuristic evaluation which the program
 undertook. The higher the value - the less did the program expect the
 first move to be the best.
@11
6 4 75 18
 About the numbers on the right bottom:

 To solve the problem many sequences of moves are played through.
 all:   gives the number of all sequences considered so far.
 life:  says how many of those ended with life and
 death: how many ended with death.
 m-dep: gives the number of moves in the longest sequence so far.
 mem:   gives the size of the remaining free memory in bytes.
        The longer the sequences the higher are the memory re-
        quirements. Sequences are restricted to maximally 60 moves.
 ko-th: is the number of Ko-threats which one side at least needs
        in order to win. If this number is positive then B(*) needs
        these threats else W(o) needs these threats.
@12
1 1 80 24

                       Frequently asked questions
                       __________________________

Question:

"When putting in a position occuring in a game or with holes in the boundary
 then GoTools seems to freeze."

Answer:

GoTools is a program to solve closed boundary problems. This recent version
at least can be given open boundary problems but no guarantee can be given
that it will solve it efficiently. The program can not only get lost in
positions with big holes but also if the boundary is closed but weak.
Therefore, if possible have a closed strong boundary.

Question:

"In one problem the killer had to move first and GoTools did not find the
 move which at least would have given a seki! All other moves end in
 unconditional, independent life."

Answer:

The reason for not finding the sekis is that GoTools does not distinguish
between life and seki. This is mentioned in the program in the menu point
`Info | Intro'. This has the following consequence:

 - If one first move leads to life and another leads to seki then the first
   of these which is found is taken and no further search is done because
   life and seki are currently regarded as equivalent. So it may be that
   the first move found only gives seki though another move would lead to
   life.

 - Similarly, if the killer starts moving, and seki or life are the only
   possible outcomes, then both are considered to be a total loss. Any move
   is played, which delays life or seki for as long as possible - not
   necessarily the move which gives seki.

 - Either of these two things can happen after any move, not only after the
   first move.

 - You are only sure that your first move is the absolutely best one if
   this move is the only one that wins (or obtains the best ko) when you
   run the CRACK mode, and you have asked the program to determine _all_
   winning moves, and it turns out that there are no others. This
   opportunity to determine all winning moves in a given situation
   exists only for the starting situation, not deeper in the search tree
   where in each situation only one winning move is determined, and not
   all.

---------

Question:

"When I have solved a problem in the `Daily exercise' then I am asked whether
I want to play this problem through. I am also told that if the problem is
difficult then this could take some time. Why should it take extra time? Is
the solution not already saved together with the problem?"

Answer:

What is saved is only one sequence of moves, i.e. the winning move and one
possible continuation. To play a problem through the computer must be able
to answer _any_ _one_ of your moves, i.e. it has to know the whole search
tree. This tree to save means to save the whole hash database ~180 kb for
only 1 problem and there are some 1000 problems.
  One can solve the whole search tree (if it fits into the data base) for a
problem that has just been solved by GoTools. After selecting `File | Save'
you are asked whether you want to save the tree as well. The size of the
hash data base depends on how much RAM memory the program has available
(not used by resident programs) and varies from 255 entries to 16,000 entries.
This size is shown on screen when you clear the database under `Run|clear
dBase'.

---------

Question:

"How much memory does GoTools take and does this effect the speed?"

Answer:

GoTools runs in the 640 kByte real memory under DOS. The amount of
available memory depends on how much memory is blocked by resident
programs. The more memory is available, the bigger the hash data base
that is chosen (automatically) and the faster that difficult problems
can be solved. This affects problems with more than, say, 8000 leaves
(counted by the number after `all:' on the right bottom of the screen
when the solution is in progress). For big problems it therefore is
better to have no other resident programs occupying memory.

---------

Question:

"In the menu point `Info | Intro' it is said that `Edit | Position' will, as a
side effect, delete the solution of the problem to edit. What all is deleted
and what is kept?"

Answer:

At one time only one position is kept in memory which is the one shown on the
board, if any. Deleted is who is to move first and the solution (status and a
sequence of moves) of this problem. The reason is that a changed position may
have a different status and/or a different first move. The contents of the
hash database are not deleted as they are still accurate. So if the problem
would not be changed in the edit process and be solved again then the answer
would come quickly through the experience collected in the data base.

---------

Question:

"Sometimes, for difficult problems, a message appears saying that the search
 depth is too deep, and search stops. I have 8 MByte of memory. Why is that
 not enough?"

Answer:

As explained above, only 640 kB are maximally used currently but that is not
the real issue here.
    Difficult tsumego problems are not just a question of more memory or
higher speed. During the solution of such problems, sequences of moves may be
encountered which include cycles such as triple-ko. As long as these cycles
repeat exactly, they can be avoided but it may be that cycles do not repeat
exactly, i.e. that they are only similar to each other and not identical. Then
they can not be ruled out in principle and very long sequences of moves may
occur (>100 moves). Here no memory and speed can help as what one has to
investigate in this case is not a single sequence of 100 moves but a huge tree
with a depth of >100 moves and a branching factor of perhaps 20 in order to
get an exact answer. Here only more Go-knowledge can help to avoid bad moves,
like self-atari, which lead to recurring situations. But this is difficult as
sometimes the correct move includes a big sacrifice. Therefore it is hard to
tell whether a move is useless without trying it out. But trying it out is
just what we need to avoid, if possible, to avoid getting into such long
sequences of moves. The only answer to this is to choose a faster and less
accurate mode of calculation in `Run | Crack' or to wait for later versions of
GoTools.

---------

Question:

"What is the best way of avoiding the same problem in the `Daily Exercise'
mode?"

Answer:

The 24.000 problems of volumes 1-6 used in the `Daily exercise' are the ones
left after throwing out identical problems or essentially identical problems.
Still, many are similar but there should always be a minor but real difference
which might not need to change the solution but at least has somehow to be
considered when solving the problem. At least the difference is big enough
that the program had to do a slightly different calculation.

The only way of avoiding such similar problems is to choose different
difficulty levels.

---------

Question:

"What does ^f in the mode `Run|Crack' mean, i.e. how can one put it in?
Why can it not be a simple letter like `s'?"

Answer:

^f means Ctrl f and stops the calculation like in unix ^z interrupts a process
or like ^c is the interrupt which usually stops a program.
A simple key is usually not used for terminating a process by hand but
the combination of 2 keys or in serious cases 3 keys (Ctrl+Alt+Del).
---------

Question:

"The time bar in `Daily Exercise' does not work and also not the time
measurement in the `Play' mode."

Answer:

If GoTools is run under WINDOWS or OS2 then the real time clock interrupts
as they are used in GoTools do not work, therefore GoTools should be run
under MSDOS with as little as possible memory occupied by resident programs.
As the choice of board color, ... is stored in an extra file to be used
when the program is started the next time, it may lead to difficulties if
GoTools is started repeatedly under WINDOWS with different board colors
chosen.
@13
10 6 69 19
 The stored hash database can not be loaded.

 The size of the hash database which was stored differs
 from the size of the database used currently. GoTools
 tries to maximize the amount of memory used for the
 database to speed up longer calculations. Obviously at
 the time the database was formerly stored, a different
 amount of memory was available than is available now.
 This may be caused by running GoTools in a different
 environment or by having memory resident programs loaded
 at one time and not at another time, or by running
 GoTools on different computers.
@14
10 10 70 15
 The depth of the search tree had to be cut to complete
 the search. This may have affected the accuracy of the
 result and the current contents of the hash tables. You
 can clear the hash table with `Run | clear dBase'.
@15
10 10 70 15
 The problem to be solved is too big for the demo-version.
 Only small problems are supposed to be solvable in this
 version. In Play mode therefore computer moves need not
 be accurate.
@16
46 13 75 16
 Search depth must be cut
 because of too few memory.
@17
15 10 67 18
 In this demo version of GoTools only very small
 problems are generated to demonstrate the method.
 Problems generated in the full version are larger
 in size and are more difficult. Also, because many
 slightly more complicated problems are dropped,
 the production rate of problems is lower than in
 the full version.
@18
24 10 58 14
 In this demo version of GoTools
 you have only access to the
 simplest class of problems.
@19
8 2 71 24
 Elapsed time:

 A rough and possibly too generous estimate for the time
 until either the problem is solved or until a new internal
 ko-investigation starts, is:

 If a ko-investigation starts or is repeated with a higher
 number of threats to be investigated then the absolute
 value behind `ko-th:' in the lower right corner of the
 screen increases. In this case
 - if the situation is really a ko then the calculation may
   easily last the same time as was already spent,
   the estimated time is about right.
 - if the situation is not a ko then the program normally
   realizes this soon and would not spent to much extra time,
   the estimated time is initially too high.

 The estimated time given above is only a probability measure
 which normally fluctuates and which can serve only as a very
 rough guideline. If the program has only just started then
 the estimated total time may be too small.
@20
15 6 67 21
 The blinking field or stone in the following
 position indicates the cursor which you can move
 with the cursor keys but not with the mouse.

 If you want to play a ko then just set the stone
 which is forbidden by ko. The computer will then
 ask you whether you really mean it and will count
 one more ko-threat having been made and answered.

 The numbers in the lower right are the times used
 by the player and the computer.

 To see comments press `m' and to change who plays
 next use `p' for player and `c' for computer.
@21
11 10 68 14
 Please reset the computer with the reset button or
 with Ctrl+Alt+Del and try again. Do not start GoTools
 under Windows, OS/2 or other environments than MSDOS.
@22
18 13 62 24
 You can: - add a solution         <a>
          - delete one solution    <d>
          - delete all solutions   <k>
          - view a solution        <v>
          - change a solution      <c>
          - duplicate a solution   <u>
          - move a solution up     <p>
          - move a solution down   <n>
          - comment on a solution  <o>
          - finish input       <ENTER>
@23
20 9 59 16
 There is too little (MSDOS-) memory
 available for GoTools to solve
 larger problems completely. You can
 increase the available memory if you
 have less permanently resident
 programs loaded.
@24
45 2 80 23
To set up a life/death problem,
chains have to be selected which
try to live, i.e. the position
will be regarded as alive if at
least one of these chains sur-
vives and only be declared dead
if none of them can live. Choose
between one and four chains for
that purpose. A chain belongs to
this list if it is colored.

To change the list of chains,
move with the cursor to a stone of
a chain and press

DEL   to drop the chain from this
      list or press
SPACE to add a chain to this list.

Complete the input with ENTER.
@25
44 1 80 24
0: influence        m: merk[]
1: freep            n: constkett[1]
2:                  o: continue
3: teilconsistence  p: print 
4: crosscuts(semei) q: counterproof
5: vga board        r: area
6: ascii board      s: situat
7:                  t: fitness
8:                  u: linkused
9: dist (disabled)  v: FreepIstPfl.
a: save position    w: wall
b: HashDump         x: sacri
c: constkett        y: eHashDump
d: deck             z: no inner pts
e: destruc          A: unnuetz2
f: wurfkett         B: PopArea
g: go to            C: liveheu
h: this menu        D: monolitheye
i: wallkiller       E: kostelle
j: inner            F: umlauf
k: ConstKeim       ^f: exit & quit 
l: fleechn          ENTER: next move
@26
46 13 74 16
 Search depth must be cut
 because of depth limit.
@27
46 1 73 10
 Input of the position:

 select a field: <ARROWS>
 white stone:    <o> <w>
 black stone:    <*> <b>
 forbidden ko-field: <k>
 delete stone:   <DEL>
 finish input:   <ENTER>
@28
46 1 80 10
 Input of the position:

 select a field: <ARROWS>
 white: <o><w> right mouse button
 black: <*><b> left  mouse button
 forbidden ko-field: <k>
 delete stone:   <DEL>
 finish input:   <ENTER>
@29
46 1 77 15
 Editing a sequence of moves:

 select a field: <ARROWS>
 make move:      <SPACE>
 del prev. move: <BACK>
 del next  move: <DEL>
 pass:             p
 save position:    s
 move back:      <PgUp>
 move forward:   <PgDn>
 goto start:       < 
 goto end:         > 
 finish input:   <ENTER>
@30
46 1 77 15
 Editing a sequence of moves:

 select a field:   <ARROWS>
 make move: mouse, <SPACE>
 del prev. move:   <BACK>
 del next  move:   <DEL>
 pass:               p
 save position:      s
 move back:        <PgUp>
 move forward:     <PgDn>
 goto start:         < 
 goto end:           > 
 finish input:     <ENTER>
@31
20 10 59 15
 This is not a single problem file.
 Choose "load Packed" in case you
 want to read a problem from a packed
 problem file.
@32
46 5 80 22
Although the search depth is
limited, the result will still
be exact and conclusive if either
- this limit was never reached or
- the specified maximal search
  depth is either an odd number
  (3,5,..) and the side moving
  first has won or if it is an
  even number (2,4,..) and the
  side moving second has won.
Therefore, assuming ..... moves
first, input an odd number if
a result `..... has won' should
be trustworthy and input an even
number the result `..... has won'
should be trustworthy.
@33
46 5 80 10
To have a minimal computation
time one should answer this
and all following questions
by pressing <Enter>.
@34
46 5 80 9
Computations <2> and especially
<3> can become lengthy for large
problems.
@35
46 5 80 9
For difficult problems this
may take much longer than
solving the problem.
@36
27 8 53 11
This menu item in not yet
supported under linux.
@37
26 10 54 12
Too many moves to consider.
@38
5 9 75 16
If your screen is not large enough for the following display you have
the option under unix to reduce the font size of the xterm window 
BEFORE starting GoTools: switch NUM LOCK on (which may require 
pressing the function key for keyboards without extra number keys), 
press the SHIFT + MINUS keys of the number pad once for each 
reduction of font size, switch NUM LOCK off.
@39
5 4 75 18
WHAT IS SHOWN:

In this display points on the go board are represented by rectangles.
Black stones are shown as green filled rectangles and white stones as
white rectangles. Ko-forbidden fields are shown in magenta.  Up to 3
numbers can be inscribed in a rectangle.  At first we describe the
meaning of the number in the second row, then in the third row and
further down in this text the meaning of the number in the top row 
of a rectangle.

To each empty point and each chain is attached a number which for
empty points is ment to be a measure of influence and for an occupied
point it is supposed to be a measure of strength of the chain, that 
is represented by the point. This number is shown in the CENTER (2nd 
row) of a rectangle. If it is not displayed (for example, on an empty
board) then Black and White have even influence on this point. If for
an empty point this number is red then it is supposed to be the
probability to be occupied or owned later by White and if it is black
then it is supposed to be the probability to be occupied later by 
Black. (Colors may change to adapt to the specific display of colors 
on the screen.) Numbers in the lower right corners of a rectangle 
show how many iterations were necessary to compute the number in the 
center. Iterations are not done equally often for different points 
but are dynamically decided based on the size of the last change of 
value.

Based on the central number in each rectangle a total score is com-
puted and shown on the right (described below) which is the expected 
score solely based on this relatively poor influence function for the
current board position. But the program determines more.

For each empty point on the board the program determines what would
happen, if the next move would be on this empty point and computes 
the influence function for the whole board, computes the total score 
and remembers the highest score for all possible moves. Then it takes
the difference of this higest score with the score of each individual
move and displays this difference as the TOP number in each rectangle
of an empty point. Thus the best possible move (according to this 
influence function) has a 0.0000 shown in the first row of its 
rectangle. The higher the number in the top row, the worse is the 
move according to this influence function. 

One of the rectangles is surrounded in White or Green. This is the
cursor that can be moved with the arrow keys. The color of the cursor
is the color of the side moving next. In principle the color moving 
next is a parameter to the evaluation function, although currently it
is hardly used. 

When moving the cursor over the board then on the right hand side of
the screen the number behind `ignorable:' changes. This number is 
the percentage of moves on the board that will give a lower score 
than the move marked by the cursor. Thus one can move the cursor over
the board and can get a quick feeling of which moves are favoured by 
the influence function and which not.

On the right hand side the top box shows command keys (see help for a
description). Underneath follow parameters that are used to compute
the influence function. The `accuracy parameter' is not a real
accuracy measure of the computed value but a threshold parameter.  If
the change of the influence value in the last iteration step got
bigger than this threshold then all its neighbouring units (empty
points and chains) have to be iterated again.

The over-relaxation parameter is a parameter that allows to speed up
computation dependent on the situation. For empty boards it seems 
that a value 1.0 is best whereas for filled boards larger values, 
like 1.5 may be better.

The maximal number of iterations of each single strength/influence
value is limited by a parameter underneath. Lowering this parameter 
to small values <10 gives a slight speed up without a serious loss
of accuracy because too many iterations lead to values which have not
much to do with reality as vital knowledge is so far ignored, see
below.

The next group of numbers shows the total white and black area based
on the computed numbers. Their sum should total up to (board
size)^2. The difference of both numbers is the score value
corresponding to Chinese counting where captured stones are ignored.
If the program is currently stepping through a game then the number
behind `ignorable:' is the number of possible next moves which has a 
score less than the score of the next move in the game. In other 
words, in order to consider the next move in the game the program 
could have ignored so many percent of moves which had a lower score 
than the next move in the game.

The next output underneath shows a statistics of the last computa-
tion. The number of evaluations shows the total of how often numbers 
were computed in the iteration. The column nderneath lists fields /
chains and the number of how often their value was computed.

The horizontal bars underneath the board represent the current score,
with a red bar extending to the left indicating White's lead and
a green bar to the right indicating Black's lead.

- (Current) weaknesses: 
  - The information of which side moves next is hardly used.
  - Even the knowledge that moves are made alternatively by both 
    sides is currently not used (e.g. safe link through miai). 
  - The importance of a chain is currently not used and thus whether 
    a response is under guarantee made if an essential chain would 
    be attacked. 
  - A life & death analysis of chains is not made.
  - Each chain has only one identity, no matter what its size is.
    For example, for a chain to be sacrificed the resulting empty
    points after capture will have different identities and play 
    different roles.
@40
5 4 75 18
WHAT CAN BE DONE:

- By putting stones on the board with <b> or <w> one can study how 
  the evaluation function changes with a slightly varying position.
- By pressing <m> one can find the move that optimizes the score for 
  its side, solely based on this evaluation function. It is instruc-
  tive to start with an empty board play a game this way.
- The evaluation function partly takes into account who moves next. 
  By pressing <n> one can see how the evaluation function changes by 
  changing who moves next.
- A simple illustration of the different shells around the cursor
  is shown after pressing <s>.
- With <z> one is shown the size of the data structures involved.
- By pressing <c> the board is randomly rotated and mirrored, colours
  are switched and the evaluation function is re-applied and the 
  resulting values are compared with the original values before the 
  rotation. If no comments are given then all is correct.
- The iterative computation stops when changes become less than some
  value which is shown on the screen behind `accuracy parameter:' and
  which can be changed by pressing <a>.
- The over-relaxation (OR) parameter is a factor by which the change
  in each iteration step is `over-done'. To have over-relaxation the
  value has to be >1, for stability this factor should be <2. It can 
  be changed by pressing <p>. It seems for an empty board the value 
  should be =1.0 and for filled boards possibly >1 (eg. 1.5).
- The maximal number of iterations at each point and chain can be
  changed by pressing <x>. Numbers <10 should be adequate and give
  a slight speed up.
@
