Re: [Bug-gnubg] incorrect analysis resignation ?

[Jim Segrave]

On Wed 17 Sep 2003 (18:42 +1200), Joseph Heled wrote:
> Hi,
> 
> Look at the end. The analysis says the resignation is doubtful.
> Is this another incarnation of the resignation bug, or a new one?

It looks to me like a limitation in the structure of game
records. White has played and then resigned with no intervening play
by black. The end of the game when the .sgf file is loaded is:

MOVE_NORMAL    ------> MOVE_RESIGN
white                  white
41 3/1 3/off

The game list should realise that the resign was by white, since the
moverecord had the correct player identified, but it still puts it as
a move by black.

One solution would be to create a MOVE_NULL type record whose only
purpose is to ensure that there is a strict alternation in plays. It
would be easy to introduce, since the only place it can happen is a
resignation. 

The main problems are:
moverecords don't indicate what player made the move in the common
part of the struct, it's in the individual union members. The code
would be much cleaner if it didn't need to find the player based on
the record type. We'd also need to have a value to indicate that the
moverecord does not have a meaningful player (MOVE_GAMEINFO,
MOVE_SETBOARD, etc.) In this case we don't need to insert MOVE_NULLS.

Places affected:

play.c - before inserting a MOVE_RESIGN, check that the current last
move is assigned either to the other player or is marked as
not-meaningful. If not, insert a MOVE_NULL belonging to the other
player.

ComamandNext should skip forward over MOVE_NULLs
CommandPrevious should skip backward over MOVE_NULLs
Attempts to select a MOVE_NULL in the game list should always skip
forward.

sgf.c would need the same logic as play.c for inserting MOVE_RESIGNS

AnalyseMatch/AnalyseGame should take no action for a MOVE_NULL

And of course everywhere moverecords are created, the player
indication would need to be set or moved from the current location to
the common part of the struct.

-- 
Jim Segrave           address@hidden