Re: [Computer-go] Project Leela Zero

[Stefan Kaitschick]

Is this something LeelaZero might consider using?
https://arxiv.org/pdf/1803.05407.pdf
The last diagram is looking very impressive. It's not a game playing
domain, but still.
Maybe this averaging technique could help reduce the gap for a (relatively)
low resource project like Leela.


On Wed, Jan 10, 2018 at 12:28 AM, uurtamo .  wrote:

> 4dan?
>
> On Jan 9, 2018 3:26 PM, "mic"  wrote:
>
>> Thank you very much.
>>
>> It will play on DGS as LeelaZero19 (without GPU support). I will start
>> this night with an unrated test game against FuegoBot, one minute thinking
>> time each. Then I will give it a rank, so it can get stronger by the time.
>>
>> Leela 0.11.0 (on DGS as LeelaBot19) has meanwhile reached a weak 4 dan
>> rank, also without GPU support.
>>
>> -Michael.
>>
>> ---
>> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
>> https://www.avast.com/antivirus
>>
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>
>
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Breakthrough: FineArt giving handicap against pro players

[Stefan Kaitschick]

Ke Jie sacrificed himself to help the Nihon Kiin get off its high horse. :-)

Congrats on your own results.
>
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Patterns and bad shape

[Stefan Kaitschick]

On Mon, Apr 17, 2017 at 3:04 PM, David Wu  wrote:

> To some degree this maybe means Leela is insufficiently explorative in
> cases like this, but still, why does the policy net not put H5 more than
> 1.03%. After all, it's vastly more likely than 1% that that a good player
> will see the ladder works here and try escaping in this position.



I think it's likely that the ladder is actually the first thing that Leela
considered. My guess is that it put a penalty on the move after misreading
the ladder.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] AlphaGo rollout nakade patterns?

[Stefan Kaitschick]

Finally, somebody asks about the nature of those 8192 patterns.(pardon the
Nature pun)
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] it's alphago

[Stefan Kaitschick]

> Honestly I got a little frustrated that many people didn't think that
> was AlphaGo. It was almost clear to me because I know the difficulty of
> developing AlphaGo-like bots.
>


 I feel with you. People seem to think that the Nature paper gave away the
full recipe.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Chun-Hsun Chou 9p vs Yi-Min Hsieh 6p and DarkForest on ICIRA 2016 Tokyo

[Stefan Kaitschick]

It's hard to tell, because bots don't really play outrageous moves anymore,
especially not it good positions.
My guess would be the shoulderhit at 41.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

[Computer-go] Scoring Network

[Stefan Kaitschick]

Has anyone ever tried to build a value network that is trained on finished
positions?
I admit that would be less awesome than what AlphaGo's value network has
achieved.
But reducing the task to status and scoring might help in endgame play.
Generalizing this, there could be several value networks, each specialized
on a different stage of the game.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Creating the playout NN

[Stefan Kaitschick]

>
> The purpose is to see if there is some sort of "simplification" available
> to the emerged complex functions encoded in the weights. It is a typical
> reductionist strategy, especially where there is an attempt to converge on
> human conceptualization.
>
>
That's an interesting way to look at it. If you do this with several
different smaller NN of varying complexity, and see how good they are, you
would get some kind of numeric estimate of the complexity of the encoded
concepts. Of course. there is the slight problem, that we also would need
to map those "simple" NN to concepts somehow.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Creating the playout NN

[Stefan Kaitschick]

>
> BTW, by improvement, I don't mean higher Go playing skill...I mean
> appearing close to the same level of Go playing skill _per_ _move_ with far
> less computational cost. It's the total game outcomes that will fall.
>
>
 For the playouts, you always need a relatively inexpensive computation.
Because for every invocation of the main NN in the tree, you need several
hundred cheaper calls in the playout.
So it will have to be orders of magnitude faster. Surely, replacing a crude
fast NN with a slightly less crude fast NN would be beneficial.
I don't know if other bots besides AlphaGo are already utilizing the
selfplay improvement. But when they do, it will be helpful there too.
Because the added knowledge of the main NN can be transferred down to the
playout NN.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Creating the playout NN

[Stefan Kaitschick]

I don't know how the added training compares to direct training of the
shallow network.
It's prob. not so important, because both should be much faster than the
training of the deep NN.
Accuracy should be slightly improved.

Together, that might not justify the effort. But I think the fact that you
can create the mimicking NN, after the deep NN has been refined with self
play, is important.

On Sun, Jun 12, 2016 at 9:51 AM, Petri Pitkanen <petri.t.pitka...@gmail.com>
wrote:

> Would the expected improvement be reduced training time or improved
> accuracy?
>
>
> 2016-06-11 23:06 GMT+03:00 Stefan Kaitschick <stefan.kaitsch...@hamburg.de
> >:
>
>> If I understood it right, the playout NN in AlphaGo was created by using
>> the same training set as the one used for the large NN that is used in the
>> tree. There would be an alternative though. I don't know if this is the
>> best source, but here is one example: https://arxiv.org/pdf/1312.6184.pdf
>> The idea is to teach a shallow NN to mimic the outputs of a deeper net.
>> For one thing, this seems to give better results than direct training on
>> the same set. But also, more importantly, this could be done after the
>> large NN has been improved with selfplay.
>> And after that, the selfplay could be restarted with the new playout NN.
>> So it seems to me, there is real room for improvement here.
>>
>> Stefan
>>
>> ___
>> Computer-go mailing list
>> Computer-go@computer-go.org
>> http://computer-go.org/mailman/listinfo/computer-go
>>
>
>
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

[Computer-go] Creating the playout NN

[Stefan Kaitschick]

If I understood it right, the playout NN in AlphaGo was created by using
the same training set as the one used for the large NN that is used in the
tree. There would be an alternative though. I don't know if this is the
best source, but here is one example: https://arxiv.org/pdf/1312.6184.pdf
The idea is to teach a shallow NN to mimic the outputs of a deeper net. For
one thing, this seems to give better results than direct training on the
same set. But also, more importantly, this could be done after the large NN
has been improved with selfplay.
And after that, the selfplay could be restarted with the new playout NN.
So it seems to me, there is real room for improvement here.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] new challenge for Go programmers

[Stefan Kaitschick]

Your lack of respect for task performance is misguided imo. Your
preconceived notions of what intelligence is, will lead you astray.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search (value network)

[Stefan Kaitschick]

The evaluation is always at least as deep as leaves of the tree.
Still, you're right that the earlier in the game, the bigger the inherent
uncertainty.
One thing I don't understand: if the network does a thumbs up or down,
instead of answering with a probability,
what is the use of MSE? Why not just prediction rate?

On Thu, Feb 4, 2016 at 8:34 PM, Álvaro Begué  wrote:

> I am not sure how exactly they define MSE. If you look at the plot in
> figure 2b, the MSE at the very beginning of the game (where you can't
> possibly know anything about the result) is 0.50. That suggests it's
> something else than your [very sensible] interpretation.
>
> Álvaro.
>
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Mastering the Game of Go with Deep Neural Networks and Tree Search

[Stefan Kaitschick]

I always thought the same. But I don't think they tackled the decomposition
problem directly.
Achieving good(non-terminal) board evaluations must have reduced the
problem.
If you don't do full playouts, you get much less thrashing between
independent problems.
It also implies a useful static L evaluation.
That "value network" is just amazing to me.
It does what computer go failed at for over 20 years, and what MCTS was
designed to sidestep.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Number of Go positions computed at last

[Stefan Kaitschick]

Good joke to render the solution as a board position.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] NHK News "Bots will be admitted to pro tournaments"

[Stefan Kaitschick]

According to a post in this forum it's 13*13.

http://lifein19x19.com/forum/viewtopic.php?f=18=12553
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Facebook Go AI

[Stefan Kaitschick]

> I understand the idea, that long term prediction might lead to a
> different optimum (but it should not lead to one with a higher one
> step prediction rate: it might result in a stronger player with the
> same prediction rate...), and might increase training speed, but hard
> facts would be great before spending a GPU month into this :)
>
>
>
> Detlef
>

I wouldn't be too sure, that this cannot improve the 1 step prediction rate.
In a way, multi-step prediction is like peeking around the corner. :-)

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Komi 6.5/7.5

[Stefan Kaitschick]

I agree with Robert. 7 is still a hot candidate for all board sizes.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] AMAF/RAVE + heavy playouts - is it save?

[Stefan Kaitschick]

The name "Monte Carlo" strongly seems to suggest, that randomness it at the
core of the method. And randomness does play a role.
But what really happend in the shift to MC, was that bots didn't try to
evaluate intermediate positions anymore. Instead, all game knowledge was
put into selecting candidate moves. It turns out, that, for bots, it's much
easier to suggest promising moves, than to say who is ahead in an ongoing
game.
The tree of possible go games is so vast, that trying to explore it with
pure randomness fails. Even with statistical feedback. It's already a minor
miracle, that it works as well as it does with good move generators.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] CGF Open 2015 result

[Stefan Kaitschick]

A thought about that impressive article:
Move prediction has become the bot workhorse. But I have a question: how
can those predictions work, without having a goal? The predictions are
obviously purely shape based, so a 41% success rate is really pretty
awesome. But that means that some positions, like running battles, the
percentages will be a lot better than in others, like non eye-stealing eye
filling. How about giving the learning algorithms a "hint" about the
solution? Not about the area, but the type of move. So when, for example,
in the tree, certain stones end up captured a lot, a different move
predictor, that prefers taking libs, filling eyes ect might try to avoid
that fate. I know this is pure handwaving, but some kind of feedback from
search results to predictor used seems needed.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] codecentric Challenge 2015, Round 2

[Stefan Kaitschick]

What Semeai is that? Do you mean the useless attack on the b center group?
It looked to me simply like an aimless long endgame by Zen.
But I would be interested to know, what Zen's specific problem was.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] KGS bot tournaments - what are your opinions?

[Stefan Kaitschick]

On Wed, Oct 7, 2015 at 7:21 PM, Dave Dyer  wrote:

>
> How about handicapping the hardware based on time.  Programs running
> on more powerful hardware would get less time.
>
>
 I think that's a good idea. Programs could even aquire a time ranking,
depending on their success in previous tournaments.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] KGS bot tournaments - what are your opinions?

[Stefan Kaitschick]

>
> 1. I do not see a way to do this but running on same hardware (e.g.
> Amazon EC2 with graphic card). Even this is unfair, as programs might
> be optimized to other configurations (cluster)
>
>
 First, there is the question is fairness is even desirable.
But also, as you say, it is really impossible to make an event "fair", even
with identical hardware, because this will give the reverse advantage to
programs that put a premium on resource conservation in their design. And
with the new CNN developments, it would be a shame to put resource limits
to the top of the agenda.

