Dave Dyer | 2 Sep 19:04 2014
Picon

Re: some general UCT notes.

At 06:18 AM 9/2/2014, Ben Ellis wrote:
>I agree the board-copying should possibly be quicker, but in your case I'd think for the first half of the
game you should starting from an empty board and replay the moves to get to the current position and then
doing the opposite in the second half of the game by undoing the moves. You'd have to approximate what "half
way through the game" is of course :)

Actually, the starting point of a search is always a copy of the main board
(and associated data structures), not one created by replaying moves, but
what you do just once, to start a search, has no effect at all on the
overall performance.
Ben Ellis | 2 Sep 15:18 2014
Picon

Re: some general UCT notes.

I agree the board-copying should possibly be quicker, but in your case I'd think for the first half of the game you should starting from an empty board and replay the moves to get to the current position and then doing the opposite in the second half of the game by undoing the moves. You'd have to approximate what "half way through the game" is of course :)


On Sat, Aug 30, 2014 at 9:10 PM, Dave Dyer <ddyer <at> real-me.net> wrote:

I've recently been upgrading my family of UCT robots for non-go games,
but thought I'd report a few things for "general knowledge and expectations".
This UCT system is written in java, and runs on standard PC hardware with
multiple processor cores.

The system typically uses a fairly small tree and a relatively long random
playout tail, and is not especially optimized for speed. Only the tree-descent
and backtrack-update phases have thread synchronization issues.

I found simple threading had a pretty sharp knee in performance at 4
threads.  In other words, 2 3 and 4 threads improved the overall amount
of work done more or less linearly to 3.5x, speed improvements fell off
rapidly for more threads.

I've also been comparing "blitz" play which creates a copy of the
board at top level, and starts each descent with a copy of the board;
compared with "unwinding" play where every move is explicitly unwound.
Of course, the complexity of the unwinding varies a lot from game to
game, but I found that "unwind" is always faster, an average 1/3 faster
across several games.  So if the complexity of unwinding your data
structures is not too great, it's worthwhile.

_______________________________________________
Computer-go mailing list
Computer-go <at> dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go

_______________________________________________
Computer-go mailing list
Computer-go <at> dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
angpoo | 2 Sep 11:47 2014
Picon

need help about KGS bot config

Hello.

I'm Lim Jaebum author of DolBaram.

DolBaram is ranked bot now. But still open free game.

here's my config.
---
room=Computer Go
mode=custom
reconnect=true
undo=false
rules=chinese
rules.boardSize=19
rules.time=1:00+5x0:15
---

Did I miss something?
_______________________________________________
Computer-go mailing list
Computer-go <at> dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Detlef Schmicker | 31 Aug 11:50 2014
Picon

Probability drift functions

Hi,

I try to find a way to measure the drift of the probability of a node. I
am not looking for a heuristic like compare the last 1000 playouts with
the probability of all playouts but something more general.

I found some articles over "Drift Analysis", which are used in a
different way, but may be converted to this situation.

I found 

arXiv:1011.3466v1 [cs.NE] 15 Nov 2010
Non-Existence of Linear Universal Drift Functions

which from my understanding indicates, that I might be searching for
something impossible, but I did not read into detail for now.

Did somebody already tried this? The idea is, drifting nodes have to
explored in more detail...

Thanks Detlef
Petr Baudis | 31 Aug 09:31 2014
Picon

Re: some general UCT notes.

  Hi!

  Thanks for sharing your observations.

On Sat, Aug 30, 2014 at 01:10:10PM -0700, Dave Dyer wrote:
> I found simple threading had a pretty sharp knee in performance at 4
> threads.  In other words, 2 3 and 4 threads improved the overall amount
> of work done more or less linearly to 3.5x, speed improvements fell off
> rapidly for more threads.

  Do you exclusively lock the tree when working with it, or does Java
allow some tricks to use the traditional lockless tree updates?

> I've also been comparing "blitz" play which creates a copy of the
> board at top level, and starts each descent with a copy of the board;
> compared with "unwinding" play where every move is explicitly unwound.
> Of course, the complexity of the unwinding varies a lot from game to 
> game, but I found that "unwind" is always faster, an average 1/3 faster
> across several games.  So if the complexity of unwinding your data
> structures is not too great, it's worthwhile.

  Couldn't it be the case that your "board" object is just too heavy
weight?  Don't any surprising things hide in the constructors etc.?
What actually takes so much time during the copy operation?

  (Also, in general - what is the relation between number of moves you
make during a playout, number of different board points you visit by the
moves, and size of the board?  If the last is much bigger than the
former two, it may make sense.)

--

-- 
				Petr Baudis
	Life is short, the craft long, opportunity fleeting, experiment
	treacherous, judgment difficult.  -- Hippocrates
