[Computer-go] Question on 0.5-wins

steve uurtamo uurtamo at gmail.com
Tue Jun 25 09:36:15 PDT 2013


I think that maybe I see the mistake here.

What you (Stefan) seem to be thinking is:

Okay, I make an estimate about a bunch of positions. I assume that I'm not
100% correct. Some give me a huge lead, some give me a tiny lead. I should
bias those that give a huge lead just in case I'm wrong.

Here's the thing -- all of those positions are already not given equal
weight. The positions with a tiny lead almost always have a much higher
probability of being correct, in the MCTS sense. Those positions with huge
leads have lots of different pathways that can make everything go horribly
wrong, in the bot's way of thinking. Especially, perhaps, when they involve
big empty eyes. Defending a big empty eye is easy for humans. Other
situations that can make tree width explode and evaluation look not so nice
include -- multiple unsettled groups. Settling groups early is a quick path
to losing against a bot. Leaving lots of unsettled shapes whose outcome you
understand better than the bot -- that's a great way to beat a bot, because
of the exponential explosion in the tree trying to evaluate each possible
feasible outcome.

Even with smart pruning, this is an approach that should work for awhile --
the more ambiguous you can keep the game, the more work the bot has to go
to in order to get a scorable set of moves.

s.




On Tue, Jun 25, 2013 at 9:26 AM, Don Dailey <dailey.don at gmail.com> wrote:

>
>
> On Tue, Jun 25, 2013 at 12:12 PM, Stefan Kaitschick <
> stefan.kaitschick at hamburg.de> wrote:
>
>> That certainly sounds reasonable.
>> Though I still don't get why bots would frivolously fritter away the
>> final cushion.
>> Even a great bean counter should know that he can't expect his own
>> count to be perfect.
>>
>
> Bot's have no such concept,  but when this situation actually arises their
> "belief" is strong in the sense that their estimate is statistical and
> shows no advantage for the big move over the small one.    So they simply
> cannot distinguish it.
>
> And they are probably almost always correct except in those situations
> where the playouts lead to incorrect results with their simplistic rules -
> such as nakade shapes and imperfect eye definitions.
>
> Don
>
>
>
>
>
>> Then again perhaps todays bots are smarter about this, and the
>> perplexing behaviour I'm thinking about is a thing of the past. Which
>> would still leave a lack of advice for newbie-bots.
>>
>> Stefan
>>
>> On Tue, Jun 25, 2013 at 11:33 AM, Nick Wedd <nick at maproom.co.uk> wrote:
>> > On 25/06/2013 10:07, Petri Pitkanen wrote:
>> >>
>> >> Bots also fill in their own territory removing  very distant threats if
>> >> they can afford to do it. Probably saves a loss in one game out 100 or
>> so.
>> >
>> >
>> > I am not at all surprised by the phenomenon of half-point victories.
>> >
>> > One player, who can count perfectly, is trying to maximise its
>> > probability of winning. The other player, who cannot count perfectly
>> > and knows it, is trying to maximise his score. This naturally produces
>> > a half-point win or a large loss for the former.
>> >
>> > You see a similar result, unintended by either player but a natural
>> > outcome of their play, when a human 3-dan gives nine handicap stones
>> > to a human 7-kyu. If the 3d attacks a weak group, the 7k tries to make
>> > eyes for it, and is not good at telling real eyes from false eyes
>> > until it is too late. The 3d tries to stop the group from making real
>> > eyes, and is good at telling them from false eyes. The result is that
>> > the group makes a string of false eyes, without either player having
>> > any particular interest in this outcome.
>> >
>> > Nick
>> >
>> _______________________________________________
>> Computer-go mailing list
>> Computer-go at dvandva.org
>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>>
>
>
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20130625/ba65123c/attachment.html>


More information about the Computer-go mailing list