oo embarrasing to mention?
Stefan Kaitschick
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Permutating through liberties in a semiai seems especially painful from a
human perspective.
And doing so in multiple fights, without separating them somehow, is
ofcourse much more painful still.
Maybe someone will find a way of destilling the concept of leading or
trailing a semiai out of the M
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 s
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, yo
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, the
- Original Message -
From: "Dave Dyer"
To: "computer-go"
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 differen
Ofcourse they can know. They just have to check for it.
Those programs that do well against mirror go probably all do check for it.
What to do about it is a bigger problem.
My suggestion would be to make an extra search that assumes mirror play by the
opponent.
This has to be taken with a grain of
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
elusi
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 fe
"You are giving the program an arbitrary short term goal which may, or may not
be compatible with the long term goal of winning the game."
Don,
this is a very important consideration. How can an illusionary goal be better
than the real goal?
But I would argue that in the handicap situation, ca
"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
"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
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
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
combina
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 p
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,
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
t
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
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 ne
Ah. A "single path to victory" bottleneck. That makes it even worse than I
thought.
This is probably also the problem when mc bots judge an invadable to be
safe.
Stefan
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
se 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 ga
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)
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 i
tember 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_e
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 compl
My mistake. I misstook "start of the playout" for the board position.
Stefan
- Original Message -
From: "Mark Boon"
To: "computer-go"
Sent: Monday, September 14, 2009 11:42 PM
Subject: Re: [computer-go] Stone-Age
On Mon, Sep 14, 2009 at 10:55 AM, St
wow. great report.
Thanks.
Stefan
- Original Message -
From: "Hideki Kato"
To: "computer-go"
Sent: Tuesday, September 22, 2009 3:45 AM
Subject: [computer-go] Re: Congratulations to MoGoTW!
Nick Wedd: :
Congratulations to MoGoTW, winner of yesterday's KGS bot tournament.
My repo
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 definit
Stefan Kaitschick wrote:
About the move order problem: I'm skeptical about finding an efficient
full
board algorithm that detects the consequences of move order.
In this context, "the order of moves" does not mean a long sequence.
It means something like "If I al
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 f
> 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 defi
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 adde
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 subdirector
Very Cool. The mysterious part was "more interesting than programming go".
That seemed almost impossible.
Stefan
- Original Message -
From: "Mark Boon"
To: "computer-go"
Sent: Wednesday, October 14, 2009 11:23 PM
Subject: Re: [computer-go] Pattern matching
On Sat, Oct 10, 2009 at 5
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
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
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 genera
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 reso
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: comp
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
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 th
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 switch
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 "
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/
> 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 rando
I admit that I was narrowly parsing words.
I do like your "bermuda triangle" :-)
Stefan
- Original Message -
From: "Robert Jasiek"
To: "computer-go"
Sent: Wednesday, November 11, 2009 2:57 PM
Subject: Re: [computer-go] Re: Joseki Book
Stefan
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 mu
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
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
___
tter 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
wrote:
Crazy Stone (CS)
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
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
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: terr
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 countera
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"
To: "'computer-go'"
Sent: Monday, January 11, 2010 2:23 AM
Subject: RE: [computer
>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 diff
2010/1/19 terry mcintyre :
( 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 c
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 mailin
>
> 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 mov
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 t
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
o
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-delus
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 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 hum
>
> 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
> informati
> 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 na
What an unfortunate game against the human opponent. The trouble started
early with the tight low pincer at move 12.
The way black could press down on that move is what created the incentive
for CS to play the totally unreasonable invasion on the right a little
later.
Stefan
On Mon, Mar 16, 201
> > DolBaram won the 4-handicap game against Cho Chikun 9p!
>
> ..but unfortunately, CrazyStone lost the 3-handicap game against
> Cho Chikun. It made a dubious choice in the opening, but my guess
> is that more importantly, a corner semeai with approach liberty was
> left in one corner throughout
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 "res
> 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 aro
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
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-g
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&list
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 un
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
syste
Ok, he's no go expert. Blaming the difficulties on the board size, and lack
of clever (chess) programming. But it's still enjoyable to watch, thx.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
>
> 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 imposs
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
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,
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
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 candid
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
> 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 grea
According to a post in this forum it's 13*13.
http://lifein19x19.com/forum/viewtopic.php?f=18&t=12553
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
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
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&D ev
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 jus
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
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 i
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
wrote:
> Would the expected improvement be reduced training time or improved
> accuracy?
>
>
> 2016-06-11 23:06 GMT+03:00 Stefan
>
> 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.
B
>
> 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 i
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,
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/compute
> 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.
_
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
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 wo
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
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 1
98 matches
Mail list logo