Rémi Coulom | 31 Aug 09:13 2014
Picon

Re: some general UCT notes.

On 30 août 2014, at 22:10, Dave Dyer <ddyer <at> real-me.net> wrote:

> I've also been comparing "blitz" play which creates a copy of the
> board at top level, and starts each descent with a copy of the board;
> compared with "unwinding" play where every move is explicitly unwound.
> Of course, the complexity of the unwinding varies a lot from game to 
> game, but I found that "unwind" is always faster, an average 1/3 faster
> across several games.  So if the complexity of unwinding your data
> structures is not too great, it's worthwhile.

Hi Dave,

I am very surprised by this. It is certainly not the case for Go, even on 9x9. Making a copy of the board should
be orders of magnitude faster than running a playout.

Rémi
Dave Dyer | 31 Aug 08:38 2014
Picon

Re: some general UCT notes.

At 02:41 PM 8/30/2014, Álvaro Begué wrote:
>Can you give us an idea of what types of games you are talking about? From that email I can't tell if you are
looking at Connect Four, Texas Hold'em, Diplomacy, Puerto Rico or Imperium Romanum II. I am sure the your
observations don't apply to all those games.

Actually, it pretty much does.  The list includes 2 player abstracts
such as Morelli and Kamisado, all the way to multiplayer euros such
as Euphoria and One Day in London.
Álvaro Begué | 30 Aug 23:41 2014
Picon

Re: some general UCT notes.

Can you give us an idea of what types of games you are talking about? From that email I can't tell if you are looking at Connect Four, Texas Hold'em, Diplomacy, Puerto Rico or Imperium Romanum II. I am sure the your observations don't apply to all those games.


Álvaro.



On Sat, Aug 30, 2014 at 4:10 PM, Dave Dyer <ddyer <at> real-me.net> wrote:

I've recently been upgrading my family of UCT robots for non-go games,
but thought I'd report a few things for "general knowledge and expectations".
This UCT system is written in java, and runs on standard PC hardware with
multiple processor cores.

The system typically uses a fairly small tree and a relatively long random
playout tail, and is not especially optimized for speed. Only the tree-descent
and backtrack-update phases have thread synchronization issues.

I found simple threading had a pretty sharp knee in performance at 4
threads.  In other words, 2 3 and 4 threads improved the overall amount
of work done more or less linearly to 3.5x, speed improvements fell off
rapidly for more threads.

I've also been comparing "blitz" play which creates a copy of the
board at top level, and starts each descent with a copy of the board;
compared with "unwinding" play where every move is explicitly unwound.
Of course, the complexity of the unwinding varies a lot from game to
game, but I found that "unwind" is always faster, an average 1/3 faster
across several games.  So if the complexity of unwinding your data
structures is not too great, it's worthwhile.

_______________________________________________
Computer-go mailing list
Computer-go <at> dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go

_______________________________________________
Computer-go mailing list
Computer-go <at> dvandva.org
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
Petr Baudis | 30 Aug 14:23 2014
Picon

Visualizing test games for performance analysis

  Hi!

  I have came upon an interesting trick for analyzing behavior changes
in noisy systems like game AI runs, that draws heavily on using some
abstract characteristics and visualizing them:

	http://yieldthought.com/post/95722882055/machine-learning-teaches-me-how-to-write-better-ai

Has anyone tried something like this in Computer Go? It's been pretty
inspiring for me because I have always found finding bugs and
shortcomings in heuristics a really painful process.

  One question is what game-continuous performance characteristics
to choose in Go.  An obvious one is winrate, for reading measure
I guess also numbers of dead / unstable stones.

  I guess I'll try to implement this for Pachi + gogui-twogtp
-debugtocomment, the tool itself can be engine-independent.

  (Of course, given that we also simulate games during MCTS, this could
be brought into an even more interesting level.)

--

-- 
				Petr Baudis
	Life is short, the craft long, opportunity fleeting, experiment
	treacherous, judgment difficult.  -- Hippocrates
Joshua Shriver | 25 Aug 06:51 2014
Picon

CGOS "start engine pack"

Anyone have the 9x9 and 19x19 engine start pack?  Working on CGOS
right now and could use those engines to test with. Know at least a
couple were used as anchor engines.

-Josh
Detlef Schmicker | 20 Aug 17:01 2014
Picon

Journals for computer go related papers

Hi,

I am writing a little paper on a new backup operator for MCTS. Now I
just realized, that most (nearly all) computer go related papers are
published in conference proceedings.

As a high school teacher I have no possibility to take part at
conferences:(

Do you think there are reasonable journals to consider or should I
simply use arXiv.org?

Thanks a lot

Detlef

Gmane