As a Kibitz, I would have an added trivial wish: force a minimum time
consumption on the first moves of 9*9 games. It's annoying as a spectator
to have the first 8 moves or so just spit out on the board, forcing you to
go back to see what happened there. It would also slightly lessen the
advantage of bots with books.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] re comments on Life and Death

[Stefan Kaitschick]

Robert, David Fotland has paid his dues on "truly intelligent" go programs.
Maybe more than anybody else.
I find your critique a little painful. Don't blame David, that the "stupid"
monte carlo works so much better.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] what do you (or does your computer) see?

[Stefan Kaitschick]

When I click on a youtube video, I don't expect much. But I do expect to be
at least marginally entertained.
One more video of this "quality", and you will have lost me as a potential
viewer.

On Fri, Sep 4, 2015 at 5:31 AM, djhbrown .  wrote:

>
>
> https://www.youtube.com/watch?v=IoO7Nhlf_k4=PL4y5WtsvtduqNW0AKlSsOdea3Hl1X_v-S=10
>
> Please reply by posting a comment on YouTube
>
>
>
>
>
>
>
>
> ___
> Computer-go mailing list
> Computer-go@computer-go.org
> http://computer-go.org/mailman/listinfo/computer-go
>
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Dynamic komi - VBSC

[Stefan Kaitschick]

The best contenders may be best for entirely different reasons. How do you
compare a line that tries to bring down a huge group with a line that
cautiously tries to optimize safe points. It's really hard to do. And
whereever the dynamic komi lands, pedestrian variations may look great or
totally uninteresting. The idea of dynamic komi is to give enterprising
variations short of kamikaze a chance of prevailing in poor positions, and
humdrum variations better than passing a chance in comfortable positions.
So what you need is some estimate of the overall state of the game, and
averaging out from all variations seems like a sensible way to do this.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] re comments on Life and Death

[Stefan Kaitschick]

So far I have not criticised but asked questions. I am a great fan of the
expert system approach because a) I have studied go knowledge a lot and
see, in principle, light at the end of the tunnel, b) I think that "MC +
expert system" or "only expert system" can be better than MC if the expert
system is well designed, c) an expert system can, in principle, provide
more meaningful insight for us human duffers than an MC because the expert
system can express itself in terms of reasoning. (Disclaimer: There is a
good chance that I will criticise anybody presenting his definitions for
use in an expert system. But who does not dare to be criticised does not
learn!)

MC is currently stagnating, so looking at new (or old discarded) approaches
has become more attractive again.
But I don't think that a "classic" rules based system will be of much use
from here. It is just too far removed from MC concepts to be productively
integrated into an MC system. And no matter what, MC has to be the starting
point, because it is so much more effective than anything else that has
been tried.What you are left to work with, is the trail of statistics that
MC leaves behind. That is the only tunnel with a possible end to it that I
see. And who knows, maybe someone will find statistical properties that can
be usefully mapped back to human concepts of go.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Programme NAO to play Go and talk about it

[Stefan Kaitschick]

The quantum leap in go computing was to discard all structures, to plan
nothing, to evaluate nothing except final score. That has it's own limits -
programmers wish they could get some separation of concerns implemented.
But we're talking about going from beating pros with 4 stones to beating
them with 3 - that's lamenting at a very high level.
Plans, evaluation functions, ect failed for over 20 years to produce true
(amateur) dan level programs. Also, you cannot give reasons for moves
"after the fact" if reason wasn't used to obtain the selected move in the
first place.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] OT (maybe): Arimaa bot notably stronger

[Stefan Kaitschick]

The funny thing is, that in computer go there are no goals, except winning.
And therefore, the reason for a win cannot be determined.
One crude measure might be to use stronger attacking moves in the
playouts, when the winrate is low.

unrelated:
Does anyone know if the successful Arimaa bot responds to the gold setup
when it's silver, or if it just ignores how gold deployed?
Just wondering.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Arimaa bot notably stronger

[Stefan Kaitschick]

 On
 http://arimaa.com/arimaa/challenge/2015/showGames.cgi
 the games can be replayed.

 That's nice. Arimaa looks like a rather tedious game to actually play
 though.

I have never played it, but the idea seems to be to take the opponents
camel hostage at a sinkhole, and then go bossing around with your own camel
while the opponents elephant is occupied.(ok, that's at the level of a 30k
telling you how smart a ponnuki is)


 So, this is the second game (after Havannah) where programmers
 caught prize money for beating a strong/the strongest human player.
 Probably, game inventors will understand better now how risky such
 challenges are.


 It wasn't a million dollar challenge. Given the programming effort, 12k$
is not a huge amount of money.
I think this prize was offered with the idea of paying it out.





 PS. Perhaps, some tricks of bot_sharp may be applied to bots
 in Connect6.


It's probably pretty confined to Arimaa. The whole game was designed to
confound bot tree search with the huge number of possible moves.
So it stands to reason, that good forward pruning is the key to the kingdom
here.

Funny, how the really powerful techniques are so often disappointing, when
you look behind the curtain.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go

[Stefan Kaitschick]

 But, I imagine this is more fuss than it is worth; the NN will be
 integrated into MCTS search, and I think the strong programs already
 have ways to generate ko threat candidates.

 Darren


Do they? What would look like? Playing 2 moves in a row for the same side?
I thought the programs naively discovered ko threats.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Move Evaluation in Go Using Deep Convolutional Neural Networks

[Stefan Kaitschick]

 Let's be pragmatic - humans heavily use the information about the last
 move too.  If they take a while, they don't need to know the last move
 of the opponent when reviewing a position, but when reading a tactical
 sequence the previous move in the sequence is essential piece of
 information.

 --
 Petr Baudis


So maybe there is a greater justification for using last move info in the
playout than in the tree?

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Evaluation function through Deep Convolutional Neural Networks

[Stefan Kaitschick]

To me, that's the core lesson of MCTS - take your hands off that evaluation
button.

On Sat, Jan 10, 2015 at 12:00 AM, Darren Cook dar...@dcook.org wrote:

  The discussion on move evaluation via CNNs got me wondering: has anyone
  tried to make an evaluation function with CNNs ?

 My first thought was a human can find good moves with a glance at a
 board position, but even the best pros need to both count and use search
 to work out the score. So NNs good for move candidate generation, MCTS
 good for scoring?

 Darren



___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Move Evaluation in Go Using Deep Convolutional Neural Networks

[Stefan Kaitschick]

Last move info is a strange beast, isn't it? I mean, except for ko
captures, it doesn't really add information to the position. The correct
prediction rate is such an obvious metric, but maybe prediction shouldn't
be improved at any price. To a certain degree, last move info is a kind of
self-delusion. A predictor that does well without it should be a lot more
robust, even if the percentages are poorer.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Move Evaluation in Go Using Deep Convolutional Neural Networks

[Stefan Kaitschick]

Great work. Looks like the age of nn is here.
How does this compare in computation time to a heavy MC move generator?

One very minor quibble, I feel like a nag for even mentioning it:  You write
The most frequently cited reason for the difficulty of Go, compared to
games such as Chess, Scrabble
or Shogi, is the difficulty of constructing an evaluation function that can
differentiate good moves
from bad in a given position.

If MC has shown anything, it's that computationally, it's much easier to
suggest a good move, than to evaluate the position.
This is still true with your paper, it's just that the move suggestion has
become even better.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go

[Stefan Kaitschick]

That's pretty good looking for a pure predictor. Considering it has no
specific knowledge about semeais, ladders, or ko threat situations...
Switching out the pattern matcher (not the whole move generator) in an
existing mc program, should be pretty straightforward. Even if the nn is a
lot slower than the orig. pattern matcher, it could still make sense high
up in the tree.
If this does prove fruitful, the question of what transforms of the raw
position should be fed to the nn could be the next big thing. After the
almost annoying success of general purpose mc, this would be a more poetic
line of research.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go

[Stefan Kaitschick]

A move generator, that always plays it's first choice, that can win games
against Fuego?
That smells like a possible game changer.(pardon the pun).
Surely, programmers will take this workhorse, and put it before the MC cart.

Stefan
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [Computer-go] Teaching Deep Convolutional Neural Networks to Play Go

[Stefan Kaitschick]

 Finally, I am not a fan of NN in the MCTS architecture. The NN
 architecture imposes a high CPU burden (e.g., compared to decision trees),
 and this study didn't produce such a breakthrough in accuracy that I would
 give away performance.


  Is it really such a burden? Supporting the move generator with the NN
result high up in the decision tree can't be that expensive.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go

Re: [computer-go] Re: Open source real time Go server

[Stefan Kaitschick]

As for other things we'd like to see improved, we could build a list. My pet 
peeve is the KGS score estimator, which is often wildly wrong. I've heard 
complaints about the implementation of the rules, and some have argued that 
it is not terribly bot-friendly.

A good SE is a terribly difficult problem. It more or less amounts to creating 
a good evaluation function.
As the long pre-MC misery has shown, a good evaluation function is very hard to 
come by.
MC in a nutshell is really avoid evaluation.
If resources were no problem, the best way to estimate the score would probably 
be to have an MC program find the komi that results in a 50% winrate.

Stefan


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

Re: [computer-go] Re: Open source real time Go server

[Stefan Kaitschick]

2010/1/19 terry mcintyre terrymcint...@yahoo.com:
( I recall a pro making
such an observation; I was willing to accept his expertise on the 
matter. )


Any pro making such a comment at move 10 is just grand-standing. I
have experienced pros making such comments too. You can let such a
remark pass out of politeness of course, but accepting it because of
his presumed expertise is extremely naive IMO. I would even be
suspicious of pros making such comments at move 150.

Mark


If a pro predicts a half-point win early in the game, that is obviously bs.
But maybe we are just taking his words too literally.
I think it's actually a bigger problem at move 150.
Because at that point he is making a (very shaky) claim to truth.
I just hate the Go-World commentaries where the narrative has one side 
making 3 catastrophic mistakes

and the other side coasting to an unshakable 1.5 point win.

Stefan 


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

Re: [computer-go] 13x13 human vs computer

[Stefan Kaitschick]

9*9: 6 dan
19*19 :1 kyu
13*13   1 dan?

not the expected interpolation :-)
Looks like programing for a specific board size is important.

Stefan

- Original Message - 
From: David Fotland fotl...@smart-games.com

To: 'computer-go' computer-go@computer-go.org
Sent: Monday, January 11, 2010 2:23 AM
Subject: RE: [computer-go] 13x13 human vs computer


On 13x13, Many Faces is probably 1 Dan on KGS.  I don't know how that
translates to German ranks, but probably 2 stones is fair, or 3 stones if
you want the computer to likely win.

David


-Original Message-
From: computer-go-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of Ingo Althöfer
Sent: Sunday, January 10, 2010 11:17 AM
To: computer-go@computer-go.org
Subject: [computer-go] 13x13 human vs computer

