[gnugo-devel] arend_1_30.4: ascii doc update

[Arend Bayer]

 - README/TODO/INSTALL brought up to date, with some revisions
 
For README/INSTALL this is almost only an update to current default
settings. 

For TODO I had intended as well to just do some updating, but ended up
doing some more revisions. Some are of course a matter of opinion, and
there I tried to make the changes modest (i.e. what is written below is
somewhere between what was written and my own judgements). Well, not
that it matters very much.


Arend


Index: INSTALL
===================================================================
RCS file: /cvsroot/gnugo/gnugo/INSTALL,v
retrieving revision 1.5
diff -u -r1.5 INSTALL
--- INSTALL     4 Mar 2002 06:49:07 -0000       1.5
+++ INSTALL     30 Mar 2002 09:43:41 -0000
@@ -17,11 +17,11 @@
 
    ./configure --enable-cache-size=32 --enable-level=8
 
-creates a 48 Mb cache in RAM and sets the level to 8.  Both these
+creates a 32 Mb cache in RAM and sets the level to 8.  Both these
 defaults can be overridden at run time.
 
 If you do not specify any options, the default level is 10 (highest
-supported) and the default cache size is 16. These defaults are
+supported) and the default cache size is 8. These defaults are
 probably suitable for most systems unless GNU Go seems too slow.
 
 You have now made a binary called interface/gnugo. Now
@@ -32,7 +32,12 @@
 to install gnugo in /usr/local/bin. This will also install the man
 page gnugo.6 into /usr/man/man6. Fuller documentation can be found
 in the doc/ directory. (See THE MANUAL below.)
+  
+After you have installed GNU Go, you can save disk space (and still keep
+the source files) by typing:
 
+  make clean
+  
 There are different methods of using GNU Go. You may run it from the
 command line by just typing:
 
@@ -49,7 +54,7 @@
 
                           RAM CACHE
 
-By default, GNU Go makes a cache of 16 Megabytes in RAM for its
+By default, GNU Go makes a cache of 8 Megabytes in RAM for its
 internal use. The cache is used to store intermediate results during
 its analysis of the position.
 
@@ -72,7 +77,7 @@
    ./configure --enable-cache-size=48
 
 creates a cache of size 48. If you omit this, your default
-cache size will be 16. You must recompile and reinstall GNU Go
+cache size will be 8. You must recompile and reinstall GNU Go
 after reconfiguring it by running make and make install.
 
 You may override the compile-time defaults by running gnugo with
@@ -94,7 +99,7 @@
 ./configure --enable-level=9
 
 sets the default level to 9. If you omit this parameter,
-the compiler sets the default level to 8. We recommend
+the compiler sets the default level to 10. We recommend
 using level 10 unless you find it too slow. If you decide
 you want to change the default you may rerun configure
 and recompile the program.
Index: README
===================================================================
RCS file: /cvsroot/gnugo/gnugo/README,v
retrieving revision 1.4
diff -u -r1.4 README
--- README      15 Oct 2001 00:21:16 -0000      1.4
+++ README      30 Mar 2002 09:43:42 -0000
@@ -4,6 +4,7 @@
 found at http://www.gnu.org/software/gnugo/devel.html. Consult TODO if
 you are interested in helping.
 
