Re: [Bug-gnubg] Suggestions for GNUbg

[Jim Segrave]

On Mon 07 Oct 2002 (07:38 +0000), Joern Thyssen wrote:
> 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.

I'd like it kept as an option. Maybe I'm perverse, but I find it
easier and it matches the way a lot of people seem to discuss games
(all moves seen from the current player's POV).

[snip]
 
> > 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.

It would be possible (but definitely not easy) to start a Tutor mode
cube evaluation after gnubg plays (and any synchronous sound) while
waiting for the player to make a double/roll decision. If they decide
before the cube analysis is done, then you simply discard the work,
but if gnubg manages to finish, then a bit of time is saved. On World
Class cube and Chequer play on an average PC 350 MHz, the delay
between choosing double or roll and Tutor mode evaluating it is maybe
3 seconds or so. I'm not convinced that saving that time would be such
an improvement as to justify the effort it would take to implement it.

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

Here's a thought. 

For Unix users, doing an analysis on a niced copy of gnubg is trivial
(in fact, I've seldom felt the need to nice it at all).

I'm not sure how pre-emptive (if at all) Windows apps are. But I
assume that there's some syscall which will allow a process to
deliberatly relinquish control. Suppose there were an option you could
select on Windows versions which would cause this call to take place
regularly. Then you could start a second copy, turn on the option and
load the match to be analysed and minimise the window(s). Would that
give the same effect?

-- 
Jim Segrave           address@hidden