Hello,
at a public event (during an exhibition on Claude
Shannon; in Nixdorf museum in Paderborn) I want to
arrange an exhibition game human vs computer go on
13x13 board. (Thinking time about 45 minutes for both
sides.)

Does someone here know about human vs computer games
on 13x13?

The human opponents will be around 3-dan or 2-dan (German
amateur level). What would be an appropriate handicap when
they play against, for instance, Many Faces of Go on a
standard dual core notebook?

Ingo.

--
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/


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


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

Re: [computer-go] Zen beats a 5-dan on KGS

[Stefan Kaitschick]

Very nice. You just can't be cavalier tactically when you play a bot.
Even though this was an even game, the human started playing handicap 
style after a few obviously weak bot moves.
But the kind of tactical handicap play that w tried completely backfired 
against Zens strong tactical counterattacks.
Before this, Zen won against 2-dans on even, and even won a game against a 
shodan, giving 3 stones.

So it's not a fluke.
Beating a 5-dan on even isn't Zens real current strength, but as we see, if 
the opponent is not used to bot play, it can allready happen.

Congrats Zen.

Stefan

- Original Message - 
From: Ingo Althöfer 3-hirn-ver...@gmx.de

To: computer-go@computer-go.org
Sent: Saturday, January 02, 2010 1:30 PM
Subject: [computer-go] Zen beats a 5-dan on KGS



The old year 2009 ended with a true cracker onm KGS:
In the computer room  Mosa, a Japanese player with
rank 5-dan, had five games with Zen running on a
mini-cluster (4x4 cernels).
One of these games was won by Zen, at chinese rules,
komi 7.5 and handicap 0.  Zen was black in that game.
Thinking time was 30 minutes sudden death.

You can download all five games from here:
http://www.gokgs.com/gameArchives.jsp?user=mosayear=2009month=12

Mosas rating curve on KGS is shown here:
http://www.gokgs.com/graphPage.jsp?user=mosa

Best wishes for 2010 to all of you!

Ingo.


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

[computer-go] one more look at the scoring function

[Stefan Kaitschick]

Looking at the games on kgs, both ManyFaces and Zen are pretty decent at giving 
handicap, but still fairly weak at taking handicap.
I think the problem remains, that they allow the opponent to close the gap too 
easily. Once the game is close they get much stronger,
but by then they are in a real danger of losing. I feel the problem is still 
with the scoring function. Watching them give away points with
both hands, I have advocated a dynamic negative komi, thereby almost starting a 
flamewar on this list. So as not to start it again, let me state here that I 
now think that it's a remedy of dubious value, making the bots play more 
positive moves that look better, but might hurt the bots chances of winning 
by going head to head with a stronger opponent.
Here's my new suggestion: how about trying to map the score to the chances of 
winning?
In the later endgame, a putative 0.5 point win might be something like 90%, a 
putative 1.5 point win 95%.
Early in the game that would be maybe 51% and 53%.
I'm not sure of what the most useful numbers would be ofcourse, or how quickly 
they would change, or if there should be other factors than the move number.

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

Re: [computer-go] problem which current programs have difficulty solving

[Stefan Kaitschick]

I wouldn't consider not solving this pathological.
I think it's a pretty difficult problem.
Without a problem warning most amateur players would miss it too.
You can't force life and you can't force connection. The either-or is easy to 
miss.

Stefan 

  - Original Message - 
  From: terry mcintyre 
  To: computer go 
  Sent: Sunday, December 20, 2009 7:03 PM
  Subject: [computer-go] problem which current programs have difficulty solving


  This gem is from one of Yilun Yang's little pocket-sized books - I think it 
is called Recovery And Connections. 

  Neither Gnugo, Fuego, nor Many Faces of Go is able to solve it. Fuego came 
closest, recognizing the best black move, but a few moves later, it lost 
interest and played elsewhere. GnuGo rejects the winning move as unsafe.

  Btw, GoGui/Gnugo have a method to find dragon status; is there something 
comparable with Fuego/GoGui?


  Terry McIntyre terrymcint...@yahoo.com


  “Politics should be limited in scope to war, protection of property, and the 
occasional precautionary beheading of a member of the ruling class.” P.J. 
O'Rourke






--


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

Re: [computer-go] KCC won the 3rd UEC Cup

[Stefan Kaitschick]

I guess your right.
It's just that the innocent side losing on the spot rubs it in.
Accepting any move surely has to be a bot vs.bot mode.
Against a human opponent the bot can't very well accept suicide or immediate 
ko takeback.


Stefan

- Original Message - 
From: Mark Boon tesujisoftw...@gmail.com

To: computer-go computer-go@computer-go.org
Sent: Monday, November 30, 2009 9:26 PM
Subject: Re: [computer-go] KCC won the 3rd UEC Cup


Well, I suppose this is a lesson that every computer-Go programmer
learns one day or another: always have a way to accept any move, no
matter whether your bot thinks it's legal or not.

I don't see how this is an indictment, the rules are what they are.
For every player. It's not as if this was a little-known issue with
Japanese rules.

Mark


On Sun, Nov 29, 2009 at 10:57 PM, Stefan Kaitschick
stefan.kaitsch...@hamburg.de wrote:

Crazy Stone (CS) lost the first game due to a wrong ko setting. The
opponent of CS played a superko violation which was legal under Japanese
rules, and CS lost the game by a faul.


The most devastating indictment against japanese rules I've seen so far.

Stefan


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


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


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

Re: [computer-go] Live broadcasting at UEC Cup

[Stefan Kaitschick]

Another option would be double elimination.
Drawbacks are that you first need to trim the field down to 16 contestants, 
and that it takes more rounds than single elimination. (aka ko)
The advantage is that it retains the ko characteristic of everybody still 
in it can win it while lessening the impact of chance.


Stefan

- Original Message - 
From: Rémi Coulom remi.cou...@univ-lille3.fr

To: computer-go computer-go@computer-go.org
Sent: Tuesday, December 01, 2009 9:47 PM
Subject: Re: [computer-go] Live broadcasting at UEC Cup



David Fotland wrote:

I'd like to thank all of the people who organized the UEC tournament for
providing machines and operators to allow Many Faces and others to
participate.  I'd like to suggest that the UEC organizers consider using 
a

Swiss tournament system in the future since it gives a more accurate
assessment of program strength.

Regards,

David Fotland


Hi,

I have just come back from Japan. I would like to also thank the UEC Cup 
organizers. I enjoyed the tournament very much, despite my stupid 
superko-setting mistake. Crazy Stone would probably have had no chance 
against KCC or Zen, anyways. I have really stopped working on Crazy Stone, 
so this version was almost identical to the version of last year. The only 
change is that I added more pattern shapes, which improves strength a 
little.


I like the direct-elimination system, because it determines a clear winner 
in a deterministic number of rounds. I don't like the KGS system, where 
the winner is determined by SOS.


I believe the direct-elimination system would work better without seeds. 
With seeds, very strong newcomers such as Zen or KCC this year, or Many 
Faces last year, risk meeting the winner of the previous year too early. I 
believe that without seeds, the pairings of the second day would have been 
much better. Also, playing in the first day allows to detect technical 
problems early. There would have been less problems with MoGo last year, 
had it played in the first day. And I would have liked to play in the 
first day too, rather than watch everybody have fun. Unlike human 
tournaments, computers don't get tired from playing so many games.


Anyway, the organization of the UEC Cup is really great. I thank again the 
organizers and participants, in particular those who guided us around 
Tokyo on Monday.


Bye,

Rémi
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/ 


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

Re: [computer-go] KCC won the 3rd UEC Cup

[Stefan Kaitschick]

Crazy Stone (CS) lost the first game due to a wrong ko setting.  The 
opponent of CS played a superko violation which was legal under 
Japanese rules, and CS lost the game by a faul.


The most devastating indictment against japanese rules I've seen so far.

Stefan


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

Re: [computer-go] Re: Hahn system tournament and MC bots

[Stefan Kaitschick]

No professional gambler, if he had the numbers laid out for him, would
ever choose unoptimal play, not when he's playing for the long
term. The computer, in the same way, would have to be modeled to
maximize expected value. Nothing else makes sense.

In a single game with high stakes, yes mindset (risk aversion, your
finances, etc) might come into it. But that is exactly why I specified
the long term scenario.

-Jeff



A professional gambler has a 2 step task.
1. Find a weaker player (aka fish)
2. capture the fish('s bankroll)

Luckily for the gambler, there is usually an adequate supply of fish.
But capturing the fish is a bigger problem.
Fish are shy and need to fed worms to make them feel comfortable.
So step 2 is really a 3 step process:
2a. let the fish win at the relatively small starting stakes.
2b. Act angry and astounded, offer a raise of the stakes. Now start winning.
2c. The angry and astounded fish will offer another raise of the stakes if 
step 2b was artful enough. Now capture the fish.


So the whole idea of optimizing the score it totally besides the point.


Stefan



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

Re: [computer-go] Hahn system tournament and MC bots

[Stefan Kaitschick]

If scoring matters, then instead of just estimating the winrate for a certain 
move, a bot has to estimate a komi/winrate function.
As a shortcut, maybe a simoid scoring function will suddenly start to shine.
But that really folds winrate and winning score into a single dimension.
If that is too much of a simplification only testing can tell.
For humans it just means don't resign, don't try anything too funny to catch 
up, and don't take it too easy in a winning position.
Put even more shortly it means don't bother counting for humans, which is 
ironic because for bots it means exactly the opposite.

Stefan

  - Original Message - 
  From: Don Dailey 
  To: computer-go 
  Sent: Monday, November 23, 2009 1:22 AM
  Subject: Re: [computer-go] Hahn system tournament and MC bots


  I'm pretty sure that this simplification of the rules would favor computers.  
 Of course that would require some program modifications, primarily counting 
points on the board instead of wins and losses.

  These rules basically takes out some (or at least reduces) elements of the 
game that humans are better at, such as knowing how to judge risk, knowing when 
to go for it, etc.   Go is still way too complex for computers to process 
well so any simplification like this is going to help computers.  

  - Don




  On Sun, Nov 22, 2009 at 6:23 PM, Alain Baeckeroot 
alain.baecker...@laposte.net wrote:


A Go tounrmaent with Hahn system has been retransmeted on kgs/eurogo TV
With these rules, the actual count makes a difference (as opposed to just 
win/lose)

 Winning by 40.5gets 100 points
 ......
 Losing by  40.5gets   0 point

see  http://senseis.xmp.net/?Bangneki
http://www.suomigo.net/wiki/HahnSystem

How current MCx bots can handle this kind of rules ?

The traditional safe way would ensure 60 points,
but trying crazy things (when losing) would cost a lot
if the result ends by losing by resignation or -40.5

What is the impact for chosing the best move ?
(choose the greediest amongst several with highest winning rate ?)

Alain.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/





--


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

Re: [computer-go] Re: Joseki Book

[Stefan Kaitschick]

Ofcourse I can't say what a correct opening is.
What I can say though, is that if bots are onto something with their 
strange

openings, at this point it's by accident.

It is not by accident, it is consistent with what the bot can read.

What I mean is that it may well be legitimate to play strange looking 
opening moves at the highest level.
But that the current generation of bots is so biased by certain blind spots 
that it is impossible to tell at this point
if their style stems in part from global evaluation or solely from their 
biases.
You are right ofcourse that this reflects their reading, but that reading 
will be seriously off when one side sytematically has a better chance of 
guessing good moves than the other.(With side I don't mean human vs. bot 
but invader vs defender)



They really do underestimate the chances of an invader.

Maybe it is obvious for a player stronger than the bot, but i am 1 stone
weaker than zen19 and i have hard time to beat it, even if i know it will
play cosmic style.
And i find it is very strong at sacrifying something to go back to its 
beloved

center

Yes. Zen would not be 1-2d on kgs if it couldn't hold it's own against 
opponents that allready knew what it was up to.



That goes for moyo parachute invasions as well as corner invasions.
I think that's because the likelyhood of randomly playing  killing moves 
is

greater than the chance of randomly playing shinogi moves.
Disproving the initial hypothesis about such an invasion is an unsolved
task.
David Fotland made a similar comment about semeais that are incorrectly
evaluated because the losing side can play its moves in any order
while the winning side cannot.


I have the same problem during my games against humans :)
It seems 1d bots have more or less the same problems as 'cosmic 1d' players.

