Re: [gnugo-devel] bigger TODO list

[Inge Wallin]

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

Good point.  Dan, do you add it to the TODO file?

> > 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?

I forgot another reason: memory conservation.

My idea is to use these types of bitmaps in a number of places. This
could be places like in persistent caches (to store interesting
areas), in strategic analysis (e.g. to store areas of influence), and
so on.  It would be useful if these could be handled in numbers and
not take up too much memory.  It would also be useful if they could be
handled as first class datatypes, which a struct with a bitmap could.

Maybe my motivation was not properly thought through since all the
entries in the new TODO file was from the top of my head, but I stand
by the idea.

> > 8. Support for seki in:
> >     - the tactical reader
>
> What would this mean?

You wouldn't have to ask since one of your latest patches seems to
implement this (or am I wrong)?  :-)

What it means is that it should detect that seki is a way to save a
string.  We have (at least) one example in the regressions, but I
don't have time to find it right now.

> > 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.

Not necessarily.  Sometimes the reading goes to the bottom and in
those cases it would be useful.  Especially for owl reading, since
each owl node could potentially use lots of tactical reading nodes. 

> > 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.

Yes!

        -Inge