Re: [Bug-gnubg] 1-sided rollout results

[Joern Thyssen]

On Mon, Jul 21, 2003 at 08:51:40PM +0200, Jim Segrave wrote

> > This is a known old problem never fixed. 
> > 
> > gnubg stores the double decision and take decision as a separate moves,
> > so you can individually evaluate both. I'm not sure what the best
> > solution is: (a) ensure that updates to one evaluation is propagated to
> > the other, or (b) only store the evaluation for the double decision, and
> > change the GUI/export so it uses the numbers for the double decision for
> > the take decision. Or a third solution?
> > 
> > Since nobody is working on this, I suggest you create a bug report at
> > <URL:http://savannah.gnu.org/bugs/?func=addbug&group=gnubg>.
> 
> Would it be that hard to change the movedouble member of a moverecord
> union to be a pointer to struct with these items in it? Then we could
> duplicate the pointer in the double/take (although you'd need to
> change arDouble to have two rows). Obvious problems are ensuring it's
> freed when need be = reference counts would be the simplest way. Then
> the contents would always be the most recent analysis of either side
> of a cube decision. I think the actual number of places needing
> changing would not be unreasonable.
> 
> typedef struct _cubecommon {   
>     float aarOutput[ 2 ][NUM_ROLLOUT_OUTPUTS ];
>     float aarStdDev[ 2 ][ NUM_ROLLOUT_OUTPUTS ];
>     float arDouble[2][ 4 ];
>     evalsetup esDouble;
>     skilltype st[2]
>     int refcount;
> } cubecommon;

Your solution is basically identical to my solution (b), but rather than
changing the GUI to use the numbers for the double decision in the take
decision, you have to deal with this when loading and analysing matches
-- probably better since it's only two places and it's independent of
whether you use the text cli or gtk gui.

Jørn