About a year ago I tried collecting full histograms to see if I could
extract useful information from them. On small boards the histograms tend
to show multimodal distributions (killing the whole board leads to peaks
at the two extreme scores). But I could not think of a good use for this
information. I mean, how do you compare two multimodal distributions
(instead of comparing only one statistic like the mean, the winrate, the
median or the mode)? One could calculate skewness (or other moments), but
when comparing distibutions with the same mean, should one prefer
positive skewness or negative skewness?
Using the median also seemed troublesome, because its value progression
while adding playouts is not smooth. It changes in a steplike fashion:
Adding a win or loss either either has no effect on the median (most of
the time) or it lets the median jump from one value to the next
(occasionally).
I will specify slighttly more precisely a model in PS? but I won't do
much on it because I do not think we can extract anything really
interesting.
I think the only point where we might do something is that one of the
effects of playouts is probably adding some noise: bad yose play, add a
Gaussian with intermediate variance.
So that we could get better results by deconvoluting. Since the true
function with which we convolve is probably not obvious, it should also
be blind deconvolution. All the more since the function is probably not
the same on each mode...
The consequences are complicated. Let's give examples.
If I have to choose between:
150 times +100.5
50 time +.5
100 times -.5
50 times -1.5
and
175 times +10 (plus or minus one)
175 times -10
I choose the first: the +.5 should probably be a -.5.
On the other hand, between
50 times 1.5
100 times .5
50 times -.5
and
180 times +10
20 times -10
I still choose the first. Here the -.5 should be positive.
I honestly believe it's not worth the effort, since the distributions
are probably much less "clear". Just use winrate.
Jonas
PS:
The intuitive model I would come with is the following:
* Both (real) players are random. Our aim is to choose the move which
gives highest winrate.
* MC simulations simulate them by much weaker players.
The (real) final score in a given position is a sum of random variables of the
form:
score = sum_{k big local situation} p_k score_k + noise.
Here score_k is the value of winning a local fight, successfully
invading, and so on. There are only very few of them. Their combination
could give the modes of the histogram. p_k is the probability of winning the
corresponding local fight. noise is a random variable corresponding to
all the other small ways of gaining points. It includes the difference
between score_k and what will be really gained by winning situation k.
Playing a move can change the p_k as well as score_k (bad move would
probably have p_k go down, heighten the stakes by brooadening a fight
change score_k, etc.). And the noise, probably more slowly.
The score of the simulations have the same form of formula:
score_simulation = p_k^sim score_k^sim + noise^sim.
score_k^sim might generally not be a too bad estaimtion of score^k.
The whole point of **simulation balancing** is trying to have p_k^sim
close to p_k. Especially for clear semeais, but also otherwise. I
predict thtaat simulation balancing will favour moves that are bd at
killing invaders, so that invasions have survival chances closer to its
chances in reality.
noise^sim is probably much bigger than in reality. And might not be
centered. Here again simulation balancing would try to center it. Trying
to suppress noise^sim by denoisuing is the suggestion in message body.
That's the nonly thing I can come up with, since it seems impossible to
guess the biases in the other quantities.
This model does neglect completely interaction between local sitations.
I do not know if that would have much effect on the score histogram. A
possible modification would be giving several levels for each score_k
corresponding to different outcomes (kill the whole group, part of the
group, kill but give huge thickness, let live, and so on).
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
