Quoting [EMAIL PROTECTED]:
Also, there are a lot to improvements to do in MC in a quite short term, so I
share the point of view of Rémi, Don and some others when saying that MC
programs will fill the gap with classical programs in 19x19. And this can be
soon. Now, it is the work of the
Quoting David Fotland [EMAIL PROTECTED]:
My point with the file I attached is not that it's a difficult position.
These fights are incredibly easy if you just add a few dozen lines of code
to count liberties correctly. To me it's as if a weak chess player says, my
program doesn#8217;t need to
Quoting [EMAIL PROTECTED]:
Now my feeling is that the improving random simulations part of
this work is
promising. We have only done very few steps in this direction, and it gives
quite convincing results. It was what I meant in the random distribution
discussions we have in this list. I am
Quoting Don Dailey [EMAIL PROTECTED]:
I would love to see such a tournament, but the UCT programs could not
take full advantage of the extra time. As you see, we run out of
memory after a minute or two!
Valkyria can prune the tree but not indefinetly. I think it would at least be
able to
Quoting Chrilly [EMAIL PROTECTED]:
Maybe there is a logical flaw in my calculation. In this case it
would be nice if one of the UCT-programmers explains were all this
memory is used.
Valkyria currently preallocate 2 million records for the nodes of 28 bytes
each which is about 50 MB. I
Quoting [EMAIL PROTECTED]:
on 9x9 boards. To make a long story short, I didn't see any evidence
that this algorithm is fundamentally disadvantaged in handicap games.
In fact, I agree with Remi's view that it is particularly *well*
suited to handicap games compared to territory based
Quoting Christian Nilsson [EMAIL PROTECTED]:
Yes, in chinese rules you need to compensate white for the extra area
you gain from the actual stones. The handicap is only meant to be the
extra strength/stability.
One can of course ignore this for the server. I just wanted to make
sure all
Quoting Don Dailey [EMAIL PROTECTED]:
The simplest thing is to just explain it on a web page, but there is no
explicit
way to tell the programs that white is being compensated (or not) for
the
handicap stones and that bothers me.
The first step is to inform future programmers of the
Quoting [EMAIL PROTECTED]:
I'm curious about the full width depth and the principal variation depth to
compare UCT wilth alpha-beta.
The comparison is not so easy to do I think, because using MC as an
evaluation
function for alpha beta, you have to do several simulations for one
evaluation
I am currently working with different pruning methods for 19x19 go.
What worked
for Valkyria on 9x9 become much to slow on 19x19 where full board
evaluation of
several 100 moves simply does not work. During christmas I was able to
prune the
number of candiate moves to perhaps a factor 4-20
Quoting Sylvain Gelly [EMAIL PROTECTED]:
Hello Magnus,
I am glad to hear your experiment in 19x19.
Your pruning is based on expert go knowledge or another statistic?
Do have some statistics of the level of your pruning method against another
program (let's say gnugo :)) in 19x19?
There are
Quoting Sylvain Gelly [EMAIL PROTECTED]:
But often it also suddenly pick a really bad move and play it so the
descrioption above is a little idealized.
Did you try picking the move with the highest number of simulations rather
than the higher average? This only modification gave MoGo a +10%
It is true that MC-programs has a bias towards overconcentration. But...
1) A improvements to the simulations of MC-program as implemented by MoGo and
Valkyria does diminish the problem. In fact most of the strength of these
programs from doing that. I think it is next to possible to explicitly
Two qick comments:
Quoting Matt Gokey [EMAIL PROTECTED]:
Jacques Basaldúa wrote:
Very good analysis and I would like to contribute a 4th reason:
against scalability of global search MC/UCT. If the simulation is
500 moves long (Chinese rules with recaptures, etc.) the observed
variance at an
Quoting Matt Gokey [EMAIL PROTECTED]:
Magnus Persson wrote:
Quoting Matt Gokey [EMAIL PROTECTED]:
I was wondering if anyone was combining an opening library with MC/UCT
by running a large number of the simulations and storing the results.
This seems like a pretty natural extension to save
Quoting Heikki Levanto [EMAIL PROTECTED]:
On Wed, Feb 07, 2007 at 04:42:01PM -0500, Don Dailey wrote:
In truth the only thing that matters is to increase your winning
percentage - not your score. There seems to be no point in tampering
with this.
I guess I must accept the wisdom of those
Quoting Don Dailey [EMAIL PROTECTED]:
Doing 8 searches is time-consuming, but I really prefer a book
that has a LOT of variety.
This is also one reason I now hand edit my book. Every time I correct a
bad move
there are often several ways of playing that I cannot tell which is better or
Quoting Don Dailey [EMAIL PROTECTED]:
I think there are 15 first moves in 9x9 go if you factor out the
symetries.
UCT isn't good at evauating all the moves, it will pick one of them and
spend most of it's time on it.But you could search each 1 at a time.
The UCT programs are memory bound,
Quoting Chris Fant [EMAIL PROTECTED]:
I understand that allowing multi-stone suicide seems like a bad idea,
but because it makes board repetition much more unlikely, it seems
like a good idea.
I do not understand how you get a problem of board repetition, and how
multi-stone suicde help with
Quoting Tapani Raiko [EMAIL PROTECTED]:
In 3D Go, you need a surface of stones to surround space but just a
string of stones peeking in to ruin it. In normal 2D Go, you surround
area by strings and ruin area by strings, so there is a nice balance. My
guess is that Go in any other dimensionality
Quoting Heikki Levanto [EMAIL PROTECTED]:
I have never really understood the idea in all-in-first. That seems to
fly in the face of the common sense idea that the order of moves is
important. But perhaps I have got it wrong in my mind. I will have to
study more.
Actually early in the game the
Quoting Don Dailey [EMAIL PROTECTED]:
Do you think any version of gnugo is suitable as an anchor?
My problem with Gnugo is that it might be too deterministic. It is in general
easier to overfit the parameters to gnugo than an MC-program. But perhaps the
gnugo team could make a version that at
the weaker the player the more annoyed they get with MC-programs.
Stronger players knows when the game is over so when the bad moves comes it
does not matter to them. Weaker player simply do not see that is is all over.
-Magnus
--
Magnus Persson
Berlin, Germany
http://www.phmp.se (Under construction
Quoting Darren Cook [EMAIL PROTECTED]:
9x9 *is* played by professionals, at least in Japan, but naturally with
neither big prize money, nor students wanting to pay to learn it, it is
not played that seriously, and usually with quick time limits.
You can find 9x9 pro games here (but it might
Quoting Darren Cook [EMAIL PROTECTED]:
My conclusion is that random playouts will never produce a very strong
player (within realistic resource limits); I now see why heavy playouts
performed so much better in Don's experiments. I also suspect the
playout style may need to be modified for
Thanks, for sharing this early!
Everything in this paper makes perfect sense, and is well written.
Reading it is
like finding the last pieces of a difficult puzzle.
I do however have some problem with the math of section 2.5 A
Minorization-Maximization Algorithm. I have a feeling that a lot of
Yes, now I understand. I think what made it hard for me conceptually was that
P(Rj) can be rewritten n different ways for each feature ci 1 = i = n. I had
this problem with your example too. I first thought that the lines with the
factors were arbitarary, but then I realized that each line goes
Quoting Peter Drake [EMAIL PROTECTED]:
In previous versions of Orego, I have added one node per playout. I
just changed that to add a child to a node only if that node has at
least A runs, where A is the area of the board (e.g., 81). This seems
to make the program stronger, if only because
Quoting Jason House [EMAIL PROTECTED]:
Looking at a single color, the winning percentage seems to shift by
0.2 to 0.4%... About what I'd expect to see. What confuses me though
is how to interpret the jump back and forth as the color changes
(about 8%). Are the percentages always the winning
Congratulations to Steenvreeter!
I looked at the games against MoGo and Crazystone to see what this
engine might
do. But it is really hard since most moves played by the top programs
are quite
good.
In the second game against CrazyStone it played like a weak MC-program in the
opening -
Quoting Sanghyeon Seo [EMAIL PROTECTED]:
2007/6/14, Magnus Persson [EMAIL PROTECTED]:
Quoting Sylvain Gelly [EMAIL PROTECTED]:
Hi Darren,
After white (mogo) H2, MoGo was estimating 74%, and expecting:
H2 G1 H3 B1 A1 B3 H1 F8 B5 H4
Then black played H3, and estimation increased to 81
But I would still like to know how many MC evaluations it would take
until all corners look at least somewhat similar... I bet that is many
more than we see used currently - if it ever gets there.
The approach I take in Valkyria is radically different. I simply prune all
symmetric moves. For
/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/
complicated for Viking, so in the end I
disabled that
code.
-Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Quoting Jacques Basaldúa [EMAIL PROTECTED]:
Hi, Magnus
Magnus Persson wrote:
Weak tactics is a problem of the playouts in my opinion. UCT as a
general search method has thus little to do with ladders and other
game specific details. If there are no tactical mistakes in the
playouts
Quoting Jacques Basaldúa [EMAIL PROTECTED]:
Low variance is the clue for improvement.
Here I agree with you completely.
I put it in my own words:
As I see it MC-evaluation has a signal hidden by a lot of noise.
This has some consequences.
In order to evaluate a position correctly a lot of
Quoting chrilly [EMAIL PROTECTED]:
I will play with Suzie at the forthcoming European Go championship in
Villach/Austria some 9x9 demonstration matches against everybody who
wants to play.
I want to prepare an opening book and I am looking for a 9x9 games
collection. So far I have only found
Quoting Joshua Shriver [EMAIL PROTECTED]:
What are and what is the difference in a fuseki and a joseki?
Fuseki is opening strategy. That is looking at a whole board position and find
the best move.
Joseki is just a common sequence of moves often local to a corner.
Joseki moves
should not
was 69653
12:35:43C-E genmove w
12:35:45E-C = j1
12:35:45C-S j1
12:35:47S-C play b RESIGN 47144
12:35:47C-E play b RESIGN
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer
Quoting Joshua Shriver [EMAIL PROTECTED]:
What kind of data structures do you all use for your engines, in
respect to board representation and move generation. I know in chess
bitboard, mailbox board[8][8], 0x88 exist all with their pro's and
cons. Are there similar concepts for Go?
I always
numbers and seeing if
they look uniform, or going back to scour the core logic (that passes all
the unit tests).
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer
by zero error.
Could this be affecting the performance? Perhaps at low levels like
this it has a noticeable effect?Would it make the program especially
vulnerable to an identical program that doesn't do this?
--
Magnus Persson
Berlin, Germany
of course mean that the
implementation was buggy or could be improved somehow.
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Quoting Jason House [EMAIL PROTECTED]:
2. First play urgency - Giving an artificial upper confidence bounds to
untried moves (I've seen references that 110% win rate is the right setting)
Where did you see that?
--
Magnus Persson
Berlin, Germany
.
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Aboute the Nakade problem:
1) There is in principle no problem to correctly handle nakade in
MC/UCT programs. It just a question of making the playouts do it.
2) But doing this requires some smart programming. I think all the
strong progams has been designed by the What can I do in less than
Quoting David Fotland [EMAIL PROTECTED]:
I'm working on Many Faces of Go 12 engine, which is an alpha-beta searcher,
and it's strong enough now I'd like to some stronger competition on 19x19
CGOS to test against.
Does anyone want to put up some strong programs? I know everyone prefers to
work
Quoting David Fotland [EMAIL PROTECTED]:
I hope it will get much stronger in the next few weeks as I wring out the
bugs.
It's nice to see Valkyria join. Anyone else?
Yes, I gave it a try and I might have found the reason it has been
playing so poorly on 19x19. My laptop overheat easily
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/
Quoting Gunnar Farnebäck [EMAIL PROTECTED]:
10k100k 1M
GNU Go CVS 0.079 0.387 0.475
This position seems to fit he extra knowledge of Valkyria well, but
not perfectly
500 1k 10k100k
Valkyria 0.76 0.760.64
I just want to make some comments about MC evaluation to remove some
common misunderstandings.
I have seen some complaints about misevaluation such as a program
having 65% chance of winning in a game which is lost and the other way
around. For example arguments has been proposed in line
Quoting Don Dailey [EMAIL PROTECTED]:
And yes, it slows down the play-outs. Still, the play-outs seem to
require a good bit of randomness - certainly they cannot be
deterministic and it seems difficult to find the general principles that
are important to the play-out policy.
Not all changes
So I wouldn't be surprised at all if at some point you'll see a
marriage of the best ideas of traditional Go programs and Monte-Carlo /
UCT. In fact, this is most likely already happening as these
Monte-Carlo programs use algorithms / ideas from the traditional
programs for tactics,
to be analyzed with go knowledge that
applies to all sizes of the game.
So feel free to argue that 19x19 has properties that are unique, but
in doing so please *specify* exactly what this means and why a
computer program has to deal with it to play really strong.
-Magnus
--
Magnus
Quoting Mark Boon [EMAIL PROTECTED]:
On 22-jan-08, at 11:33, Magnus Persson wrote:
So feel free to argue that 19x19 has properties that are unique,
but in doing so please *specify* exactly what this means and why a
computer program has to deal with it to play really strong.
Would
Quoting Heikki Levanto [EMAIL PROTECTED]:
I agree on this _only_ if the UCT check all possible moves.
If not one can be limited by the quality of the playout.
I think we may be confusing two different things here:
a) Using all possible moves in the playouts to evaluate a leaf in
the
Quoting Heikki Levanto [EMAIL PROTECTED]:
But you still prune moves like filling a one-point eye. We know that there is
a pthological case where that indeed is a correct move. So Valkyria will
never converge to perfect play even with unlimited CPU power.
Yes, this is a known bug. :)
But, I
Quoting Heikki Levanto [EMAIL PROTECTED]:
Of course we can wait until we get more data. I just wanted to share my
observation that the curves seem to change around the level where MC playouts
tend to flatten out, and hear if anyone would have some insightful comments
to that. Even with the risk
Quoting Gunnar Farnebäck [EMAIL PROTECTED]:
I have never managed to implement RAVE successfully. It made my
program significantly slower but no stronger even at a fixed number of
simulations.
I get a small effect from RAVE, My rationalisation is that if the
program is rich with other
Quoting Don Dailey [EMAIL PROTECTED]:
My feelings on this seem to match at least one source:
Look here:http://senseis.xmp.net/?Komi
Here is an excerpt:
It is widely believed that the correct komi is independent of board size
for all but the smallest boards. For area scoring, this
Hi, here comes the simple explanation, but some more data as indicated
below might of course empirically overturn this.
There are 81 points to split.
If black has 44 and white 37 points then white komi 7 there is jigo.
But when black get 1 point more white also get one point less. The
Quoting steve uurtamo [EMAIL PROTECTED]:
the thing that got me thinking about this is that i've never seen an MC
player really play out a ko fight. (or perhaps they are in their own cryptic
MC way that i can't see).
It takes two to dance a Tango! For example ko fights on 9x9 occur late
in
Attached is an sgf-game of a long kofight on 9x9 between Valkyria and
Gnugo. Valkyria of course wins with 0.5 otherwise it would probably
not have been such a nice example of a long kofight.
-Magnus
kofight318392.sgf
Description: application/go-sgf
Quoting Mark Boon [EMAIL PROTECTED]:
On 3-mrt-08, at 18:43, Don Dailey wrote:
I base that logic on my observations that once the score goes below 10%
for Lazarus, it is losing. It's extremely rare that it salvages a game
once the score goes below even 20%.
In which case I could argue
Quoting Don Dailey [EMAIL PROTECTED]:
Just to make it clear, the case we want to fix is the case where many
bots are programmed to resign. Lazarus will resign when the score is
below 1% (and has remained so for a couple of moves in a row which is
probably just a superstition on my part to
Quoting steve uurtamo [EMAIL PROTECTED]:
cool. do you have any examples from a 19x19 game? that's what
i was referring to when i said that i've never seen an MC player
play out a ko fight.
Valkyria is unfortunately way to weak for 19x19. My argument is more
that in principle MC programs
Quoting Christoph Birk [EMAIL PROTECTED]:
On Tue, 4 Mar 2008, Don Dailey wrote:
I really believe the source of peoples confusion on this is believing
that the program starts playing ugly random moves as soon as it is
down a little. But in fact, when it gets into ugly mode it is
because the
Quoting Christoph Birk [EMAIL PROTECTED]:
On Tue, 4 Mar 2008, Magnus Persson wrote:
But here you are missing the point that close to 0% winning
probability means that it cannot win against random play. The
opponent could lose only by killing his own groups.
I don't know why you (and Don
Quoting Don Dailey [EMAIL PROTECTED]:
When the child nodes are allocated, they are done all at once with
this code - where cc is the number of fully legal child nodes:
In valkyria3 I have supernodes that contains an array of moveinfo
for all possible moves. In the moveinfo I also store
Quoting Jonas Kahn [EMAIL PROTECTED]:
On Tue, Mar 11, 2008 at 09:05:01AM +0100, Magnus Persson wrote:
Quoting Don Dailey [EMAIL PROTECTED]:
When the child nodes are allocated, they are done all at once with
this code - where cc is the number of fully legal child nodes:
In valkyria3 I have
Quoting Ivan Dubois [EMAIL PROTECTED]:
Hello,
I think there is a very easy and straigthforward solution to the
nakade/seki problem, here it is :
For moves that are self-atari on a group that contains MORE than
5 stones :
Both in the tree and the playouts, strictly forbid them
Quoting Petr Baudis [EMAIL PROTECTED]:
Please note that pachi1 had a rather embarassing bug of starting the
random playouts with wrong color (so if the last tree node was black,
the playout would start with black as well). pachi2 has this bug fixed;
the ELO rating is still not settled, but so
A recurrent concept popping up in discussions on how to improve
playouts is balance. So I would like to try to share my philosophy
behind the playouts of Valkyria and how I define balance and how it
relates to the evaluation of go positions.
*Background
In an old school program the
Quoting Don Dailey [EMAIL PROTECTED]:
I have a response to this comment:
Still I think predicting the best moves is very important in the
tree part, but this may be much less important in the playouts, and
perhaps even detrimental as some people have experienced.
A class of bad
No, I can read it without problems on windows.
Quoting Jacques Basaldúa [EMAIL PROTECTED]:
and I still cannot read any mathematical expressions. I guess this
applies to all Windows users.
-Magnus
___
computer-go mailing list
Yesterday I noticed an odd phenomena in Valkyria wich was caused by
high selectivity and AMAF.
In this position
(;GM[1]FF[4]SZ[9]AP[SmartGo:1.4]
KM[7.5]
;B[ee];W[de];B[ed];W[df];B[ef];W[dd];B[dg];W[ge];B[dc];W[cc];B[cd];W[bd]
do right now is that I only use the first 70% of the
moves played in the simulations for AMAF, following the idea that
moves at the end of each simulations probably is only noise anyway.
-Magnus
--
Magnus Persson
Berlin, Germany
___
computer-go
Quoting Olivier Teytaud [EMAIL PROTECTED]:
Also, I've met people claiming that
- they need a constant 0 for exploration;
I use 0.1*Sqrt( ln(totvisits)/(5*Visits));
The 5 in the equations is there for historical reasons.
But I think the advantage I get from a constant 0 is so small it is
I went through the problems with Valkyria.
Right now it can do 32 out 50 where it had to think more than 10
seconds on perhaps 2 of those problems it solved.
But I do recommend to go through these problems by hand. At least one
position had the first move right but it seemed very week on
I have checked if there is a difference for Valkyria in using
confidence bounds or just greedily search the move with the highest
winrate. This is Valkyria 3.2.0 using 512 simulations per move against
GnuGo 3.7.10.
UCT_K Winrate SERR
0 58.82.2 (greedy)
0.0156.82.2
0.1
I run it with
gnugo3.7.10.exe --mode gtp --chinese-rules --score aftermath
--capture-all-dead --positional-superko
Which is the default level which I do not know what it is.
-Magnus
Quoting David Fotland [EMAIL PROTECTED]:
What level for gnugo 3.7.10?
Quoting Michael Williams [EMAIL PROTECTED]:
I'm curious what the winrate of the bug-fixed version is over the
original version.
The last version with bugs was Valkyria3.2.0 with 2216 Elo on CGOS,
whereas the new version Valkyria3.2.1 currently has 2255. It is doing
really well against
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
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
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
enough
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 mailing list
be 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/
/computer-go/
--
Magnus Persson
Berlin, Germany
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
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
___
computer-go
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
priority 7
On Sun, 2008-08-03 at 00:26 +0200, Magnus Persson wrote
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'm
on the 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
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
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
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
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
Some months ago someone published a set of LD 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
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
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/
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
1 - 100 of 164 matches
Mail list logo