Alain.

I don't quite agree here. For example,  a human 1d is much better than zen 
at judging 3-3 invasions.
Zen has serious deficits in judging the prospects of an invasion in a fairly 
unstructured area.(compared to humans, not to other bots) Otoh, there are 
areas were Zen is clearly superior to most human 1ds. It is surprisingly 
good at hand to hand fighting.
And it's exagerated optimism when it comes to killing groups has left many 
opponents stunned in disbelief when Zen actually killed an almost 
impregnable group.


Stefan




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

Re: [computer-go] Go Programming Language

[Stefan Kaitschick]

Has anyone tried programming Go in the Go Programming Language?

http://golang.org/


And the result would be a gogo?


hurray! go gogo!
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Joseki Book

[Stefan Kaitschick]

 Characterising the style quickly, it can start the first few moves at 

almost any intersections 3rd line and above ...


Ignorants call the early moves random but it is only because they lack 
an understanding of their reasoning  ...


The first statement is a pretty good definition of random.
Can't resist a flame war here  :-)

Stefan
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: Joseki Book

[Stefan Kaitschick]

I admit that I was narrowly parsing words.
I do like your bermuda triangle :-)

Stefan


- Original Message - 
From: Robert Jasiek jas...@snafu.de

To: computer-go computer-go@computer-go.org
Sent: Wednesday, November 11, 2009 2:57 PM
Subject: Re: [computer-go] Re: Joseki Book



Stefan Kaitschick wrote:

almost any intersections 3rd line and above ...

The first statement is a pretty good definition of random.


In contrast to random play, nobi, kosumi (except in the corner), empty 
triangles and the like must be avoided and the opposing stones' position 
should be taken into account as well. Furthermore the generation of the 
moves creates a difference from random because it is (or should be) 
embedded in a context of reasoning, planning or (MC programs) statistics.


--
robert jasiek
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

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

Re: [computer-go] Joseki Book

[Stefan Kaitschick]

True, but at the moment we're just interested in getting Orego to play
ANY joseki, i.e., a reasonable move in some corner, rather than a 
disastrous tenuki. Finding the right joseki will be future work.


(Orego also has a small fuseki book, which we're working to expand.)

On an intermediate level, a joseki that is good for a professional  is 
not necessarily so good for a kyu player.  Professionals are  better than 
weak players at using thickness, whereas solid territory  is worth much 
the same to both.  So if your objective is for Orego  to become 1-dan, 
you should tend to prefer josekis which give low  solid territorial 
positions, leaving the hard-to-use outer influence  for its opponents.


Good advice!



Peter Drake


By playing/watching bots on kgs I've noticed a bot specific weakness in 
applying OB on 19*19.

There is a consistency gap from OB to post-OB.
And ironically it's worse for simple and safe joseki than for more 
extravagant, influence-oriented ones.
When pure MCTS kicks in, the bot will go for what remains of center 
influence, trampling on his own low positions.
Alleviating this problem is even more important than direction of play or 
than the local quality of the move.
For example, MFoG likes to play keima boshi on a low hoshi kakari, even when 
it doesn't have any extensions.

This is a wise choice, considering current post-OB play.
One day, when MCTS becomes more refined, bots will stop overestimating the 
value of influence.
But until then, it is better to use an OB that puts the bot in a position 
that it likes, than in a position that is objectively good.


Stefan

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

Re: [computer-go] Re: Joseki Book

[Stefan Kaitschick]

Ofcourse I can't say what a correct opening is.
What I can say though, is that if bots are onto something with their strange
openings, at this point it's by accident.
They really do underestimate the chances of an invader.
That goes for moyo parachute invasions as well as corner invasions.
I think that's because the likelyhood of randomly playing  killing moves is
greater than the chance of randomly playing shinogi moves.
Disproving the initial hypothesis about such an invasion is an unsolved
task.
David Fotland made a similar comment about semeais that are incorrectly
evaluated because the losing side can play its moves in any order
while the winning side cannot.

Stefan

- Original Message - 
From: Robert Jasiek jas...@snafu.de
To: computer-go computer-go@computer-go.org
Sent: Tuesday, November 10, 2009 2:52 PM
Subject: Re: [computer-go] Re: Joseki Book


 Ingo Althöfer wrote:
  So, do you believe that the human problem of overestimating early
  territory is more severe than the MCTS-bot problem of overestimating
  influence?

 Of course, I was exaggerating as much as Stefan:) The truth is: We
 simply don't know the perfect play's degree of territory vs. influence
 balance.

 One thing is clear though: Traditional opening theory ends on the 4th
 line. Not because that line would be the end of the world but because
 traditional go theory is ignorant about trying to evaluate higher stones
 in comparison to lower stones well.

 Needless to say, I have always been happy that MC programs have been
 (accidentally of course) copying my opening style as Black:) IMO,
 their 19x19 opening strength is at least 3d level. It might be higher
 but I cannot prove or disprove it. They tend to play a bit more
 unrelated stones that those in my games.

  PS: Can you give us a comment on Fuego's influence-oriented Joseki's
  in the KGS bot tournament on Sunday ?

 I am not sure which game that is; please send it to me / the list as SGF
 inline or attachment. Or do you mean all games of Fuego played on 11-08?

 -- 
 robert jasiek
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/

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

Re: [SPAM] Re: [computer-go] First ever win of a computer against apro 9P as black (game of Go, 9x9).

[Stefan Kaitschick]

MCTS avoids evaluation. That is its main trick.
It also avoids subproblems like the plague. Atleast sofar.
I think you are absolutely right that in the end a program will need to be able 
to define subproblems, their local status, and the conditions that will change 
that status. The current switching behavior, that results when more than one 
critical area exists, can only be described as thrashing. Computing power alone 
will not solve this.
But local results don't stay local. And a winning move is often a winning move 
because it influences several critcal areas at the same time, effectively 
merging them.
How to apply divide and conquer to the protean and holistic game of go will 
remain a headache for a long time.

Stefan

  This may be useful in computer Go. One of the reasons human pros do well is 
that they compute certain sub-problems once, and don't repeat the effort until 
something important changes. They know in an instant that certain positions are 
live or dead or seki; they know when a move ( reducing a liberty, for example ) 
disturbs that result. This could probably be emulated with theorem-proving 
ability. Presently, search algorithms have to rediscover these results many 
times over; this is (in my opinion) why computer programs get significantly 
weaker when starved for time; they cannot think deeply enough to solve problems 
which may be solved in an eyeblink by a pro.



  Terry McIntyre terrymcint...@yahoo.com___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] First ever win of a computer against a pro 9P asblack (game of Go, 9x9).

[Stefan Kaitschick]

c) There was one non-blitz game (45 minutes per side). MoGo was unlucky 
  as it was black, but it nonetheless won the game. This game is enclosed. 
 All games can be found on KGS (account nutngo)

Congratulations.


b) MoGo already won a game as black, against Catalin Taranu, but I guess 
   the pro, at that time, had played an original opening somehow for fun 
   (I'm not sure of that, however).

c) My feeling is that blitz games are not favorable to computers... Statistics 
are in accordance with this I guess. Humans are stronger for short time
settings.

I just can't believe the general statement that computers scale better than 
humans on time.
Tripling the number of playouts surely won't do much for the program.
So if it's supposed to help, it means that the extra time will do practically 
nothing(or worse) for the human.
I'm willing to concede, that that might have exactly been the case.
The pro had allready won the shorter games and was probably inflicted by the 
same momentary imbalance as Catalin. That's actually very human. The bots have 
to earn their respect.
Also, in serious future showdowns, there will have to be regenerative pauses 
between the games.


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

Re: [computer-go] MC hard positions for MCTS

[Stefan Kaitschick]

I would add invasions.
This is especially obvious when the position cries for a san-san invasion.
Nakade may be a part of it.
But the biggest problem is that the path to life/ko is very narrow.
The defender has many useful moves and the invader has few.
So MCTS will falsely judge invadable areas to be safe.

Stefan


  - Original Message - 
  From: Petri Pitkanen 
  To: computer-go 
  Sent: Tuesday, October 27, 2009 11:05 AM
  Subject: [computer-go] MC hard positions for MCTS


  Hello,

  Are there more peculiar situation that will cause problems for MCTS apart 
from the three I know.
  1. Nakade (this is partuially solved in most of the programs)
  2. Semeais
  3. Double Ko.

  Last one was new to me. See 
http://files.gokgs.com/games/2009/10/26/ManyFaces-Hyoga.sgf

  In that game manyfaces wastes ko-threats in hopeless ko in lower left corner. 
And wins game by human weakness of pushing with stones taht are short of 
liberties.

  Is there any nice way to solve this or shouldd all of these solved in 
expanding the node using classical go-AI-engine.

  Petri

  -- 
  Petri Pitkänen
  e-mail: petri.t.pitka...@gmail.com



--


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

Re: [computer-go] MC hard positions for MCTS

[Stefan Kaitschick]

But, has anyone gathered stats on positions, from real games, that
require precise play by the defender/attacker/both/neither? Is defending
really easier than attacking?

Darren



Who is the defender?
One side is defending his territory, the other side is defending his group.
I think the general bias is towards overestimating the chance of killing.
Thats what makes MCTS programs such an aggressive lot :-)

Stefan
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] MC hard positions for MCTS

[Stefan Kaitschick]

 This causes what I call the horizon effect which prevents the
