Re: [gnugo-devel] Levels and time used.

[Evan Daniel]

On Thu, 2 Sep 2004 09:24:18 +0200 (CEST), Jens Yllman <address@hidden> wrote:
> Hi,
> 
> I just have a small thought. Today GNU Go is mostly tuned for level 10.
> And that is the only level anybody realy can talk about it's strength.
> 
> On my computer running as level 10 is realy fast. And now when the talk
> about specific patterns with high values for getting out of reading more
> quickly makes me think that that aproch does not realy 'improve' GNU Go.
> Atleast not in the way of 'understanding' the game.
> 

The question of whether a computer can think is no more interesting
than the question of whether a submarine can swim.

-- Edsgar W. Dijkstra

I think that we need to be careful of anthropomorphizing the computer
too much.  Having the program understand the situation is all well and
good, and even important, but needs to be seen as a secondary goal. 
Strong go players do not derive the life and death of the tripod group
from first principles every time it comes up; neither should GNU Go. 
Increasing the level of abstraction involved is, I believe, very
important in the long run.

We've amply demonstrated that GNU Go underestands the tripod group,
and many others.  Wanting it to understand it is therefore only useful
insofar as it helps to make a stronger go program in other areas of
play.

I also think that most human go knowledge is in the form of
sophisticated pattern matching.  I find it not infrequent that on
seeing a move pointed out by a strong player, the weaker player
frequently can easily see the merits, but simply never managed to look
at the move.  My experience suggests that the use of patterns in GNU
Go is similar -- many good things can be accomplished, but there are
inherent problems to the approach.  I think on balance a strong go
program will need to use patterns for many of the same reasons a
strong human does.

> I would like us to have a better understanding about what happens with
> increased reading depth and larger cache and things like that. And realy
> make things like the automaticly adjusted level depending on time left
> work.

That I definitely agree with.  One interesting place to start would be
investigating why some regression tests FAIL on higher levels. 
Another would be trying to do something about the fact that
variability in play speed increases at higher levels much more so than
the time to play a move does.

> 
> My personal feeling is that makeing a program play good with
> patternmatching is not realy makeing a program play the game. And I would
> like GNU Go to understand more of the concepts of the game.
> 
> I've been rather absent from GNU Go lately. So I don't realy have any
> feeling about these features at the moment. So maybe I'm just stating
> something that is not relevant anymore.
> 
> Last thought about high valued patterns. If we add high valued patterns.
> It would be nice to have option to not include. I'm not that good on how
> things work internaly. But I understand this might not be easy as
> run-time. But I think that the possibility to turn of makes it possible to
> check the current state of the 'real knowledge' in GNU Go.

At least as currently implemented, it would be trivial to add a
runtime option to either ignore the high valued patterns completely or
treat them the same as any other pattern, but with a higher value (ie
no  special case).  It would be somewhat more work to match the
pattern and then compare to the reading results, but still not very
hard.

Evan Daniel