Re: [Bug-gnubg] luck analysis suggestion

[Joern Thyssen]

On Mon, Dec 09, 2002 at 11:41:58AM +0000, O.M. Riordan wrote
> 
> > Should be fixed now.
> > 
> > I've added a new set of commands: "set analysis luckanalysis ..." that
> > can be used to specify the evaluation parameters for the luck analysis.
> > 
> > For example,
> > 
> > set analysis luckanalysis plies 2
> > set analysis luckanalisys cubeful on
> > 
> > The default settings is cubeful 0-ply.
> > 
> > Jørn
> > 
> 
> Thanks; but one thing is not quite right. Also there are some bugs that I
> hadn't noticed earlier.
> 
> what is not quite right is that the move selection should be at the same
> ply as the analysis of the resulting position. Presumably they could be
> done together - at $n$-ply a sensible sequence is, for each roll, do
> something like: `decide on a move in the same way as if I was going to
> play at $n$-ply, then return equity of that move at $n$-ply'. (The equity
> would normally have been calculated while deciding the move, unless one
> move was obviously best. Here $n$-ply equity is needed even if there is
> only one legal move, or no legal moves.)

I'm not sure that I agree that the move selection should be done at the
same level as the final evaluation. First, it would make the luck
analysis much slower, and, second, I don't see why it's necesary.

Perhaps I'm overlooking something!

> Bugs: 
> 
> (a) the results for the first move (of a match/game within a match) are
> nonsense
> e.g., -24% for opening 32 for second player

I've fixed this.

> 
> (b) the numbers don't add up right in MWC, being generally off by a factor
> of 2:
> e.g., in the attached file, move 11 (JF rolls 26), MWC for jellyfish
> before roll 32.6% (from 1-ply of previous move), after roll 63.5% (0-ply
> of current move), but 0-ply luck estimate only 15.45% (should be 30.9%).

You forgot to attach the file!

Remember that this is under the assumption that JF actually selects the
best move (according to the 0-ply move selection).

I did a few trials, and the fix above seems to fix this as well.

> (I'm guessing, but is it perhaps the case that in a match the
>  -ar[OUTPUT(_CUBEFUL)_EQUITY] should be 1- ? This doesn't explain the
> second though.)

Yup! 

Jørn