tree exploration to work properly - the moment the tree finds a sequence
that unbiases the simulations, it is horrified by the bad results [*] and
switches to a different branch, until it finds the same; thus, the bot
pushes the resolution (unbiasing) of the situation over the tree horizon
for as long as possible. This shows in actual games as the bot playing
random throwins and obviously pass moves before resigning.



 I don't know how much hidden ongoing research is being done about
dealing with the bias in the tree, the only result so far I'm aware of
is Remi Coulom's criticality heuristic, and it wasn't that effective;
I personally have some clear ideas I want to start experimenting with as
soon as possible - I think we need a top-down counterpart for the
bottom-up propagation function of RAVE. IMHO a substantial progress
in this direction is the next big thing to happen in computer go.




Petr Pasky Baudis


I like the criticality heuristic. It certainly points to an important 
problem.
One trick might be to identify hot spots with something akin to 
criticality and then penalize jumping between them. Because permutating 
moves between separate important areas is exactly what leads to the 
consequence evading horizon effect.


Stefan

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

Re: [computer-go] First ever win of a computer against a pro 9P asblack (game of Go, 9x9).

[Stefan Kaitschick]

29, turning into a won ko, really is a great way to play.
It would be interesting to know if MoGo perceived itself to be on the home 
stretch here.
So it would be great to have the bots win rate estimations as sgf comments.

Stefan
  - Original Message - 
  From: Olivier Teytaud 
  To: computer-go 
  Sent: Tuesday, October 27, 2009 5:38 PM
  Subject: [computer-go] First ever win of a computer against a pro 9P asblack 
(game of Go, 9x9).


  Dear all, some comments by my Taiwanese colleagues about the game played by 
MoGo against the 9p pro:

  1) mogoTW finally ran on the 16*8 system on Oct. 26, 2009.

  2) Contributors for which I did not know their real name: Hsien-Der Huang 
and Cheng-Wei Chou  (sorry for them!)


  3) Some comments by the pro, translated by people from Taiwan:

  ===


  He told the jounalists that he made a mistake on move 26, which is a move 
that it is hard to find such kind an error (move 26) even for a professional Go 
player. However, he was so surprised that MoGoTW found this mistake that he 
made during the game. That means the level of MoGoTW in 9x9 game has made an 
improvement than last time (08/2009).

  In addition, he also told the journalists that MoGoTW made a good move at 
Move 29. He thought that the main reason that MoGoTW won the game was Move 29 
and MoGoTW didn't make any mistake after Move 29.

  ==





--


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

Re: [computer-go] Pattern matching

[Stefan Kaitschick]

Very Cool. The mysterious part was more interesting than programming go.
That seemed almost impossible.

Stefan

- Original Message - 
From: Mark Boon tesujisoftw...@gmail.com

To: computer-go computer-go@computer-go.org
Sent: Wednesday, October 14, 2009 11:23 PM
Subject: Re: [computer-go] Pattern matching


On Sat, Oct 10, 2009 at 5:32 PM, Álvaro Begué alvaro.be...@gmail.com 
wrote:

Are you not going to tell us what this new job is about?



I almost forgot to answer this, I had no intention to sound
mysterious. My job is to make autonomous avatars (also called NPCs or
'bots') for a new MMO platform called Blue Mars. The immediate goal is
to make them more interesting, intelligent and interactive than the
zombie bots currently populating such worlds. That is a pretty easy
target. The ultimate goal is to make them actually seem intelligent
and indistinguishable from real players or even replace a real player
when he/she is not online. I've been given a practically free hand in
how I think this is accomplished best. I've only just started laying
the groundwork, but already there are some results that people are
excited about. So far so good.

Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/ 


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

Re: [computer-go] Generalizing RAVE

[Stefan Kaitschick]

Here's a suggestion to extend RAVE to better handle it:
There are 20 points within keima distance of any point not close to the
edge.(5*5 without the corners)
When RAVE values are backed up, they are put into the category defined by
the previous opponents move.
(21 categories, 20 + other. All added up yield the normal RAVE value)


One more thought. I think the proximity heuristic should actually make this 
more effective, not less.
Because many moves are close to the last one, the uninformative other 
category gets less hits.
And an ordering of the close points in order of previous effectiveness 
should help guide the search more effectively.


Stefan

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

[computer-go] public test suite

[Stefan Kaitschick]

Every now and then somebody submits an interesting 9*9 problem, usually 
rendered in X and O.
Wouldn't it be great to have a public suite, lets say a directory with 
black to play and win sgf problems.

For quick testing there should be only one correct first move.
There could also be subdirectories for problem types.
Maybe CGOS could be expanded to send bots through the test batch.

Stefan

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

Re: [computer-go] Generalizing RAVE

[Stefan Kaitschick]

 Stefan Kaitschick wrote:
 Here's a suggestion to extend RAVE to better handle it:
 There are 20 points within keima distance of any point not close to the
 edge.(5*5 without the corners)
 When RAVE values are backed up, they are put into the category defined by
 the previous opponents move.
 (21 categories, 20 + other. All added up yield the normal RAVE value)
 This amounts to accumulating a killer heuristic for local points.
 It can used in 2 ways:
 1. prefer the best local response
 2. if there is a good local response for the opponent, penalize a
candidate
 move

 I don't understand what it is useful for. I think that the near points
 from the previous move are already preferred by proximity heuristics.
 Could you give us an example?

 --
 Yamato

I guess you are right that the proximity heuristic is very helpful in
reducing the thrashing I described above.
But it can't do everything. After failing locally, the move generator will
at some point stumble over non-local ko threats.
And these moves will immediately improve the win rate, in part by not beeing
correctly answered and in part by moving the local focus
away from the original problem. So refuting a non-local threat comes at a
fairly high price. I don't see how this can be avoided.
But once a successful answer is found it would be nice to rember it as a
specific answer to the threat.
Not only for answering a threat - the proximity heuristic can again do a
large part of the work here.
A ko threat will typically have a great win rate against all moves except
one.
That might give the move a decent RAVE value even after it has been refuted.
But a non-local move against which a single strong refutation has been
found, should be tried less often than if the win rates
of attempted refutations were more balanced.

Stefan

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

Re: [computer-go] Generalizing RAVE

[Stefan Kaitschick]

MCTS, even though it walks to the end of the earth, has it's own horizon 
effect.

The name is more fitting for depth-limited alpha-beta search ofcourse.
It's a kind of procrastination. Finding a lot of useless things to do before 
admitting

an undesirable, but unavoidable consequence.
Even if a fight is important, there will usually exist interposable ko 
threat type moves.

These will trigger am entirely new search on the same subject.
And if there are n ko threats, there will be n! ways of trying them out.
Also, these n! attempts can be interposed every 2 half moves by the side 
that is losing the fight.
In some esoteric way, standard RAVE probably ameliorates this problem, or it 
wouldn't work as well as it does.

Here's a suggestion to extend RAVE to better handle it:
There are 20 points within keima distance of any point not close to the 
edge.(5*5 without the corners)
When RAVE values are backed up, they are put into the category defined by 
the previous opponents move.

(21 categories, 20 + other. All added up yield the normal RAVE value)
This amounts to accumulating a killer heuristic for local points.
It can used in 2 ways:
1. prefer the best local response
2. if there is a good local response for the opponent, penalize a candidate 
move


This could be combined with a hash table for high level nodes to catch 
transpositions.


Stefan 


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

Re: [computer-go] Generalizing RAVE

[Stefan Kaitschick]

It is exactly the same as my thought. I also have tried CRAVE, but the
results were worse than normal RAVE.

While RAVE is a very efficient algorithm, it strongly limits scalability
of the program. It typically makes a fatal mistake in the position that
the order of moves are important. We definitely need to improve RAVE,
but it is a very tough job.

--
Yamato


I have a question about RAVE: it seems a little strange to me that all 
outcomes below the current position are just added up.
Positions further down the tree are less similiar to the current position 
than those further up.

So shouldn't there be some kind of attenuation factor from level to level?

About the move order problem: I'm skeptical about finding an efficient full 
board algorithm that detects the consequences of move order.
There is so much random noise, that finding  a needle in a haystack seems 
inviting by comparison.
Imo, move order will somehow have to be linked to the satisfaction of 
subgoals, i.e. defending/killing strings/groups.


Stefan

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

[computer-go] string criticality?

[Stefan Kaitschick]

Rémi Coulom offers a formula for the criticality of point x.
(Criticality: a Monte-Carlo Heuristic for Go Programs)
Criticality being a measure of how important holding x is for winning.

c(x) = v(x)/N - (w(x)/N * W/N + b(x)/N * B/N)

N: number of playouts
W/B: playouts won by white/black
w(x)/b(x): playouts where x is owned by white/black
v(x): playouts where x is owned by playout winner

I'm prepared to believe that this formula is a meaningful measure of 
covariance.
The way I understand it, moves with a high criticality value are given a 
better chance of being tried.
Seems logical to me. I just wonder if something similiar couldn't also be 
used to identify the importance of strings allready played.

There would be 2 levels of criticality:
1. How important is the string for winning the game?
2. How important are points in the vicinity for attacking/defending this 
string?

(possibly with ordering information)

I'm not sure if the above formula should be used or if it should be 
something asymmetric.

Unlike point criticality there is a preestablished owner for a string.
There will be a tendency that losing a string will be more harmful for the 
defender than not capturing will be for the attacker.



Stefan 


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

Re: [computer-go] string criticality?

[Stefan Kaitschick]

Few months ago I tested it without success.
String criticality seems a nice idea, but how should it be implemented?
Just giving high priority to the liberties does not work, because that
cannot be distinguished from the simple dame-filling.
Can you suggest a concrete formula?

--
Yamato


a shot in the dark:


1. How important is the string for winning the game?
Using Rémi Couloms' formula
c(s) = v(s)/N - (w(s)/N * W/N + b(s)/N * B/N)

N: number of playouts
W/B: playouts won by white/black
w(s)/b(s): playouts where s is owned by white/black
v(s): playouts where s is owned by playout winner


2. How important are points for winning the string?

In a semiai situation there are no critical points(ignoring eye 
making/destroying)
Each side has its own valuable points, playing the opponents move is usually 
catastrophic.

This should actually make it easier to find these points.
They should be as good for one side as they are bad for the other.
(Or worse, consider making your own large eye smaller)

something like this(a little Bayes):

P(C|X) = P(X|C) * P(C) / P(X)

P(C|X): chance that the string will be captured if x is played by any side
P(C): string_captured_count / N
P(X): x_not_empty_count / N
P(X|C): x_not_empty_when_string_captured / string_captured_count

value 0: perfect defense
value 1: perfect offense

The moves of one side can be dependant on each other because they might have 
to be played in a certain order.

This interdependence could be quite expensive/difficult to find.
But ignoring it will indeed reduce string criticality to normal dame 
filling.

