[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] 1-sided rollout results
From: |
Jim Segrave |
Subject: |
Re: [Bug-gnubg] 1-sided rollout results |
Date: |
Mon, 21 Jul 2003 20:51:40 +0200 |
User-agent: |
Mutt/1.2.5.1i |
On Mon 21 Jul 2003 (16:59 +0000), Joern Thyssen wrote:
> On Mon, Jul 21, 2003 at 12:12:10PM -0300, Albert Silver wrote
> > When I do a rollout of a doubling decision in an analyzed game, it only
> > adds the results to one side. For example, if I click on the 'Double' of
> > one side and do a rollout, it will update the results accordingly, but
> > if I then click on the take/drop of the other player, it continues to
> > display the previous 2-ply evaluation. Worse: it also shows the rollout
> > results in the statistics for the first player and the 2-ply for the
> > take/drop decision for the second player. This problem is also true for
> > any multi-ply analysis of cube decisions.
>
> 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;
I'm willing to have a go at breaking new things^W^W^Wadding this
feature once I've finished working on the rollout stuff in gnubg.texi.
--
Jim Segrave address@hidden