bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Bug-gnubg] Even, odd and half plies (WAS: New Contact Net Error Rat


From: Nis
Subject: RE: [Bug-gnubg] Even, odd and half plies (WAS: New Contact Net Error Rates)
Date: Fri, 28 Feb 2003 20:09:04 +0100



--On Friday, February 28, 2003 09:57 -0800 David Montgomery <address@hidden> wrote:

> 2A) Do a weighted average of 432 2-ply nodes selected by striated
>     sampling with the result of a full 1-ply evaluation, using
>     empirically derived weights.

With 2A, both the 2-ply and the 1-ply evaluations, considered separately,
are attempts to estimate the overall equity of the position, so it's
reasonable to combine them willy-nilly.

2B) Do a weighted average of the 432 2-ply nodes resulting from 12 of
    the initial rolls and the 1-ply evaluations of the 24 other
    rolls (each with weight 36)

With 2B only one weighting seems reasonable to me.

Good point!

As an example, take the situation where I will win, unless I roll 2-1 and
opponent rolls 6-6:

In this case, if all our evaluations are exact, we will have
1-ply = 2-ply = 1294/1296
while 2A) gives either 1292/1296 or 1295/1296 depending on whether the
winning sequence is included in the 432 evaluated on 2-ply.

Good example.  2A results in overweighting the selected 2-ply
continuations, and this is bad.

My intuition is still that 2A would perform better than 2B.  I feel
that it is beneficial to have the most accurate evaluations spread
across the range of variations.

I agree that this is beneficial - the question being which is more important, having them spread across the tree, or having all branches equally represented

I hope the issue can be decided empirically.  It shouldn't be too
hard.  2B is actually easier to implement than 2A, because the
rolls are partitioned at the root level.  (Well, for 2-ply, anyway;
maybe not for the generalization to N-ply.)

I would think that 2A is much easier to implement, since we already have the code for getting the 2 numbers we want to average.

I am wondering if anyone would object to having the "reduced evaluation" setting "taken over" by 2 (A or B) - since it seem very few people are using the current implementation anyway (it is not part of any of the standard settings - I guess it would be if people here found it to be useful).

This would mean that I could probably implement 2A in about an hour (not counting bug-fixing, to be done by someone who knows C).

--
Nis Jorgensen
Greenpeace
Amsterdam




reply via email to

[Prev in Thread] Current Thread [Next in Thread]