gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] bigger TODO list


From: Gunnar Farneback
Subject: Re: [gnugo-devel] bigger TODO list
Date: Tue, 27 Nov 2001 22:35:34 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Inge wrote:
> Here is the new list with all the projects I could think of.  I
> suggest that you (plural 'you' here) enter your ideas and projects so
> that the TODO file gets up to date with what is needed now.  

A revision of the TODO file was certainly overdue. I'll just make some
random comments for now.

> 1. Complete the conversion to 1-dimensional representation.
>    Also, check all comments before functions to make them agree with
>    the actual function header.  In some cases these comments were
>    missed when the function was converted to 1D.

There's a lot of 1D conversion needed in the docs as well.

> 6. The goal array used in a number of places could be recoded into
>    using bitmaps.  This would probably make it faster and less prone
>    to bugs.

In what way would bitmaps be less prone to bugs? Why would it be
faster?

> 8. Support for seki in:
>     - the tactical reader

What would this mean?

> 9. Support for ko in eyes.db and optics.c.
> 
> 10.Support for constraints in the eye patterns.
>    (Is this a good idea?)

I'm continuously thinking about these two.

> 11.The persistent caches (currently for tactical reading and owl
>    reading could store move trees taken from the analysis so that we
>    might not have to recalculate the result if we have already
>    anticipated an opponent move in the area.

I'm doubtful about this. When a move has been made in the area the old
analysis has a too low reading depth.

> 12.Create a paradigm for handling other types of ko (approach move ko,
>    multi-step ko, etc) and then write code that handles them.
>    (difficult!)

There ought to be something published on this that we could use.

> 2. A graphical pattern editor.
>    This would make it much easier for non-programmers to improve the
>    strength of GNU Go.  It could also be used as a debugging tool for
>    the programmers.  This project has the GUI as a prerequisite.

The challenge here is not to make a tool which makes it easier to
create patterns but to make it easier to overview and maintain the
database.

I would definitely be happy to see a better environment for editing
and merging changes to the joseki databases than we have available
now.

/Gunnar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]