Hi Remi,
Thanks for the reply. There are so many parameters to tune and
heuristics to try, and having two types of search (playouts and the
MCTS) doubles the number of knobs! (More than doubles, as there is the
interaction to consider too.)
I did not try your position. But understanding seki is
On Feb 2, 2009, at 6:57 AM, Isaac Deutsch i...@gmx.ch wrote:
Hi Issac,
You should be more in the range of +200-300 ELO, at least with
pattern
based
playouts.
Sylvain
Isaac. They are not pattern based playouts, but as I said uniformly
random.
I reckon the effect of RAVE is less with
On Feb 2, 2009, at 9:40 AM, Jason House jason.james.ho...@gmail.com
wrote:
On Feb 2, 2009, at 6:57 AM, Isaac Deutsch i...@gmx.ch wrote:
Hi Issac,
You should be more in the range of +200-300 ELO, at least with
pattern
based
playouts.
Sylvain
Isaac. They are not pattern based
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
___
Mark Boon wrote:
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
Nick Wedd wrote:
I would like to se the time measurement done in the client. I find it
odd that cheat-proof client-side time is now standard for chess
servers, but too difficult for any Go server to implement.
In case of big network lag, client-side time may make the game too long.
The
Wow, thanks for all the answers! You're being really helpful.
Do you use UCT with a too large exploration term?
That's a good idea. I actually use a rather big value for c=0.5. I might try
lowering it. Thanks! (Precisely, the formula is c*sqrt(log(p)/c).)
My first (braindead) multi-threaded UCT
On Mon, 2009-02-02 at 18:09 +0100, Isaac Deutsch wrote:
I don't think many people realize that you have to play hundreds of
games just to be within 40 or 50 ELO with much certainty. If you
play
less than 100 games you could easily be off by over 100 ELO.
Maybe I'm a bit (a lot :)
About the thinking process log.
Enabling debugging options can result in serious performance loss. In my
system
only the admin thread can do such things as tree dumps and that makes
all other
pawn threads idle. I don't think such preventive measures are
justified. In case
of doubt, it should
Darren Cook wrote:
Was there a reason in not using criticality as a guide in playouts too?
Or just lack of time to experiment with it?
No particular reason, except maybe that it would be difficult to do, and
I do not really know how to implement it.
I am convinced that the idea of
I have about 200-300k games/move, so maybe the effect is even less. But,
maybe I still have a grave bug somewhere. I will check again.
Cheers, ibd
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
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
In message
262b2f900902010529r2ddec4afq31705bd9ccfda...@mail.gmail.com, Erik van
der Werf erikvanderw...@gmail.com writes
snip
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
In message 4985a9b2.7090...@univ-lille3.fr, Rémi Coulom
remi.cou...@univ-lille3.fr writes
Erik van der Werf wrote:
Hi Remi,
There is a simpler solution: do not allow remote play at all.
I would be in favor of this solution. But this has no chance to make
unanimity. Even with a strong
On Mon, 2009-02-02 at 09:40 -0500, Jason House wrote:
Also, I noticed your rank measurements were based on CGOS results
after relatively few games. It can retain significant bias for quite
a
while.
Yes, and you should go by the bayeselo page which is a better picture of
what is going on.
On Feb 2, 2009, at 12:09 PM, Isaac Deutsch i...@gmx.ch wrote:
Wow, thanks for all the answers! You're being really helpful.
Do you use UCT with a too large exploration term?
That's a good idea. I actually use a rather big value for c=0.5. I
might try
lowering it. Thanks! (Precisely, the
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
Hi Issac,
You should be more in the range of +200-300 ELO, at least with pattern
based
playouts.
Sylvain
Isaac. They are not pattern based playouts, but as I said uniformly random.
I reckon the effect of RAVE is less with these?
How many playouts per second do you get with each version?
On Mon, Feb 2, 2009 at 11:25 AM, Nick Wedd n...@maproom.co.uk wrote:
1.) A neural net cannot explain its thinking process because it does not
have any.
I have used artificial neural nets a lot in my go programs; it is
trivial to display predictions, but understanding them is of course
not
My first (braindead) multi-threaded UCT played weaker with two cores
than one core. How do you combine search trees/results? How do you pick
a move to play?
There were a couple of papers [2] at CG2008 on this subject. The
consensus seemed to be that root parallelization [1] was best. In fact
20 matches
Mail list logo
