Re: [Bug-gnubg] Suggestions for GNUbg

[Joern Thyssen]

On Sun, Oct 06, 2002 at 10:15:05PM +0200, Holger wrote
> Hi GNUbg team,
> 
> After my bug report yesterday I would like to express some wishes and
> suggestions regarding GNUbg.
> 
> The feature I most wanted is already fulfilled, you have added constant
> display of pip counts. Thanks for that.
> 
> In the game record window you show the moves of both players in the same
> order. But the points on the board are just numbered once from 1 to 24.
> Thus, black (player 1) moves from 24 to 1 and white (player 0) should play
> from 1 to 24 (but is listed from 24 to 1, too). The way you have it is
> confusing when I check the moves for white as they don't coincide with the
> board numbers.

Good point(!) :-) I'll add it to the TODO list.

> When playing against GNUbg and afterwards saving the match, could you add
> the date in the sgf-file? (If the DT-property was already present when
> GNUbg opens a file it does save it again. And it also displays it correctly
> in the match information window.)

OK, I'll look at it.

> 
> Then, it would be nice to have keyboard shortcuts for preferably all menu
> commands. I don't know if it's possible or as easy with GTK like in Windows
> just to put an ampersand in front of the shortcut letter (which will get
> underlined then).

It's quite simple. I don't think every menu command should have a short
cut, but I agree that some are missing.

> And now for the more sophisticated things:
> 
> Some weeks ago (some build of July) GNUbg had background analysis, i.e.,
> one could continue to play or browse the game record window while GNUbg was
> analyzing the match. 

This should not be possible, so if you were able to do it, there must
have been a bug in previous build.
 
> This was extremely useful. 

If you look through the gnubg mailing list archive this subject has been
discussed to great extent a few months ago. Making background analysis
requires that we make multi-threaded. The conclusion then was that this
was not a trivial task, and as far as I know, noone is working on it.

If you want background analysis you'll have to start another instance of
gnubg for the analysis. Under unix you can give the other instance lower
priority such that the instance you use interactively will respond
faster.

> What I think would be perfect goes much beyond this and is following:
> 
> In short it's: Every time GNUbg is idle (i.e. not analyzing anything,
> computing a move, a hint or whatever) it should analyze something if there
> is anything useful to do.

This was also discussed back then. Same conclusion as above.

> First thing probably while playing against GNUbg would be to
> analyze/compute the cube decision and move to be made by the user right
> after GNUbg is done with the computation of its own move. It's not
> necessary to wait until the user asks specifically for a hint and only to
> start then. Especially with high settings this might take a long time.
> The same is valid for the tutor mode. It doesn't make sense to wait until
> the user has made his move or decision. The necessary information to
> compute the move exists already.
> 
> Then, for instance in tutor mode, it would be much better to save the
> analysis for later use, 
> be it for immediate revision of a bad move (Right
> now GNUbg evaluates the same situation once again after the user decided to
> revise his move.

This is in part necesary as we may not assume that the new move has been
evaluated at the best evaluation settings. Of course it should be
possible to modify the logic such that only the move chosen is
re-evaluated.

> ) or to later save it to a file as evaluation together with
> the match data.

I think it does, but I have to check it.

> After those computations GNUbg should start (or continue) to analyze the
> (maybe imported) match if there are moves left that aren't evaluated yet.
> And also rather important: These actions should all be background threads.
> 
> I know that especially the last subject is not easy to implement. 

As before, this is not trivial, and I don't see it coming anytime soon.

> But I suppose a lot of people would be even happier.

Yes, but it would require a huge programming effort, which probably can
be used more fruitfully in other areas in gnubg...

Jørn

-- 
Joern Thyssen, PhD
Vendsysselgade 3, 3., DK-9000 Aalborg, Denmark
+45 9813 2791 (private) / +45 2818 0183 (mobile) / +45 9633 7036 (work)
Note: new mobile number!