+
                           Installation
 
 In short, './configure; make' will build GNU Go; optionally (running
@@ -31,6 +32,7 @@
 Contact us at address@hidden if you are interested in helping to
 develop this program.
 
+
                     Running GNU Go via CGoban
 
 This is an extremely nice way to run GNU Go. CGoban provides a
@@ -189,7 +191,7 @@
 
 
 * `-M', `--cache-size MEGS'
-     Memory in megabytes used for hashing. The default size is 16
+     Memory in megabytes used for hashing. The default size is 8
      unless you configure gnugo with the command `configure
      --enable-cache-size=SIZE' before compiling to make SIZE
      the default.
Index: TODO
===================================================================
RCS file: /cvsroot/gnugo/gnugo/TODO,v
retrieving revision 1.8
diff -u -r1.8 TODO
--- TODO        2 Feb 2002 19:05:12 -0000       1.8
+++ TODO        30 Mar 2002 09:43:43 -0000
@@ -45,9 +45,8 @@
 engine internals.  The issues are presented here in an approximate
 order of perceived difficulty.
 
- * Add a check in patterns/mkpat.c that the main diagram and the
-   constraint diagram are consistent. Currently it is only verified
-   that they have the same size.
+ * Add more checks in patterns/mkpat.c testing whether the main diagram and
+   the constraint diagram are consistent.
 
  * Complete the conversion to 1-dimensional representation.
    Check all comments before functions to make them agree with
@@ -66,16 +65,7 @@
 
  * Make the cache not waste storage on 64 bit systems.
 
- * a) Add move history for "permanent" moves (i.e. ones done with
-   play_move(), in contrast to temporary moves done by
-   trymove()/tryko()) in the board code. Notice that the move history
-   must be added to the state in the Position struct.
-
-   b) Implement undo for "permanent" moves in the board code and
-   replace various other undo implementations in play_gtp.c,
-   play_ascii.c, and play_gmp.c with this.
-
-   c) Implement detection of superko violation in the board code. We
+ * Implement detection of superko violation in the board code. We
    probably only want this optionally in play_move() and in a variant
    of is_legal().
 
@@ -86,7 +76,7 @@
    half_eye_data, worm and dragon to use the same structure as the
    dragon2 array.
 
- * Implement hashing and persistent caching in the semeai code. 
+ * Implement persistent caching in the semeai code. 
 
  * Support for ko in eyes.db and optics.c.
 
@@ -119,30 +109,26 @@
    square, and so on. Other areas where test suites would be most
    welcome are fuseki, tesuji, and endgame.
 
- * Tuning the pattern databases. These are under constant revision 
-   This is a sort of art. It is not
-   necessary to do any programming to do this since most of the
-   patterns do not require helpers. We would like it if a few more Dan
-   level players would learn this skill.
-
- * Extend and tune the Joseki database.
-
- * The semeai module is vastly in need of improvement. In fact, semeai
-   can probably only be analyzed by reading to discover what
-   backfilling is needed before we can make atari. 
+ * Tuning the pattern databases. These are under constant revision.  This
+   is a sort of art. It is not necessary to do any programming to do this
+   since most of the patterns do not require helpers. We would like it if
+   a few more Dan level players would learn this skill.
+
+ * Extend and tune the Joseki database. It might be very useful to implement
+   a semi-automatic way of doing this.
+
+ * The semeai module is still in need of improvement.
    (This is underway.)
 
  * The connection analysis is today completely static and has a hard
    time identifying mutually dependent connections or moves that
    simultaneously threatens two or more connections. This could be
-   improved by writing a connection reader, which like the owl code
-   uses pattern matching to find a small amount of key moves to try.
+   improved by writing a connection reader.
    (This is underway.)
 
- * GNU Go has a problem with opponents that build big moyos.  This is
-   because there is no move generator that tries explicitly to neither
-   build nor enter opponent moyos. Such a move generator could be
-   built using the same type of code that is used in the owl life and
+ * GNU Go does not have a move generator that tries explicitly to build
+   moyos, or reduce/invade opponent's moyos. Such a move generator could
+   be built using the same type of code that is used in the owl life and
    death reader, or the connection reader mentioned in point 5 above.
 
  * A much improved combination module.  The combination module of
@@ -152,16 +138,16 @@
    also be strong enough to find combinations of strategic moves and
    more indirect threats (a threat to a threat).  Possibly it could
    combine threats in AND-OR trees (DAGs?) that could be searched
-   using ordinary tree search algorithms. (Revision of combination.c
+   using ordinary tree search algorithms.  (Revision of combination.c
    is underway.)
 
  * Speed up the tactical reading. GNU Go is reasonably accurate when
-   it comes to tactical reading, but not always very fast. The main
+   it comes to tactical reading, but not always very fast.  The main
    problem is that too many ineffective moves are tested, leading to
-   strange variations that shouldn't need consideration. To improve
-   this the move generation heuristics in the reading code needs to be
-   refined. Some improvements should also be possible to obtain by
-   tuning the move ordering.
+   strange variations that shouldn't need consideration.  To improve
+   one could refine the move generation heuristics in the reading.
+   Also, one should implement some more of the standard tree search
+   optimizations used in alpha-beta readers.
 
  * Create a way to quickly assess the safety of a group.  This might
    take into account number of eyes / half eyes, moyo in corners, moyo
@@ -172,13 +158,10 @@
    group and/or weakens an opponent group and how strong/weak groups
    influence each other.
 
- * A move generator that identifies invasions or places to make
-   reducing moves (and of course threats to make invasions).
-
  * In some positions GNU Go may report a group as alive or connected
-   with a living group. But after the opponent has placed one stone
+   with a living group.  But after the opponent has placed one stone
    GNU Go may change the status to dead, without going through a
-   critical status. It would be nice if these positions could be
+   critical status.  It would be nice if these positions could be
    identified and logged for later analysis of the GNU Go team.
 
  * Automatic search for missing patterns by analysing games from