Looks like you're making good progress. Apart from the time gained training,
you'll probably get a similar speed up when using the DNN during play? I'm
curious when you'll see improvement in play outweigh the extra computational
cost.
Mark
> On Apr 26, 2016, at 9:55 PM, David Fotland
Somehow reading this list has fallen off my radar...
I looked at the Numenta stuff some years ago. Jeff Hawkins' book On
Intelligence is an inspiring read and has some really good insights. So when
he started Numenta I had considerable expectations. However, what I thought
were the most
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
I took AMAF as the process to consider all the moves regardless when
they were played in the sequence (although a slight discount for later
in the sequence seems to help a little) whereas RAVE is using an
undefined method to favour some nodes over others prior to expanding
them. The reason (as far
The relative values look about right. But I remember getting much
higher numbers. Did you run the Java versions with or without the
-server parameter?
Mark
On Mon, Dec 14, 2009 at 11:00 PM, Brian Slesinsky br...@slesinsky.org wrote:
Okay, I added a few more timings (playouts / second, very
I've found that AMAF gives very little boost with light playouts,
you really need something fairly meaningful already to get any kind
of real boost. To have at least 10% chance of beating GNUGo with
reasonable time per game (to be able to play-test your bot), I think
you can't avoid doing a
On Dec 13, 2009, at 8:08 AM, Denis fidaali wrote:
So it would certainly be usefull, if people could agree on a reference monte
carlo tree bot (and provide some reference implementations in popular
langages).
It would obviously be based on the reference light-bot.
This is what I
On Tue, Dec 8, 2009 at 8:37 PM, David Fotland fotl...@smart-games.com wrote:
I use two values. I never even occurred to me to use three.
I use one, it never occurred to me to use two :)
At the time I'd never heard of Zobrist, but I used to use a single
value for each point to look up Joseki.
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
On Nov 19, 2009, at 1:24 AM, Nick Wedd wrote:
So a bot which appears on KGS, gets rated as 25k, plays hundreds of
games, and then improves to 15k, is going to do a lot of damage to
the rating system.
What happens when all those beginners that start at 25k improve, many
of them well
Roger Penrose thinks the human brain can do things a Turing machine
cannot. (Note: I don't say 'computer'.) He claims it's due to some
quantum-physical effects used by the brain. I doubt his ideas are
correct, but he did have a few interesting chess-positions to support
his theory.
On Oct 27, 2009, at 7:41 PM, Hideki Kato wrote:
IMHO, Jeff's idea is still very interesting while
the implementation by the staff in Numenta have been going to not
right direction.
That was also my opinion. What I thought was strange is that Numenta's
implementation doesn't have
On Oct 27, 2009, at 3:39 AM, Hideki Kato wrote:
I strongly believe that such patterns must not be only spatial
(static) but also temporal, ie, dynamic or sequence of pattens which
allow the player quickly remember the results of local fights or
LD.
I think that's exactly right. At least for
2009/10/24 Dave Dyer dd...@real-me.net:
At 10:12 AM 10/24/2009, Joshua Shriver wrote:
Came across this today, and since this is also an AI oriented list thought
some of you might enjoy it too.
http://www.techradar.com/news/world-of-tech/future-tech/the-past-present-and-future-of-ai-643838
2009/10/26 Don Dailey dailey@gmail.com:
2009/10/26 Richard J. Lorentz lore...@csun.edu
Yes, this group does not have a consensus at all on this. On the one hand
we hear that MCTS has reached a dead end and there is no benefit from extra
CPU power, and on the other hand we have these
2009/10/26 Don Dailey dailey@gmail.com:
Yes, you understood me right. I disagree with Olivier on this one. To
me it is self-evident that humans are more scalable than computers because
we have better heuristics. When that is not true it is usually because the
task is trivial, not
On Oct 19, 2009, at 7:04 PM, Petri Pitkanen wrote:
Not really a compuetr Go issue, but I do not think that great wall
is superior even when completed. It is not too bad but it needs a
definite strategy from wall owner. I.e building side moyos using
wall as a roof and hoping that the other
Also not Remi, but...
Numenta is a startup funded by Palm founder Jeff Hawkins. He started
it following up on his book 'On Intelligence', which I think is a very
interesting read. I'd suggest it as a reading to anyone considering
applying some form of Neural simulation to Go or any other problem.
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
Someone commented on it, so it must have come across OK.
Is it possible that your e-mail provider or e-mail reader decided to
not include the attachment? At least that's what 'skipped content'
seems to indicate.
If I need to repost or publish it in another way I'd be happy to do so.
Mark
On
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
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
Just being curious I decided to give it a swing to see if Fuego would
compile on a Mac. The configure scripts stops saying 'boost' is not
installed. So I downloaded the latest version of that (it's huge!) and
set a BOOST_ROOT environment variable, but it still says it can't find
it.
On Sep 6, 2009, at 4:20 AM, Don Dailey wrote:
I tried both llvm-gcc and CLANG. I did not have any trouble
getting them to work for my 64 bit chess program.
I didn't try too hard, but neither is producing executables as fast
as gcc. llvm-gcc is the slowest about 20% slower than gcc
On Sep 5, 2009, at 4:41 AM, terry mcintyre wrote:
Found an interesting article on Snow Leopard at Ars Technica ... 20-
some pages.
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars
Of interest to Computer Go programmers: the addition of blocks to C,
which allow closures and
2009/9/1 Peter Drake dr...@lclark.edu:
On Sep 1, 2009, at 8:11 AM, David Fotland wrote:
I don’t think any of the strong programs use pseudoliberties.
Interesting! Can those involved with other strong programs verify this?
My board code is descended from my Java re-implementation of libEGO. I
On Tue, Aug 18, 2009 at 10:24 AM, Brian Sheppardsheppar...@aol.com wrote:
What do you do in your program?
Not using the mercy-rule.
I believe you can gain 10%-20% performance on 9x9 using a mercy-rule.
But in its most simple form I don't see how it can be used reliably. I
don't know if the
On Aug 15, 2009, at 6:24 AM, Heikki Levanto wrote:
You can also use board-sized bitmaps. Merging is a trivial OR
operation.
I've seen bit-maps mentioned many times, but is there any evidence
it's faster than a 'traditional' implementation?
Mark
On Aug 15, 2009, at 8:52 AM, w...@swcp.com w...@swcp.com wrote:
You will just have to jump in and read some code or write
your own to fully understand. I recommend reading the
gnugo source, which is pretty darn good.
But that's exactly the kind of work you'd want to avoid if there's no
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
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
2009/8/12 Don Dailey dailey@gmail.com:
If the program makes decisions about the best way to win N points, there
is no guarantee that this is ALSO the best way to win N+1 points.
Although this is obviously true, that doesn't automatically mean it's
not the best approach. Because there's a
There are many ways to skin a cat. I allocate them dynamically, but
recycle the nodes no longer needed for performance. And I use 'aspect
programming' that optionally (after a recompile) checks for dangling
pointers.
Mark
On Jul 14, 2009, at 5:06 AM, Carter Cheng wrote:
This is
On Mon, Jul 13, 2009 at 7:54 AM, David Doshayddos...@mac.com wrote:
My personal opinion is that way too much effort is put into optimizations
that used to be very important when memory was small, but now is nice but
not really needed. My bias is that efficiency is a good thing as long as it
I have thought about this kind of thing a bit, but it's hard to
formulate a general solution. What happens is when you prohibit
certain 'bad' moves is that you slant the result in favour of the side
with more 'bad' moves. This gets to be a problem in situations where
there are few moves to
On Fri, Jul 3, 2009 at 7:28 PM, Ray Tayekrta...@ca.rr.com wrote:
please join us for an afternoon of surf, sand, and go.
saturday, august 22'nd 2009, from 11 a.m. to 6 p.m or so, at 26918 malibu
cove colony drive
Sounds good. If the earth wasn't curved maybe we could wave at each other :)
You always need to be extremely careful about these kind of
heuristics. Especially in MC programs they can be detrimental very
easily.
But I believe you can come up with a reasonable rule to prevent some
self-atari's. I have one which is something along the following lines:
- puts itself into
I've also tried a variety of ways to use point-ownership in
combination with RAVE. By no means was it an exhaustive study, but I
failed to find an intuitive way to improve play this way.
I didn't try enough to be able to come to hard conclusions, but at the
very least it didn't turn out to be
On Wed, May 27, 2009 at 7:33 PM, David Fotland fotl...@smart-games.com wrote:
GPL is not infectious through looking at source code, but I didn't want any
appearance of wrongdoing. And I was put off a little by Stallman's
rhetoric.
David
I have mostly stayed away from GPL projects for the
I'm a bit late reading this thread and the discussion seems to have
veered from the original topic a bit.
As to the CPU vs. memory discussion, it's not so clear-cut to me that
CPU speeds are improving faster than memory. Twenty years ago you had
CPUs in the 4-8Mhz range and around 1Mb of memory.
On Sun, Apr 26, 2009 at 11:54 PM, Łukasz Lew lukasz@gmail.com wrote:
Hi,
Have any one of you tried uct + capture heuristic?
Is it stronger? How much?
From memory I'd say it was winning about 80% against plain UCT. But
only capture if it can escape (which means it can make three
/28 Mark Boon tesujisoftw...@gmail.com:
On Sun, Apr 26, 2009 at 11:54 PM, Łukasz Lew lukasz@gmail.com wrote:
Hi,
Have any one of you tried uct + capture heuristic?
Is it stronger? How much?
From memory I'd say it was winning about 80% against plain UCT. But
only capture if it can escape
On Mon, Apr 6, 2009 at 10:54 AM, Isaac Deutsch i...@gmx.ch wrote:
This leads us to the question if groups in average have
=10 or 10 liberties... :)
Without actually having done any tests or measurements, I'd guess it's
much less than 10. More like 4.
Mark
On Thu, Apr 2, 2009 at 5:14 AM, w...@swcp.com wrote:
Isaac,
I implemented about 6 way to track liberties,
a couple years ago, and measured the running
performance, and by far the best is also the
simplest: keep an array of liberties for each
chain, and do a simple linear search.
This may
I can confirm, with a bit of optimization, counting real liberties is
only marginally slower than counting pseudo-liberties. So there's
really no benefit that I can see from using pseudo liberties.
Mark
On Wed, Apr 1, 2009 at 8:49 AM, Álvaro Begué alvaro.be...@gmail.com wrote:
When John Tromp
2009/3/23 Yamato yamato...@yahoo.co.jp:
Sorry for responding to the old topic.
Mark Boon wrote:
Other than that, I'd take a different approach:
- play out as usual. Instead of counting stones + eyes on the board,
you count eyes + prisoners + nr-opponent's passes during playout.
- don't count
On Tue, Feb 17, 2009 at 8:35 PM, George Dahl george.d...@gmail.com wrote:
Really? You think that doing 20-50 uniform random playouts and
estimating the win probability, when used as a leaf node evaluator in
tree search, will outperform anything else that uses same amount of
time?
You'll
Just curious, did you ever read 'On Intelligence' by Jeff Hawkins?
After reading that I got rather sold on the idea that if you're ever
going to attempt making a program with neural nets that behaves
intelligently then it needs to have a lot of feed-back links. Not just
the standard
I don't know if that's what you're already looking at, but recently
Apple announced their new version of OS X called 'Snow Leopard' which
supposedly focuses mostly on improvements in the use of multiple
processing. And that includes the GPU. The module that binds it all
together is called
I had a little spare time to look at it. It seems indeed I forgot to
update the GoEngineGTP.jar file last time I made some changes. This
was easy to fix even from here and I think it should work now.
Just as a note, if you want to change the number of playouts to 50K,
you need to change
On Sun, Feb 8, 2009 at 3:02 PM, Isaac Deutsch i...@gmx.ch wrote:
Hi,
Can you explain what minimumNrNodes and nrSimulations do? In my program I
play 50k games regardless of the number of nodes, so I would like to adjust
this accordingly.
minimumNrNodes is the number of games played out.
/MoveIterator
Original-Nachricht
Datum: Sat, 7 Feb 2009 09:30:53 -0200
Von: Mark Boon tesujisoftw...@gmail.com
An: computer-go computer-go@computer-go.org
Betreff: Re: [computer-go] How to properly implement RAVE?
You can get everything here:
http://plug
I'm currently tied up but you can get my MCTS implementation, which
includes RAVE, and set it up to play 50K playouts. It's only a matter
of setting the right number in the configuration file.
You can also use it to play through two-gtp, that way you can test an
awful lot faster.
Mark
On Fri,
I think as long as you don't count passes during exploration (or game-
play) but only count passes during playout as points for the opponent,
I don't see why you would need any adjustment.
As to unsettled groups, that's what the second phase is for. Playout
acts as the second phase in this
On Feb 3, 2009, at 2:34 PM, Heikki Levanto wrote:
All in all, I think this is a messy and unreliable solution to a
problem I
have not seen happening.
For what it is worth I vote against client-side time controls.
Maybe you haven't seen it. That doesn't mean it doesn't exist.
I've lost
I think I've seen people post about playing with Japanese rules in
relation to MC programs. Correct me if I'm wrong, but I think I saw
people do some adjustment in that case. Does that mean they actually
use Chinese scoring internally?
Mark
___
I haven't gotten very far yet in incorporating many of the suggestions
published on this mailing-list into the MCTS ref-bot. As such I feel I
still have a lot of catching up to do when it comes to MC programs,
mostly due to lack of time.
But I had an idea I wanted to share as I haven't
On Feb 2, 2009, at 9:57 AM, Isaac Deutsch wrote:
They are not pattern based playouts, but as I said uniformly random.
I reckon the effect of RAVE is less with these?
My MCTS implementation sees a gain of 200-400 ELO from RAVE using
uniformly random moves. 400 gain (90% win-rate) for 2K
On Feb 1, 2009, at 11:29 AM, Erik van der Werf wrote:
Something else for the discussion. I would like to have a rule about
mandatory displaying the thinking process of the program so that both
operators have an idea of what is happening. Especially for remote
play I think this is needed
On Jan 21, 2009, at 10:23 AM, Magnus Persson wrote:
Quoting Thomas Lavergne thomas.laver...@reveurs.org:
- 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
On Jan 21, 2009, at 11:53 AM, Olivier Teytaud wrote:
Here, we have a non-zero initialization of the number of wins, of
the numbere of simulations, of the number of Rave-wins, of the
number of Rave-losses.
We have then a 0 constant for exploration, but also an exploratory
term which is
On Jan 18, 2009, at 4:11 PM, David Fotland wrote:
I think it 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.
Yes, my ladder
On Jan 18, 2009, at 5:38 PM, Magnus Persson wrote:
In Valkyria I solved this by playing out the ladder on the playout
board, and store all changes on a stack. When the ladder undos moves
it just pop changes from the stack. In this way I can also use the
rich board representation of
Thanks for taking the time Sylvain. I took a quick look to see how
your pseudo-code compared to the reference implementation I made.
There are a few small differences, and I think the place(s) where I
deviated is exactly what confused Daniel Waeber.
The first difference is that when I
On Jan 17, 2009, at 5:41 PM, Sylvain Gelly wrote:
For the first difference you mention, as far as I remember it makes
a small but significant difference and is one of the main reason I
was talking about tricky details.
OK, I ran a test and after 1,000 games with 2K semi-light playouts I
On Jan 15, 2009, at 10:47 AM, Daniel Waeber wrote:
Thanks you. I think that I understand it now :)
On 23:21 Wed 14 Jan , Mark Boon wrote:
You have to understand that the 'start' variable really starts at the
root from the position for which we do the search. So all the moves
'below
On Jan 15, 2009, at 12:33 PM, Daniel Waeber wrote:
yes, but the weight/color maps stay the same for all updated nodes.
I think the first playoutNode (the one most deep inside the tree) only
should get amaf values for the random playout, the next one form
random
playout + from the first
On Jan 14, 2009, at 9:36 AM, Daniel Waeber wrote:
I have a question about the the part were the stats are updated.
(l.15-25). having an array of amaf-values in every node seems very
memory
intensive and I don't get how you would access these values.
You are right, it is memory intensive.
It's difficult to get hard data about this. Go is only the most
popular game in Korea. In other countries like Japan and China it
comes second by far to a local chess variation.
Possibly Chess is more ingrained in Western culture than Go is in
Asia, I don't know really. But Chess has the
On Jan 14, 2009, at 12:43 PM, Thomas Lavergne wrote:
Couting xiangqi and shogi players as chess players is a bit unfair...
Sorry if I caused confusion, I didn't mean to count those as Chess-
players. I just stated that to show that despite large population-
numbers in say China, most of
I'm not so knowledgeable about the ELO system and had a few questions
about how it's used by the CGOS server.
Firstly, on the CGOS server page there's an explanation of how it
works with a table of expected winning percentages vs. difference in
ELO ratings:
http://cgos.boardspace.net/
On Jan 14, 2009, at 2:15 PM, Rémi Coulom wrote:
Mark Boon wrote:
I'm not so knowledgeable about the ELO system and had a few
questions about how it's used by the CGOS server.
Firstly, on the CGOS server page there's an explanation of how it
works with a table of expected winning
On Jan 14, 2009, at 3:40 PM, Don Dailey wrote:
However, the best thing to do is to ignore that page and go the Bayes
Rated link which is updated every day. This is the total
performance
rating over all time of any player on CGOS. Everything is rated
together, even if you have only
On Jan 14, 2009, at 8:39 PM, David Doshay wrote:
Saving energy is a fine thing. Lets leave that to various hardware
engineers in the semiconductor industry. Or, if you think this is
such a grand idea then you should offer up the prize money and
then we can all see who comes to compete for it.
On Jan 14, 2009, at 10:55 PM, Daniel Waeber wrote:
Accessing the AMAF values depends on your implementation. The
following is a code-snippet from my MCTS reference implementation
that
updates the AMAF values in the tree:
if (_useAMAF)
{
IntStack playoutMoves =
On Jan 10, 2009, at 8:16 AM, Gian-Carlo Pascutto wrote:
Dave Dyer wrote:
I think general hardware limits are good, because they will permit
more teams to be competitive without altering the nature of the
competition.
So in effect, it's an admission that the strength of some teams should
be
The attached game played on CGOS was awarded a win for white due to an
illegal move. Black tried to play J3, which according to the game-
record is a ko. Nothing could be further from the truth...
Rather shocking really. What happened here?
Mark
684276.sgf
Description: Binary data
On Tue, Dec 16, 2008 at 12:20 PM, Jason House
jason.james.ho...@gmail.com wrote:
When thinking about the apparent strength loss, I came up with a potential
theory: consistency. With more simulations, noise has less of an impact. I'm
going to guess that the known bias of AMAF leads to blunder
By the way, what does scratch100k.sh look like?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
- Show quoted text -
On Tue, Dec 16, 2008 at 11:35 PM, Weston Markham
weston.mark...@gmail.com wrote:
On Wed, Dec 17, 2008 at 1:32 AM, Mark Boon tesujisoftw...@gmail.com wrote:
By the way, what does scratch100k.sh look like?
../gogui-1.1.3/bin/gogui-twogtp -auto -black java -jar jrefgo.jar
On Tue, Dec 16, 2008 at 8:52 PM, Michael Goetze mgoe...@mgoetze.net wrote:
I wish people would stop spreading such incorrect information. The
correlation between professional ranks and playing strength is quite bad,
and EGF 7dans are not, generally speaking, professional strength.
I'm not
My understanding of the PlayStation is that it's a Cell architecture,
with one main CPU and six auxilary processing units with limited
capability. Of course you don't need much for something to do MC
playouts, so it seems a very suitable architecture. So 8 PS3s gives a
total of 56 CPU's.
On Mon, Dec 15, 2008 at 12:37 PM, Don Dailey drdai...@cox.net wrote:
So I think we have to embrace the fact that hardware is a part of these
kinds of advancements. In fact I have always believe this anyway, the
whole idea behind computing is to perform simple and stupid operations
very
Weston,
Although those result sound intriguing, it also looks like a
convoluted experiment. I wouldn't call gnu-go an expert judge,
although it is an impartial one. The fact that it says that the 5K
ref-bot is ahead after 10 moves 46% of the time alone makes it suspect
in my eyes. But it is
People sometimes play all kinds of silly things. It's not necessary to
anticipate it all, just make sure you can keep playing reasonable
moves when the other side plays strangely. There's little problem with
continuing to play in the corners and sides when your opponent decides
to do something
Well, I don't know about 'latest' or 'greatest', but I've posted a
Java implementation of Don's reference definition a while ago. And my
recent effort to come to a MCTS reference implementation is there as
well.
http://plug-and-go.dev.java.net
I don't think the site has seen much traffic
On 3-dec-08, at 06:09, Sylvain Gelly wrote:
What I did (was a long time ago, I don't know if it is still used in
Mogo), is to compute the m best moves every so often and most of the
time just do the max over those m moves.
m was on the order of 5, and every so often was an increasing
function
On 3-dec-08, at 10:31, Heikki Levanto wrote:
Having said that, I can't help responding to one detail:
I had seen people write about memory usage of the tree, but never
understood the concerns.
One thing to remember is that more memory use means more cache
misses, and
more access to the
At first blush, it sounds like a reasonable idea. However, as always
with these things, the proof of the cake is in the eating. So you'd
have to try it out against a ref-bot to see if it improves things.
You also need to keep an eye on time used, as it sounds a lot more
CPU intensive than
Yes, I asked that question.
So GnuGo already uses a comment-node to store the information in the
SGF tree. But twogtp uses information from the .tst file. So why the
difference?
On 2-dec-08, at 01:18, terry mcintyre wrote:
Someone recently asked about regression testing, and methods of
I have made some minor performance improvements and this is as far as
I intend to take this particular project. I might make some small
changes if necessary, but most likely I'll leave this largely
unchanged from now.
I had set myself as an arbitrary goal that it should do at least 20K
Just now I realized that I'm using the standard Java Math.log()
function in places where it computes the log(visits). In Java, this
log() function is actually the logarithm of base e, which I suppose
is normally actually written as ln(). When I read articles about UCT
and it says log(),
On 1-dec-08, at 18:55, Olivier Teytaud wrote:
I think it's now well known that Mogo doesn't use UCT.
I realize that i have no idea at all what Mogo do use for
it's MCTS.
A complicated formula mixing
(i) patterns (ii) rules (iii) rave values (iv) online statistics
Isn't that technically
Indeed, the scaling question is very important. Even though I think I
have AMAF/ RAVE working now, it's still not so clear-cut what it's
worth. With just 2,000 playouts I'm seeing a 88% win-rate against
plain old UCT tree-search without RAVE. At 10,000 playouts this win-
rate drops to 75%.
On 30-nov-08, at 16:51, Jason House wrote:
You've claimed to be non-statistical, so I'm hoping the following
is useful... You can compute the likelihood that you made an
improvement as:
erf(# of standard deviations)
Where # of standard deviations =
(win rate - 0.5)/sqrt(#games)
Erf is
I think I've seen some discussion a while ago about a set of tests
used to test playing engines. I suppose it would make sense to
compile such a set for the reference bots. Matching a win-rate and
game-length after 1,000,000 playouts is a quick first milestone for
verification that can be
Denis,
Thanks for the feed-back.
What you describe is pretty much what I do, with a small difference
that from A I don't assign any real scoring for the first move unless
A has had the minimum number of playouts before it expands further.
So assume that that limit is 10 playouts. For the
Thanks for posting that Remi. I do remember seeing that before but
somehow I didn't notice it when looking for RAVE-related stuff recently.
Mathematics is not my strong point, so I have a hard time making
sense of those formula's. I do get the gist that it uses a UCT value
and a RAVE value
On 28-nov-08, at 17:28, [EMAIL PROTECTED] wrote:
I would be very interested to see the RAVE code from Valkyria. I'm
sure others would be too.
I'm much more interested in a general concise description. If such a
description cannot be given easily, then I think there's little point
Denis,
A CGOS equivalent for Hex would probably be good to have. But since
the CGOS server software is open-source you can easily adapt it.
GTP you can simply use as-is, I don't see why that wouldn't work.
GoGui is also open-source and can possibly also be easily adapted to
Hex as well. But
1 - 100 of 249 matches
Mail list logo
