Re: [gnugo-devel] 2 little things

[Arend Bayer]

On Sun, 23 Mar 2003, max-d wrote:

> > On Sun, 23 Mar 2003, max-d wrote:
> >
> > > 1...
> > > i have noticed that gnugo takes a relative large amount of time when it
> > > executes the "undo" command (vs the "play" command ).
> > > I suppose there are some good reasons for that but i wonder about them
> and i
> > > would like to be sure there is no imperfection in the *undo function*
> > > implementation since this fact makes some troubles to me.
> >
> > What means relatively large? It's certainly not considered a performance
> > relevant, but it shouldn't take ages (i.e. seconds) either.
>
> for  a 240 move game ,
> 1/looping from beginning to end  with
>  command play ,  takes 0 sec .
> 2/looping from end down to begin   with
>  command undo , takes about 10 sec
>
> it's a real problem ...

Ok, I can see that this is a problem for a responsive UI.

Apart from speeding up the undo implemenation, the most straightforward
way to solve this would be using the

gg-undo <number>

command that takes back <number> moves. (Then your UI can just update
the board while the user is scrolling, and you can have gnugo jump directly
to the current board position.) This isn't part of the GTP
specification, so it will not work with other programs.

> > > 2...
> > > it would be nice if the last stable version (3.2) could be rebuilt
> (updated)
> > > in order to allow it to understand the same gtp commands as 3.3.16
> > > i don't think this is very much work and this would be very useful in
> order
> > > to easily compare  3.3.x ad further with 3.2.
>
> > If you like, you can go the other way round by using 3.3.16 with
> > --gtp-version=1. But where did you run into incompatibilities?
>
> the problem is not not to let the 2 engines play together ; that needs only
> few command
> and i can already do that ...
> the problem is that Gnugo 3.2 does not understand commands like "gen_move" ,
> "play" etc ...
> which are needed for what i'm trying to do.

But you can always use the 3.2 equivalents ("black" instead of "play
black", "genmove_white" instead of "genmove white").

> BTW ,i observe that Gnugo 3.3.16 is by far slower than 3.2 for tactical
> situations and at low levels , then it seems to become faster/equal  at
> levels up to 8.

I bet that is because we are not adjusting connection reading depths
yet. We need to fix this before 3.4.

Arend