[Top][All Lists]
[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