So my suggestion is this: completely order the moves for both sides.
This way interdependencies don't have to be explicitly analysed.
A move that needs to be played earlier should get a higher rating naturally.
The trick would be to allways impose this order, even if it doesn't actually 
exist.
If the criticality of a string is high, it would try to suppress these moves 
in any other order.
My hope is that this would alleviate an unfair permutation advantage by 
the losing side.



Stefan 


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

Re: [computer-go] string criticality?

[Stefan Kaitschick]

Maybe it would be good enough to only update the string criticality first.
More expensive calculations for the found critical strings could kick in 
later.
You asked for a formula, and I tried to comply, but its really only 
conceptual.
Also there will still be points that are good for both, taking a liberty or 
extending by 2 liberties for example.

The central idea would be to discourage permutations of dame-filling moves.
The ordering criterea might not have to be so precise.

Stefan

- Original Message - 
From: Yamato yamato...@yahoo.co.jp

To: computer-go computer-go@computer-go.org
Sent: Monday, September 14, 2009 5:08 PM
Subject: Re: [computer-go] string criticality?



Stefan Kaitschick wrote:

something like this(a little Bayes):

P(C|X) = P(X|C) * P(C) / P(X)

P(C|X): chance that the string will be captured if x is played by any side
P(C): string_captured_count / N
P(X): x_not_empty_count / N
P(X|C): x_not_empty_when_string_captured / string_captured_count

value 0: perfect defense
value 1: perfect offense


Well, it should work theoretically but seems very expensive for the
processor. When we have this information, do we have to update every
node value for every string every time?

--
Yamato
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/ 


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

Re: [computer-go] Stone-Age

[Stefan Kaitschick]

Stone-Age - spooky concept :-)
I suppose it has some relationship to generally lighter playouts deeper in 
the tree.

Have you experimented some more with this?
Perhaps the cutoff point should be somewhere in the future though, moving 
towards the present as the game progesses.
Otherwise you completely disable patterns for the first move, which doesn't 
seem right.


Stefan

I feel ungrateful for saying this, but a search in the archive would be 
great.


- Original Message - 
From: Mark Boon tesujisoftw...@gmail.com

To: computer-go computer-go@computer-go.org
Sent: Monday, September 14, 2009 8:49 PM
Subject: Re: [computer-go] string criticality?



Maybe from a different angle, but maybe you remember me writing about
'stone-age'. Basically what it did was assuming strings created during
the playout are less critical than existing strings. I used this to
limit my tactical search by a great deal by not doing any search on
'new' strings. This didn't affect strength in any way I could measure,
but it reduced the overhead of tactics ( I don't remember exactly, but
I think it cut in half).

I think the single most useful information about strings or groups
would be whether it has two eyes. Unfortunately I haven't been able to
think of a cost-effective way to compute that yet :)

Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/ 


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

Re: [computer-go] Stone-Age

[Stefan Kaitschick]

My mistake. I misstook start of the playout for the board position.

Stefan

- Original Message - 
From: Mark Boon tesujisoftw...@gmail.com

To: computer-go computer-go@computer-go.org
Sent: Monday, September 14, 2009 11:42 PM
Subject: Re: [computer-go] Stone-Age



On Mon, Sep 14, 2009 at 10:55 AM, Stefan Kaitschick
stefan.kaitsch...@hamburg.de wrote:

Stone-Age - spooky concept :-)
I suppose it has some relationship to generally lighter playouts deeper 
in

the tree.
Have you experimented some more with this?


No, I didn't have time to explore this further.


Perhaps the cutoff point should be somewhere in the future though, moving
towards the present as the game progesses.
Otherwise you completely disable patterns for the first move, which 
doesn't

seem right.


I'm not sure. I used as cut-off the start of the playout, which being
partly down the tree by a few moves (at least) seems to work fine. My
main 'requirement' was that it didn't lose strength with equal number
of playouts. Since that requirement was met I didn't look any further.
I'd be surprised if pushing it further out into the future would
actually *gain* strength, whereas it would certainly lose speed.



Stefan

I feel ungrateful for saying this, but a search in the archive would be
great.


You mean you don't keep your mail? My post about this was on Feb 2nd.
GMail is your friend ;-)

Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/ 


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

Re: [computer-go] (two won semiais = lost game?) semiais - expulsion from mc paradise

[Stefan Kaitschick]

The basic mc paradigm is refusing to differentiate structures for the 
purpose evaluation - ontological bliss if you will.

But semiais are now throwing go programers out of paradise.
They must be found and evaluated (The semiais, not the programers)
So maybe the first question to answer is what would constitute a solved 
semiai.
Maybe it will take separate tactical analysers, but a formulation within the 
mc framework would be preferable.
In Davids example below, with B winning although W is ahead because the W 
moves must be in order,
the first step would be to identify the B moves as belonging together in a 
group.(hard enough)
This information could then be used to somehow nullify the B permutation 
advantage through the playout policy.
A fully solved semiai would be an ordered list of groups of moves for both 
sides, with group members being permutable.

Good luck with this.

Stefan

- Original Message - 
From: David Fotland fotl...@smart-games.com

To: 'computer-go' computer-go@computer-go.org
Sent: Monday, September 07, 2009 6:18 PM
Subject: RE: [computer-go] two won semiais = lost game?



The playouts often give the side with fewer liberties the advantage in a
semeai.  This causes a large fraction of Many Faces' lost games to strong
players on KGS.

One problem is approach moves.  Say W has a group with 3 liberties, but 
they

must be played in order (perhaps one is an eye, and one needs an approach
move).  B has a group with 5 liberties, but they are all equivalent and 
can
be filled in any order.  W has only one random move that wins the semeai. 
B
has 5 random moves that improve its chance to win the semeai.  Most 
playouts

will end with B winning this semeai even though W is one move ahead.

The other problem is local patterns.  Often a 3x3 pattern will cause one
side to fill its own liberty.

David


-Original Message-
From: computer-go-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of Stefan Kaitschick
Sent: Monday, September 07, 2009 2:36 AM
To: computer-go
Subject: [computer-go] two won semiais = lost game?

I have a general question: how good are the current information gathering
mechanisms in the mc tree to insure that advantagous semiais are actually
won? Random playouts will surely give the side with more libs the
advantage,
but to what degree? Lets say the leading side wins the semiai in 2/3 of
all
playouts. This seems comfortable. But except for turnarounds through ko,
the
leading side should allways win the semiai. What if one side has 2 
winning

semiais on the board, with winning both needed to win the game? If both
have
a 2/3 chance of winning in playouts they combine to 4/9 - a losing
evaluation for a won game.

Stefan

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


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


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

[computer-go] two won semiais = lost game?

[Stefan Kaitschick]

I have a general question: how good are the current information gathering 
mechanisms in the mc tree to insure that advantagous semiais are actually 
won? Random playouts will surely give the side with more libs the advantage, 
but to what degree? Lets say the leading side wins the semiai in 2/3 of all 
playouts. This seems comfortable. But except for turnarounds through ko, the 
leading side should allways win the semiai. What if one side has 2 winning 
semiais on the board, with winning both needed to win the game? If both have 
a 2/3 chance of winning in playouts they combine to 4/9 - a losing 
evaluation for a won game.


Stefan 


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

Re: [computer-go] two won semiais = lost game?

[Stefan Kaitschick]

It is obvious that the current mechanism is bad. And another problem on 
the
wrong evaluation is the amplification of the error. When there are 
unresolved
life/death or semeais on the board, typical MC programs become weak 
because

of the instability of the simulations.

I think that we need a new algorithm to combine the UCT information into 
the
playout policy. I have already done a lot of experiments in this area, but 
not

yet succeed. However I believe this idea will be the next breakthrough.

--
Yamato


Remember quiescence search in chess programing. There, captures are executed 
before the evaluation function is invoked. Maybe a kind of quiescence search 
is needed here too. In the case of go, semiais could be played out(allways 
trading an equivalent number of moves locally), before the actual
search for a move begins. There are problems with this: finding the local 
battles, trading moves realistically, compensating for lost ko threats, 
attempting to playout a hot fight, ect. But getting rid of useless 
combinatorial explosions would be worth a lot.


Stefan 


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

Re: [computer-go] Dynamic komi at high handicaps

[Stefan Kaitschick]

Good work Ingo.
But why should it be near 50%? If it is, the komi is too large.(if giving 
handicap)
You just have to reserve some thinking time for reruns, in case the komi 
estimate from the last move doesn't fit anymore.


Stefan


(ii) Also on 13x13 board dynamic komi seems to help, although
the consolidation problem (bot becomes to conservative when
too near at 50 % for wrong komi levels) is more serious there.


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

Re: [computer-go] Dynamic komi at high handicaps

[Stefan Kaitschick]

One last rumination on dynamic komi:

The main objection against introducing dynamic komi is that it ignores the true 
goal
of winning by half a point. The power of the win/loss step function as scoring 
function underscores
the validity of this critique. And yet, the current behaviour of mc bots, when 
either leading or trailing by a large margin, resembles random play.
The simple reason for this is that either every move is a win or every move is 
a loss.
So from the perspective of securing a win, every move is as good as any other 
move.
Humans know how to handle these situations. They try to catch up from behind, 
or try to play safely while defending enough of a winning margin.
For a bot, there are some numerical clues when it is missbehaving.
When the calculated win rate is either very high or low and many move 
candidates have almost identical win rates, the bot is in coin toss country.
A simple rule would be this: define a minimum value that has to separate the 
win rate of the 2 best move candidates.
Do a normal search without komi.
If the minimum difference is not reached, do a new a new search with some komi, 
but only allow the moves within the minimum value range from the best candidate.
Repeat this with progressively higher komi until the two best candidates are 
sufficiently separated.(Or until the win rate is in a defined middle region)
There can be some traps here, a group of moves can all accomplish the same 
critical goal.
But I'm sure this can be handled. The main idea is to look for a less ambitious 
gloal when the true goal cannot be reached.
(Or a more ambitious goal when it is allready satisfied). By only allowing 
moves that are in a statistical tie in the 0 komi search,
it can be assured that short term gain doesn't compromise the long term goal.

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

Re: [computer-go] MoGo - ManyFaces

[Stefan Kaitschick]

 13 games were played and the total score was 8-5 for CzechBot. I wonder
how would they play if on even grounds. The general game pattern was the
usual wild middlegame wrestling typical of MC, with CzechBot usually
getting large edge initially (70% winning probability and seemingly
unshakeable position), but then in the lost games making a careless
blunder or two when it got too much ahead, and panicking subsequently.
Overlooking ladders seemed to happen to it several times.



trollSo maybe CzechBot should put a komi burden on itself when it gets too 
optimistic./troll


Stefan 


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

Re: [computer-go] Dynamic komi at high handicaps

[Stefan Kaitschick]

Maybe I should ask first, for clarity sake, is MCTS performance in
handicap games currently a problem?

Mark



