play against it and would appreciate any
comments about the new playing style from strong as well from weak
players.
Best
Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
ses 3 times before it resigns.
Of course, its not optimal :)
I wonder if there are others who haven't implemented the pass move
but found a nice way of handling seki situations during the search?
- Lars
-Ursprüngliche Nachricht-----
Von: "Magnus Persson"
Gesendet:
te.web.de/go/02/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer
Quoting Petr Baudis :
On Mon, Dec 14, 2009 at 10:37:24PM -0800, Peter Drake wrote:
It's easy to get confused -- different researchers use the terms
slightly differently.
They both gather data on moves other than a move made from the
current board configuration. I would say that AMAF stores sta
tern of some size. A joseki dictionary can
be seen as using very large patterns.
-Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I was not at all surprised by this result.
My thinking goes like this. On 9x9 the global situation is everything
that matters and precomputed information is not as important as
searching effectly is. Good 9x9 games are often very sharp fights
where then next move often violates good shapes
l probably make
it more biased than a usual light playout. Hard to tell before trying.
My feeling is that it might work surprisingly well but it might get
extremely biased in some situations, which perhaps can be fixed by
prefiltering of the move that can be played.
Magnus
--
Magnus Pers
. And then
copy many copies of that position and evaluate them massively in
parallel.
-Magnus
Quoting Petr Baudis :
On Thu, Sep 10, 2009 at 01:54:49PM +0200, Magnus Persson wrote:
This is very interesting. Here is a crazy idea, maybe it the same as
Marks but I want to take it to its extre
Quoting Petr Baudis :
On Thu, Sep 10, 2009 at 01:54:49PM +0200, Magnus Persson wrote:
This is very interesting. Here is a crazy idea, maybe it the same as
Marks but I want to take it to its extreme.
Since AMAF values are so helpful, perhaps one can let go of the idea
of sequential play
__
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Drake
http://www.lclark.edu/~drake/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
promise the long term
goal.
Stefan
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@compute
X
F - X O - X O O O X
G - X O - X O O - O
H O X O - X X O O -
J - - - O X - X O -
O to play
--
Magnus Persson
Berlin, Germany
___
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/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I also tried dynamic komi with Valkyria a long time ago. It failed. I
did not waste much time on it. Anyway here are my opinions and
intuitions about it.
As usual I am open to been proved being wrong with some empirical
evidence along with a nice algorithm that I can steal and add to
Valk
your program handle this situation?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://w
seem like comparing apples and
oranges.
Christian
Magnus Persson wrote:
Quoting Darren Cook :
* The scaling behavior might be different. E.g. if Fuego and Valkyria
are both run with 10 times more playouts the win rate might change. Just
to dismiss an algorithm that loses at time limits that happ
Quoting Darren Cook :
* The scaling behavior might be different. E.g. if Fuego and Valkyria
are both run with 10 times more playouts the win rate might change. Just
to dismiss an algorithm that loses at time limits that happen to suit
rapid testing on today's hardware could mean we miss out on t
-Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
. * . .
|o o o * . . .
|. * * * . . .
|. . . . . . .
|. * . . . . .
Black to play and kill :)
Christian
On 01/07/2009 17:41, Magnus Persson wrote:
In this case one needs to check that after the two stones are
captured the capturing single stone can be recaptured bringing us
back to where we
necessary for life&death?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing lis
uter-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
;computer-go@computer-go.org
> >http://www.computer-go.org/mailman/listinfo/computer-go/
> --
> g...@nue.ci.i.u-tokyo.ac.jp (Kato)
> ___
> computer-go mailing list
> computer-go@computer-go.org
> http://www.computer-go.org/mailman/lis
literally mean using the win ratio (with one "dummy" win per
node) to decide paths through the MC tree? It seems that the best move
could easily be eliminated by a couple of bad runs.
Does this only work when using RAVE/AMAF?
--
Magnus Persson
Berli
Quoting Brian Sheppard :
What komi did you use? It is nice to have the sgf in addition to the
position.
It is 7.5, and I do not have the SGF. I will try to create SGF for future
posts, to make reproduction easier for all.
Could it be that Pebbles have trouble seeing that the semeai is won
a
Quoting Nick Wedd :
In message <20090622202905.utvbb8wkgk8cw...@webmail.phmp.se>, Magnus
Persson writes
I looked at the report and would like to give my opinion on why the
programs played as they did in the commented game between Zen and
Aya.
In the game white 106 threatens to c
Probably 1x1 patterns implies that different priorities are assigned
to the absolute position of empty moves. AMAF can be seen this way.
AMAF learns statistics of 1x1 patterns if the move is played in the
playout but ignores all information surrounding the move at the time
it is played. Ano
co.uk
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/ma
white wins 0.5 even if black gets everything else.
Could it be that Pebbles have trouble seeing that the semeai is won
after white C9. Valkyria expects black A8 after C9 which delays the
capture of the white stones. Sometimes Valkyria has (or used to)
problems evaluating such semeais.
-Mag
o mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
quot;create new groups" goals
_could_
be doable. (what is the "temperature" of an isolated stone ?)
AvK
Disclaimer RIVM
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Quoting Gian-Carlo Pascutto :
On Thursday 11 June 2009 13:16:42 Magnus Persson wrote:
Would this be a simple way of using many cores effectively?
I don't see what it has to do with multiprocessing.
Otherwise I cannot see how recursive UCT would be anything else than
an ineffe
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer
In all my test with Valkyria it is absolutely clear that strength
improves with more computational resources. On 19x19 it is even more so.
But I do think most programs has a wall in front of the mountain. And
this is *bugs*. Consider what would happen if a line of code in a
program resigns
of these ideas :-) ).
Best regards,
Olivier
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I think all principles I use in the time management for Valkyria came
up in this thread more or less.
1) Valkyria selects move that has been searched the most.
2) It is given a base time for example 20 seconds early on on 9x9 CGOS
3) The base time is adjusted down if the program is winning big.
ideas about how to extract more information from
trials.
Best,
Brian
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
Actually, MCTS-programmers should be happy with any timeconstraints
that does not make the program run out of memory, since a proper
MCTS-program should scale nicely no matter the time constraint. Maybe
an ultrafast tournament with a tenth of a second would favor Valkyria
on small boards bu
dsl02
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/com
Hi, as usual Valkyria seems to handle this position well at the price
of being a super slow program in general.
This is just one example of how it reacts.
After 100 simulations it treats F1 as the best almost always, having
searched 30 to 100 times. Perahps 50-70 times is the most common res
Some quick comments:
I did store the search tree with early versions of Valkyria, but then
I gave it up.
Problems:
1) Searching deeper did not seem to overcome inherent fuseki weaknesses
2) The memory cost became too high
Advantage:
1) Playing fast in the opening saves time. This is very go
Quoting Brian Sheppard :
OK, so you don't have to worry if you set c==0. It might even be best. Just
a note: in very preliminary
experiments, c==0 is not best for Pebbles. If longer experiments confirm
that, I presume it is because
Pebbles runs on a very slow computer and searches only small tr
ter-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
that people would have
something to play against and Brain might be able to get things tested.
I'm also updating the archives, since December though Feb is missing.
- Don
-Original Message-
From: Magnus Persson
Reply-To: computer-go
To: computer-go@computer-go.org
Subject: Re: [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/
Quoting Sylvain Gelly :
On Fri, Jan 30, 2009 at 9:29 AM, Magnus Persson
wrote:
Did you try to tune the bias constant at all or just took the one I posted?
I wrote it from memory and I believe it is in the range of possibly good
values, but it is certainly not optimal, I can be off by a
Quoting Sylvain Gelly :
On Wed, Jan 28, 2009 at 10:01 PM, Isaac Deutsch wrote:
And a final question: You calculate the (beta) coefficient as
c = rc / (rc+c+rc*c*BIAS);
which looks similar to the formula proposed by David Silver (If I recall
his name correctly). However, in his formula, the la
also fail miserably in such positions.
Best
Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Quoting Thomas Lavergne :
- the best play is a good only if played immediatly and very bad if
played later in the game :
- the first playout for this play resulted in a lost.
score and RAVE score will be very low and this play will never be
considered again until a very long time.
You
is too expensive to read ladders during playouts. I remember
that you have faster ladders search code so it might not cost you as much.
My playout code has no ability to undo a move or do any kind of lookahead.
David
--
Magnus Persson
Berlin, Germany
how this function should behave.
Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
This document is confusing, but here is my interpretation of it. And
it works well for Valkyria. I would really want to see a pseudocode
version of it. I might post the code I use for Valkyria, but it is
probably not the same thing so I would probably just increase the
confusion if I did...
Quoting Mark Boon <[EMAIL PROTECTED]>:
OK, things start to fall in place for me. I was wondering all this time
what would happen with the information of the simulations that happen
before expansion. So the answer is: nothing. But at least the result of
the playout gets percolated up the tree, s
Quoting Mark Boon <[EMAIL PROTECTED]>:
What is not exactly clear to me is what you mean by 'postponing
expansion'. Let me write it in my own words to see if that's what you
mean. When you have selected a best node based on the UCT + wins/visits
value which has no children yet, you first simply do
pass because I changed it so many times
and had to add a lot of kludges to avoid problems with older kludges
and so on...
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman
Quoting Mark Boon <[EMAIL PROTECTED]>:
Thanks for the comments Magnus.
On 20-nov-08, at 13:00, Magnus Persson wrote:
The way I understood the article, after a playout it updates all the
nodes at the current level of all the moves played during the playout
(if it's a win for the pla
I could find anything problematic with your specification so I just
make some comments.
Quoting Mark Boon <[EMAIL PROTECTED]>:
- When it reaches N simulations, the child of the root-node with the
best wins-visits ratio is played. I've also seen that simply the child
with the highest number of
need to do some
more testing to make a hard case for that.
Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
_
I use a method inititally from the Mogo team that sorts of randomizes
the position before running the heavy playout. One simply plays
uniformly random *non contact* moves. The effect of this is that it
preserves the shapes of stones on the board, but it prevents the heavy
playouts from play
Yes, Valkyria does a lot of ladder reading as well. Actually "pattern
matching" in the case of Valkyria is a little unclear, it is a
decision trees where the leaves are often procedure calls that looks
at a larger portion of the board. The ladder code is called for
various reasons in the tr
Quoting Hideki Kato <[EMAIL PROTECTED]>:
Heikki Levanto: <[EMAIL PROTECTED]>:
The way I understand it, modern Monte Carlo programs do not even try to
emulate a human player with a random player - obviously that would not work.
I believe CrazyStone's use of patterns does so and it seems
succes
slightly stronger on equivalent hardware using normal time controls.
If I turned off AMAF for Valkyria I would probably have to retune all
parameters to make a fair comparison, but I am quite sure that crudely
turning it off would be very bad.
Magnus
--
Magnus Persson
Berl
If white plays first from this position, Valkyria plays J2 which wins
100% of time.
If black plays first, black has initially sometimes 5% chance to win
for the best move but the chance goes down to 1% rather quickly.
I admit not reading this thread carefully enough to understand what
the
No, if there was a serious problem it would perhaps only happen for 1
in 1000 games. So it would be pointless trying to measure it. And some
of these problems only happens against extremely weak programs. At
least in my experience.
-Magnus
Quoting Michael Williams <[EMAIL PROTECTED]>:
I
Valkyria does, because is superheavy anyway! A lot of weird stuff can
happen near the end of the game against programs that play randomly. I
think I implemented it because I had to to make it play correctly in
some positions. But it was a long time so I do not remember the details.
-Magnus
I checked these variation myself and with valkyria and it seems to be
sensible.
-Magnus
Quoting Don Dailey <[EMAIL PROTECTED]>:
I took all the games played by Leela in my 6x6 experiment and applied
mini-max to them, taking the statistics at various depths into the
games.
Don't know if ther
Quoting [EMAIL PROTECTED]:
See comments below...
... bE3 wE4 bE1 wF3!!!...
Normally wF2 is played in the corner. But with wF3 white has the
option to play aggresively with wF1 which usually is a bad idea
because the ko fight risk to much. But on a small board things are not
normal...
Can I
senger
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I fear we are not talking about the same game. In case I made a
mistake in my email you get the sgf here:
(;FF[4]CA[UTF-8]AP[GoGui:1.1]SZ[6]
KM[2.5]DT[2008-09-30]RE[B+Resign]
;B[cc];W[dd];B[cd];W[dc];B[db];W[eb];B[de];W[ee];B[ed];W[ec]
;B[ef];W[fd];B[ce];W[cb];B[bb];W[da];B[ba];W[ff];B[fe];W[ca
I stubbornly always use x.5 komi because I do not like Jigo. in this
case it was 2.5. I do that simply because Valkyria is coded like that,
it cannot play with integer komi.
Quoting Christoph Birk <[EMAIL PROTECTED]>:
On Tue, 30 Sep 2008, Magnus Persson wrote:
...wF1 bE6 wF6 bF2 w
Quoting Ingo Althöfer <[EMAIL PROTECTED]>:
Hello Magnus,
interesting and strange.
I went through your constructed game (it is repeated here
without the in-between text)
bC4 wD3 bC3 wD4 bD5 wE5 bD2 wE2 ...
... bE3 wE4 bE1 wF3!!!...
... bC1 wC5 bB5 wD6 bB6 wF1!...
...bF2 wC6 bB4!
...wF1 bE6
I have been trying to see what Valkyria does. But it is a little
unstable when it reads deep at 6x6. It should not be a problem for
Valkyria but I have not had any time to search for the bug.
Anyway the 2.5 komi black should lose if Don is right. So I have the
following very cute complete g
Quoting Mark Boon <[EMAIL PROTECTED]>:
Playing out that fake ladder in the first game meant an instant loss.
Surprising. And embarassing. Any information on the number of
processors used?
The interesting question is if there is a silly bug or something more
sophisticated.
I have struggled
ails, while not elegant, rarely matter.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go m
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Quoting David Fotland <[EMAIL PROTECTED]>:
Can you put crazystone back on 19x19 so I can see if it is just a fluke
against fuego?
I added locality to the light playouts - play near last or second to last
move, and some code to handle long ladders in playouts. I dont think this
is anything unu
I will also run Valkyria on CGOS 13x13 over the weekend, (or long as
things are stable).
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
The program reivax on 9x9 CGOS seems to be strong but suffer from a
bug leading it to pass too early, and thus it often loses games
against weaker programs that do not resign.
-Magnus
___
computer-go mailing list
computer-go@computer-go.org
http://
Some months ago someone published a set of L&D problems made for MCTS
programs. Going through this I found a lot of serious bugs in Valkyria
where overly aggressive pruning removed tesujis (tesuji = move that
normally should be pruned).
After that Valkyria improved perhaps 50-100 Elo. But I
Quoting Jacques Basaldúa <[EMAIL PROTECTED]>:
When you detect self atari in the playouts (something I haven't
tried yet, but
from recent posts in this group I am convinced that it is an important issue)
a new problem arises: How can you score the board _fast_ at the end?
Valkyria makes a si
I looked at the last games played by rz-74, and it looks like a
MC-program given how how it plays in the opening (odd moves in the
center). I also doubt there are any traditional programs who can get
90% against gnugo on 19x19. Are there?
But it seems to overplay badly in the opening in the
Quoting Hideki Kato <[EMAIL PROTECTED]>:
Yes, UCT does. From my recent experiments with a delay
line (a fixed size FIFO queue) between a UCTsearcher and an MC
simulator with RAVE against GNU Go 3.7.11 level 0 on 9x9 (single
thread):
delay #po winsgames winning rateELO 1 sig
Quoting Don Dailey <[EMAIL PROTECTED]>:
Yes, UCT is easier to use with multiple CPU's because with additional
processors alpha-beta programs do wasted work, unless you are talking
about theoretical programs with perfect move ordering, which you aren't.
Nice that all is clear about alpha-beta p
strength of the program.
With 9x9 I have used many systems learned or handmade, but it all
boils down to that as been said earlier. It only works for a program
that does not change, since it overfits its own strengths and
weaknesses.
--
Magnus Persson
Berlin, Germany
I think most programs developed by people who did not write old scool
programs has serious problems with seki. Valkyria detects some basic
seki shapes, but has problems with "nakade/seki".
-Magnus
Quoting Erik van der Werf <[EMAIL PROTECTED]>:
You're right, my reply was sloppy (it seems I'
go
# -
%section server
server cgos.boardspace.net
port 6813
%section player
name Gnugo-3.7.10-a1
password somePassword
invokegnugo --mode gtp --score aftermath --capture-all-dead
--chinese-rules --min-level 10 --max-level 10 --positional-superko
prior
games:
/home/drd/bin/cgosview.kit -server cgos.boardspace.net -port 6813 &
- Don
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
interesting to see the difference.
Best
Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Actually it is only the updating of the webpage that does not work.
The programs play as usual.
Quoting Urban Hafner <[EMAIL PROTECTED]>:
Seems like it's down since the 29th.
--
Magnus Persson
Berlin, Germany
___
computer-go m
use UCT for positions
where the last played moved lost. Should'nt this work like a dream if
sequence 2 truly goes to 100% winrate directly after the wirst win is
scored?
-Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
comp
between these moves.
-Magnus
Quoting Peter Drake <[EMAIL PROTECTED]>:
Without the 10% random moves, would every playout from a given leaf be
identical?
Peter Drake
http://www.lclark.edu/~drake/
On Jun 17, 2008, at 3:14 AM, Magnus Persson wrote:
Valkyria plays uniformily the highest
really is beneficial. If it is it is probably really a small
change to winning rate.
Magnus
Quoting Carter Cheng <[EMAIL PROTECTED]>:
I hope you don't mind me chiming in here. I think I asked this
question quite recently on the mailing list and the reply I received
from Magnus Pers
Quoting Carter Cheng <[EMAIL PROTECTED]>:
Is UCT really that good at finding the best move in alot of situations?
The search algorithms do not find the best move. They prune the bad
ones. The quicker and more reliably bad moves can be pruned the less
candidates remain to be chosen from. T
ff and you can get away with small batches and
gain something else. You have to test and see what happens.
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Quoting Carter Cheng <[EMAIL PROTECTED]>:
1) How typically do UCT bots score simulations quickly? I am not too
familiar with Chinese scoring rules.
In the end of a random games. There are only Black stones and Black
Eyes, as well as White stones and eyes. If your playouts are smart
enoug
Quoting David Fotland <[EMAIL PROTECTED]>:
So I'm curious then. With simple UCT (no rave, no priors, no progressive
widening), many people said the best constant was about 0.45. What are the
new concepts that let you avoid the constant?
Is it RAVE, because the information gathered during the
I have already posted the following results. The results shows the
winrates of Valkyria 3.2.0 against gnugo at default strength.
512 Simulations per move
UCT_K Winrate SERR
0 58.82.1 (Winrate only)
0.0156.82.2
0.1 60.92.2
0.5 54.22.2
1 50.62.2
Wit
1 - 100 of 216 matches
Mail list logo
