Re: Using partial plys

[Jeremy Thorpe <jthorpe@xxxxxxxxxxxx>]

On Tue, 22 Dec 1998, David Mechner wrote:

> Darren Cook wrote:
> > Or could you just add a bonus to the evaluation function 
> > for the side that has sente. If so, isn't calculating 
> > the worth of sente going to be very inexact?
 
this is the only way to do it.  many josekis end rather abruptly, in a way
that makes the best continuation for either side small, or strongly sente
(which means that you shouldn't evaluate the position statically)

> Wouldn't this be relative? If you're comparing the error of the sente
> estimate to the error of the full-board static evaluation then (unless
> you've had a breakthrough) it will probably be similarly exact, i.e.
> decent in simple positions and terrible in complicated positions.
> 
> The way our program counts, which is modeled after the traditional human
> method, is that it tries to calculate the size of each "area"
> independently as the swing between black and white playing there first.
> Another refinement humans use is the heuristic of doubling the value of
> a "sente" move - one that creates a big follow-up should the opponent
> ignore it and take sente. (presumably the logic is that because it's
> sente you get the next move too, which is assumed to be worth the same
> as this one).
> 
> Given this scheme, a first approximation is to consider sente worth the
> difference between the biggest move and the next-biggest move. 

there is a simple mistake here.  shouldn't the value of sente be the
diffrence in value between the first and second, plus difference between
third and fourth, etc...?  if the value of the next moves are distributed
fairly nicely (no huge gaps), the value of sente should be about half the
biggest move (or slightly more, given certain reasonable distributions
(eg. geometrical)).  So i claim a first approximation of the value of
sente is half the next biggest play.

> This is rough, but personally I'm more disturbed that my program can't
> reliably figure out whether a 50 point group is alive, dead, or
> undecided. (but it's getting there...)
 
on this topic, i would like to try probabilistic approaches to this
question.  of course, we can prove that such a question has a
deterministic answer, but since nobody can find this answer, it may have
real meaning to compute this probability.  even if it dosen't, it would be
more useful to have a module that gives output like '75% chance alive' 
than one that says 'alive' but is wrong 25% of the time.

or--another thought: let's say you know that your stones can be killed if
you don't play, but you think that 75% of programs out there can't find
the right move.  furthermore, the game is really close (if you're alive),
and there's another huge spot to play.  in this case, 75% alive seems like
a better answer than 100% dead.  what do you think?

> -David
> 

-jeremy