Yes, it's a big problem. And thats not a matter of opinion.
MC bots, leading a game by a large margin, will give away their advantage 
lighly except for the last half point.
Even on a 9*9 board, even if the bot wins more games on even with 7.5 komi, 
that doesn't mean that it's impossible
for the human to win, giving a 2 stone handicap. All it needs is a single 
bot missjudgement after the game got close.
Granted, bots are really excellent at defending the last half point 
advantage tooth and claw. I'm just saying that it should

be impossible for the human to win on 2 stones, and it isn't.
If they are behind by a large margin they will play either random or ko 
threat type moves.
So there is a kind of symmetry here. Beeing too far ahead or behind ruins 
the bots plays.
The biggest practical problem right now is poor play against pros on a 19*19 
board, taking a large handicap.
Special fuseki patterns are only a patch. When, after a decent opening, the 
regular patterns take over, they usually immediately

start to work against the bots own previous moves.
Looking into the horses mouth, instead of invoking Aristotle, is really the 
only way to find out.
I had hoped that programmers would find the idea interesting enough to try 
it out.
Instead, I found myself in a hand waving contest. Granted, I started it, so 
I can't complain.
Thanks to Ingo for simulating dynamic komi by hand to give programmers 
something less speculative.
Btw, I played 2 games (as gogonuts) on KGS against goIngo(really ManyFaces). 
I won both on 5 stones. But in the first one, with komi adjusted by Ingo, I 
had to make a very critical invasion that should not really have worked. In 
the second game I won without problems.

At the time, Ingo adjusted the win rate for w to 50%.
Since then, with his limited trials, Ingo found out that adjusting the komi 
to give each side a 50% win rate isn't optimal. His current rule is to 
adjust to 42% for w. This is ofcourse only a crude start, but sophistication 
can only be introduced by programmers.


Stefan




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

Re: [computer-go] Dynamic komi at high handicaps

[Stefan Kaitschick]

Modeling the opponents mistakes is indeed an alternative to introducing komi.
But it would have to be a lot more exact than simply rolling the dice or 
skipping a move here and there.
Successful opponent modeling would implement the overplay school of thought - 
playing tactically refutable
combinations that are beyond the opponents skill to punish them.
Introducing komi at the 50% win rate level would implement the honte school of 
thought - play as if against yourself.
At a win rate of less than 50% it implements the almost honte school of 
thought. :-)
I'm not trying to moralize. In love and go anything is fair.
I'm just saying that while both approaches are legitimate, adjusting the komi 
is much easier to do.

Different subject, suggestion for a komi adjustment scheme:

1. Make a regular evaluation(no extra komi)
2. If the win rate of the best move is within certain bounds you're done
(Say between 30 and 70 percent.Just a guess ofcourse.Also, this might shift as 
the game progresses)
3. If not, make a komi adjustment dependant on how far out of bounds the win 
rate is.
(No numerical suggestion here. Please experiment.)
4. Make a new search with this komi.
5. If the new result is in bounds calculate winrate_nokomi * factor + 
winrate_komi for each candidate and choose the highest one.
(factor around 10 maybe)
6. If not, go back to 3


The idea is to choose a move that doesnt contradict the long term goal(no komi 
search) while trying for a short term goal(komi search)
if no long term goal is available.( Or if every move satisfies the long term 
goal in case of taking handicap)


Stefan



  - Original Message - 
  From: Don Dailey 
  To: tapani.ra...@tkk.fi ; computer-go 
  Sent: Thursday, August 13, 2009 4:02 PM
  Subject: Re: [computer-go] Dynamic komi at high handicaps


  This idea makes much more sense to me than adjusting komi does.At least 
it's an attempt at opponent modeling, which is the actual problem that should 
be addressed. Whether it will actually work is something that could be 
tested.

  Another similar idea is not to pass but to play some percentage of random 
moves - which probably would work in programs with strong playout strategies.   
Of course this would be meaningless for bots that have weak (and already 
random) playout strategies.

  - Don





  On Thu, Aug 13, 2009 at 6:17 AM, Tapani Raiko pra...@cis.hut.fi wrote:

I don't think the komi should be adjusted.

Instead:

