Dave wrote:
> We have seen a similar effect many times in MoGo. Often we try
> something that seems like it should improve the quality of the
> simulation player, but it makes the overall performance worse. It is
> frustrating and surprising! Has anyone else encountered this?

I'm not surprised. The goal of Monte Carlo simulations should be to
provide an unbiased estimate of the true min-max value with as low
variance as possible. This has little to do with strength, unless you
happen to find a perfect simulation player, but then the whole search
business becomes moot.

The fact that many modifications of uniformly random playouts
simultaneously improve simulation playing strength and overall strength
is a red herring. Uniformly random playouts are strongly biased to
overestimate the value of having tightly connected stones since e.g. one
space jumps become cut through disproportionally often compared to what
happens in relevant paths through the min-max tree. Almost any change in
simulation policy that counters this tendency will improve overall
strength and likewise pretty much every sensible change will improve
simulation strength compared to uniformly random play.

At higher levels something that may happen is that a change in the
simulation policy improves the skill at making life in tight spots,
without changing other skills. This would likely improve simulation
strength but would cause a bias for positions where there's room for a
futile invasion that barely fails, decreasing overall strength.

Similar phenomena have turned up in GNU Go over the years. If you tune
tactical reading or life and death reading to find some new class of
attacking moves, results are likely to become worse if you don't do
matching changes in the capability to find defense moves.

There's also the classical effect of fixing an obvious mistake just to
find some regression tests starting to fail. Closer examination shows
that the tests were previously only passing because there were two
mistakes that cancelled each other and fixing one of them breaks the
balance.

/Gunnar
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Reply via email to