Wouldn't random passing by black during the playouts model black making
mistakes much more accurately? The number of random passes should be
adjusted such that the playouts are close to 50/50. Adjusting the komi
would make black play greedily, while random passing during playouts
would make black play safe (rich men don't pick fights).

Tapani Raiko


Christoph Birk wrote:

 I think you got it the wrong way round.
 Without dynamic komi (in high ha
 ndicap games) even trillions of simulations
 with _not_ find a move that creates a winning line, because the is none,
 if the opponet has the same strength as you.
 WHITE has to assume that BLACK will make mistakes, otherwise there
 would be no handicap.

 Christoph
 ___
 computer-go mailing list
 computer-go@computer-go.org
 http://www.computer-go.org/mailman/listinfo/computer-go/



--
 Tapani Raiko, tapani.ra...@tkk.fi, +358 50 5225750
 http://www.iki.fi/raiko/


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





--


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

Re: [computer-go] Dynamic komi at high handicaps

[Stefan Kaitschick]

What a bot does with its playouts in a handicap situation is to essentially try 
to beat itself, despite the handicap.

And in this situation the bot reacts in a very human way, it becomes despondend.

Adjusting the komi dynamically shifts the goal from winning to catching up 
quickly enough.

I feel that that is the natural handicap strategy, not a band-aid.

Ofcourse, the dynamic komi must be adjusted down to zero in good time.

I think there are 2 main reasons that this hasnt been fully explored sofar.

1. Trying to maximize the score turned out to be a huge mistake, compared to 
trying to maximize the winrate.
This makes dynamic komi a kind of blind spot.

2. Handicap go wasnt given special attention sofar.


Stefan

  - Original Message - 
  From: Don Dailey 
  To: computer-go 
  Sent: Wednesday, August 12, 2009 11:24 PM
  Subject: Re: [computer-go] Dynamic komi at high handicaps


  Terry,

  I understand the reasoning behind this, your thought experiment did not add 
anything to my understanding. And I agree that if the program is strong 
enough and the handicap is high enough this is probably better than doing 
nothing at all.

  However, I think there must be something that is more along the lines of 
treating the disease, not the symptoms.You might be able to put a band aid 
on the problem but you have not addressed the real issue in a systematic way.

  Besides, I have not yet seen anyone demonstrate that this works - it's always 
talked about but never implemented.It is made to sound so simple that you 
have to wonder where the implementation is and why the strong programs do not 
have it.

  - Don





  2009/8/12 terry mcintyre terrymcint...@yahoo.com

Consider this thought experiment.

You sit down at a board and your opponent has a 9-stone handicap.


By any objective measure of the game, you should resign immediately.

All your win-rate calculations report this hopeless state of affairs. 

Winrate gives you no objective basis to prefer one move or another.

But, you think, what if I can make a small group? What if I try for a 
lesser goal, such as don't lose by more than 90 points?

Your opponent has a 9 stone handicap because he makes more mistakes than 
you do. 

As the game progresses, those mistakes add up. You set your goal higher - 
losing by only 50 points; losing by only 10 points. 

The changing goal permits you to discriminate in a field which would 
otherwise look like a dark, desolate, win-less landscape. 


Terry McIntyre terrymcint...@yahoo.com


“We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop






From: Don Dailey dailey@gmail.com
To: computer-go computer-go@computer-go.org
Sent: Wednesday, August 12, 2009 1:05:36 PM
Subject: Re: [computer-go] Dynamic komi at high handicaps


Ok,  I misunderstood his testing procedure.  What he is doing is far more 
scientific than what I thought he was doing.  

There has got to be something better than this.   What we need is a way to 
make the playouts more meaningful but not by artificially reducing our actual 
objective which is to win.

For the high handicap games,  shouldn't the goal be to maximize the score?  
 Instead of adjusting komi why not just change the goal to win as much of the 
board as possible?This would be far more honest and reliable I would think 
and the program would not be forced to constantly waste effort on constantly 
changing goals.


- Don






On Wed, Aug 12, 2009 at 3:33 PM, Brian Sheppard sheppar...@aol.com wrote:

  The small samples is probably the least of the problems with this.   Do 
you
  actually believe that you can play games against it and not be subjective
  in
  your observations or how you play against it?

  These are computer-vs-computer games. Ingo is manually transferring moves
  between two computer opponents.

  The result does support Ingo's belief that dynamic Komi will help programs
  play high handicap games. Due to small sample size it isn't very strong
  evidence. But maybe it is enough to induce a programmer who actually plays
  in such games to create a more exhaustive test.

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






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





--


  ___
  computer-go mailing list
  computer-go@computer-go.org
  

Re: [computer-go] Dynamic komi at high handicaps

[Stefan Kaitschick]

What seems difficult to me however is to devise a reasonable way to
decrease this komi as the game progresses


Certainly that is the main problem. But the main considerations are not so 
hard to find


1. Win rate of the best move.
2. How far has the game progressed
3. deviation between the win rates of all possible moves.( with higher 
deviation dynamic komi is less called for)


Stefan

- Original Message - 
From: Mark Boon tesujisoftw...@gmail.com

To: computer-go computer-go@computer-go.org
Sent: Wednesday, August 12, 2009 11:36 PM
Subject: Re: [computer-go] Dynamic komi at high handicaps



I started to write something on this subject a while ago but it got
caught up in other things I had to do.

When humans play a (high) handicap game, they don't estimate a high
winning percentage for the weaker player. They'll consider it to be
more or less 50-50. So to adjust the komi at the beginning of the game
such that the winning percentage becomes 50% seems a very reasonable
idea to me. This is what humans do too, they'll assume the stronger
player will be able to catch up a certain number of points to overcome
the handicap.

What seems difficult to me however is to devise a reasonable way to
decrease this komi as the game progresses. In an actual game the
stronger player catches up in leaps and bounds, not smoothly.

In MC things are not always intuitive though.

Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/ 


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

Re: [computer-go] Dynamic komi at high handicaps

[Stefan Kaitschick]

For instance I am sure he will not sit merrily by and watch his opponent 
consolidate a won game just so that he can have a respectable but losing 
score.Dynamic komi of course does not address that at all.

This seems self evident, but it may actually be a treacherous conclusion.

Dynamic komi really only has one legitimate use. To avoid flat lining or, 
taking handicap, saturated win rates.
This doesnt mean that the program needs to be satisfied with losing.(A komi 
that put the win rate to 50% would model that)
A win rate range between 35 and 45 percent might make the program locally 
ambitious, without attempting the impossible with ko threat
type moves.

Stefan 





  - Original Message - 
  From: Don Dailey 
  To: computer-go 
  Sent: Thursday, August 13, 2009 12:10 AM
  Subject: Re: [computer-go] Dynamic komi at high handicaps





  On Wed, Aug 12, 2009 at 5:58 PM, Mark Boon tesujisoftw...@gmail.com wrote:

2009/8/12 Don Dailey dailey@gmail.com:


 I disagree about this being what humans do.   They do not set a fake komi
 and then try to win only by that much.


I didn't say that humans do that. I said they consider their chance
50-50. For an MC program to consider its chances to be 50-50 you'd
have to up the komi. There's a difference.

  If the handicap is fair,  their chance is about 50/50.   However,  rigging 
komi to give the same chance is NOT what humans do.   The only thing you said 
that I consider correct is that humans estimate their chances to be about 
50/50.

  One thing humans do is to set short term goals and I think dynamic komi is an 
attempt to do that - but it's a misguided attempt because you are setting the 
WRONG short term goal. The human will have a much more specific goal that 
is going to be compatible with his hope of winning the game.For instance I 
am sure he will not sit merrily by and watch his opponent consolidate a won 
game just so that he can have a respectable but losing score.Dynamic komi 
of course does not address that at all.






 I think their model is somewhat incremental, trying to win a bit at a time
 but I'm quite convinced that they won't just let the opponent consolidate
 like MCTS does.   With dynamic komi the program will STILL just try to
 consolidate and not care about what his opponent does.   But strong 
players
 will know that letting your opponent consolidate is not going to work.
So
 they will keep things complicated and challenge their weaker opponents
 everywhere that is important.



It's difficult to make hard claims about this. I don't agree at all
that the stronger player constantly needs to keep things complicated.
Personally I tend to play solidly when giving a handicap. Because most
damage is self-inflicted. You can either make a guess what the weaker
player doesn't know, or you can give him the initiative and he'll show
you. I prefer the latter approach.

When done properly, I don't see how an MCTS program would consolidate
all the time. Doing so would keep the position stable while the komi
declines. As soon as he gets behind the komi degradation curve play
will automatically get more dynamic in an attempt to catch up.

The problem is: we're speculating. The proof is in the pudding.

  Agreed. 

  - Don

   




Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/





--


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

Re: [computer-go] Re: Dynamic komi in commercial programs

[Stefan Kaitschick]

I think the most promising field for using dynamic komi is in low handicap play.
Because the main strategic principle for w in low handicap play is patience, 
which is
easily and naturally modeled by a declining komi.
For high handicaps the main strategic principle is light play, which is an 
elusive concept even for humans,
and very difficult to even begin to implement. Light play is not the same as 
bean scattering.
Maybe it will be possible to give greater weight to sparse shape patterns in 
high handicap go, but who knows?

Stefan


  - Original Message - 
  From: terry mcintyre 
  To: computer-go 
  Sent: Wednesday, July 15, 2009 12:29 AM
  Subject: Re: [computer-go] Re: Dynamic komi in commercial programs


  Maybe we should go back to the question which dynamic komi is an attempt to 
solve: how to obtain better discrimination when every move seems to be 
clustered near I am so freaking dead or I am so far ahead, as the case may 
be.


   Terry McIntyre terrymcint...@yahoo.com



  “We hang the petty thieves and appoint the great ones to public office.” -- 
Aesop



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

Re: [computer-go] Re: Dynamic komi in commercial programs

[Stefan Kaitschick]

- Original Message - 
From: Dave Dyer dd...@real-me.net

To: computer-go computer-go@computer-go.org
Sent: Saturday, July 11, 2009 10:54 PM
Subject: [computer-go] Re: Dynamic komi in commercial programs




If you are in a lost position, good play is play that maximizes
the probability of a turnaround, which is quite different depending
on how far behind you are, and for what reason.

If the status of all the major groups is solid, then concentrating
on tactics which can gain a few points reliably might be the right
thing.

On the other hand, if the status of some groups is less than
immutable, then focusing on changing their status favorably might
be correct. It's hard to see how shifting Komi will influence
the style of play in this direction.




Dynamic komi in a sense means that the bot is deluding itself on purpose.
Obviously this is dangerous medicine, a kind of magic mushroom.
So what could be worse than a deluded bot?
I say, letting a monkey play could be worse.
And monkeys' play is what you get from an mc bot when all possible moves 
come back with indistinguishably

wonderful or terrible win rates.
Adding a wishful (or pessimistic) komi will distort reality, but will help 
create bigger win rate differences between moves.
It should be possible to assign costs to both dynamic komi and to 
insufficiently spreading win rates between moves.
My hypothesis is, that with unstable groups on the board, the win-rate 
spread will tend to be larger then with stable groups.
So with proper balancing, the bot should refuse to take dynamic komi when he 
sees a chance to win outright.


Stefan

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

Re: [computer-go] Scoring - step function or sigmoid function?

[Stefan Kaitschick]

Thinking about why... In a given board position moves can be grouped
into sets: the set of correct moves, the set of 1pt mistakes, 2pt
mistakes, etc. Let's assume each side has roughly the same number of
moves each in each of these groupings.

If black is winning by 0.5pt with perfect play, then mistakes by each
side balance out and we get a winning percentage of just over 50%. If he
is winning by 1.5pt then he has breathing space and can make an extra
mistake. Or in other words, at a certain move he can play any of the
moves in the correct moves set, or any of the moves in the 1pt
mistakes set, and still win. So he wins more of the playouts. Say 55%.
If he is winning by 2.5pts then he can make one 2pt mistakes or two 1pt
mistakes (more than the opponent) and still win, so he wins more
playouts, 60% perhaps. And so on.

My conclusion was that the winning percentage is more than just an
estimate of how likely the player is to win. It is in fact a crude
estimator of the final score.

Going back to your original comment, when choosing between move A that
leads to a 0.5pt win, and move B that leads to a 100pt win, you should
be seeing move B has a higher winning percentage.

Darren



Point well taken.Winning positions tend to cluster and critical swing moves 
are rare, statistically speaking.
If the position is more or less evenly balanced, the step function might 
allready be very close to optimal because of this.
But I would like to bring up a well known mc quirk: In handicap positions, 
or after one side scored a big success in an even game,
bots play badly with both sides, until the position becomes closer again. 
The problem here is that every move is a win (or every move is a loss).
On 9*9, its possible to beat a bot, giving it 2 stones, even when it's a 
close contest on even with komi. All it needs is a single bot missread at 
the moment the position becomes close(which it will, because the bot will be 
lazy until that point).
So it would be desirable for the bot to make keeping the score advantage 
large an auxiliary goal.

This has been tried ofcourse, but without much success sofar.
And it seems that the main reason is that tinkering with the scoring 
function to achive this, tends to worsen play in competitive situations.
I have an alternative suggestion: In handicap games, introduce a virtual 
komi, that gets reduced to 0 as the game progresses.
This would work for the bot on both sides: If the bot has b it will make 
less lazy plays, if it has w, it will be less maniacal.
For example, in a 4 stone 19*19 game, if the real starting advantage is 
about 45 points, the bot could introduce an internal komi of about 30-35.
The bot should be optimistic with b and pessimistic with w, but not to the 
point that every move evaluates to the same value, and move selection 
becomes a toss-up. Another way to look at this, is that humans that give a 
handicap know that they can't usually catch up in one piece.
And humans that take a handicap know that they can't give up their advantage 
too quickly.

Virtual komi encodes this simple knowledge.
During the course of the game this internal komi would ofcourse have to be 
reduced to 0.
The proper criteria can only be found by experimentation, but the important 
factors will be how far the game has progressed, and what the win rate is 
for the best move. If the bot becomes pessimistic with b it should lower the 
internal komi more quickly.


One advantage of this approach is that it doesn't mess up even game play.
A more elaborate scheme would be to make a komi search before the real 
search - to find the best ratio of win rate to internal komi before making 
the normal move search with this komi. This could also be useful in even 
play after one side pulled ahead.


Stefan





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

Re: [computer-go] Scoring - step function or sigmoid function?

[Stefan Kaitschick]

My conclusion was that the winning percentage is more than just an
estimate of how likely the player is to win. It is in fact a crude
estimator of the final score.

Going back to your original comment, when choosing between move A that
leads to a 0.5pt win, and move B that leads to a 100pt win, you should
be seeing move B has a higher winning percentage.

Darren


Good point. Wins will occur in clusters, so win-rate and score go hand in 
hand.
MC algorithms seem to be treacherous ground when it comes to anticipating 
consequences.

Here's another shot:

MC bots play handicap games poorly.
When they take w they go into maniac mode because they can't find any wins.
When they take b they dither around until the game gets close.
What is entirely missing are the concepts of catching up or of preserving a 
lead.
So my suggestion would be to pretend that there is a komi that almost 
compensates the handicap.

A numerical example: a 4 stone handicap is worth about 45 points.
Start with a virtual komi of about 35 points, and decrease that value to 0 
during the course of the game.
This works in both directions. If the bot has w he will be pessimistic, but 
not suicidal.

If he has b he will be optimistic, but not so lazy.
The rate of giving rope should depend on the number of moves played and on 
the winning percentage.

If the winning percentage drops early, reduce the virtual komi more sharply.
One advantage of this approach would be that it wouldn't tinker with even 
game stategies.
A more elaborate scheme would be to make several preliminary searches at 
different komi levels.
The goal would not be to find the best move. The search would only  try to 
find the win rate for the komi.
Depending on how far the game progressed, giving a virtual komi will be 
worth some win rate reduction.
(Or taking a virtual komi will increase the winrate, making the bot play 
less maniacal than playing a string of kothreats in an unfavorable position.
After a decision on the komi is reached, a search is done for this komi to 
find the move to be played.

Towards the end of the game the virtual komi must allways be 0.
This strategy might even be useful for even games, when the winrate strongly 
favors one side before the late endgame.
That  would revert to the handicap game situation.(Except that a disparity 
of strength is not presumed)


Stefan




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

[computer-go] Scoring - step function or sigmoid function?

[Stefan Kaitschick]

It seems to be surprisingly difficult to outperform the step function  when 
it comes to mc scoring.
I know that many surprises await the mc adventurer, but completely 
discarding the final margin of victory just can't be optimal. The sigmoid 
function can be tinkered with ofcourse, by making its slopes steeper and/or 
by awarding bonus points for victory. But if it looks like the step function 
in the end, then computational resources could have been saved by just using 
the step function from the start. The power of the step function is that it 
directly awards what we are really interested in - victory. And an mc 
program, holding on to a half point victory in the endgame,  is a thing of 
beauty and terror. But in the opening, where the scoring leaves are 300 
moves away from the root, surely a putative half point win doesn't translate 
to a significant advantage, where as a 100 point win would. My suggestion is 
this: how about backing up the individual outcomes through the  tree and 
then do the evaluation at the intermediate nodes, using the sigmoid function 
and the parameters depending on the distance from the root? This might be 
too expensive computationaly, but shortcuts could be devised. For example, 
wins could be sorted into a couple of different categories( from half point 
win to landslide), and those categories could be evaluated differently, 
depending on the distance to the root.


Stefan 


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