> I would like to know what exact experiments with "virtual komi" have
> been made and why thay failed. ..
> So why exactly shouldn't it work?
(warning: I have not tried this yet, just been thinking about the issue)
While virtual komi sounds like an attractively simple way of solving
the issue, I
>> .. plain MC bot ..
>> The effect is that the bot is only "interested" in a narrow range of fairly
>> balanced games: if it gets too far behind, or too far ahead, its play
>> becomes fairly random. The reason being that small differences in
>> score may not sufficiently affect the win/lose ratio
>The purpose of a handicap games is to allow a 50% chance of either
>contestant winning. .. Programs do not care,
Are you sure?-) I haven't got round to moving beyond a plain MC bot yet,
where the effect is rather striking, but less naive bots also depend on win-rate
for their move evaluations.
T
Last time I looked more closely at what my MC bot (simple, no tree)
was doing, I noticed that it has a tendency to try the impossible moves
(suicides) first, discarding them as impossible for every genmove.
Looking at more statistics, and thinking about it, it finally dawned on
me that this is a c
>The use of C is almost the only choice, but I'm on the lookout for the
>next wave of languages that will be:
> 1. Native code compiled - no external runtime required.
> 2. High level language features, but not imposed on you.
Have a look at Haskell (www.haskell.org). I don't want to get int
It seems unbelievable to me how many bugs I introduced while converting
my "fooling around with Go concepts" code to GTP and towards the refbot
spec. It is not that GTP or refbot are themselves problematic, it is that I had
lots of assumptions built in that needed revision - leaving GTP and refbot
>My first monte carlo programs used ownership info very effectively, but it
>can be that by using
>AMAF this information is used already.
As a relative beginner in these matters, the more I look at AMAF,
the less I like it, and I think that has to do with AMAF ignoring
relative sequencing. By l
> one of the basic problems of go newbies
> is their tendency to place the next stone
> near to the latest stone of the opponent.
> Sometimes this is called the "2-inch heuristic
> of beginners".
How about going the other way, forcing Monte-Carlo simulations
onto a coarser grid in the hope of quic
>> In a game of self play, if both parties are employing only monte
>> carlo, ... random simulations... wouldnt it be very weak...
>> ... and some playing around I am clearly mistaken because its works
>> quite well.
>Yes, it doesn't make sense but it does indeed seem to work :-).
Plain Monte-Carl
> I am now seeking some good textbooks for computer-go course in my university
> for undergraduates. I hope I can get some advice from this mailing list,
> thank you all!
I'm not currently in teaching, but I'd be interested to hear about uses
of computer-go in this context, ie, not so much as a sp
>It's pretty tricky doing anything very clever without slowing things
>down a lot. But I am highly interested because I want to build a
>stronger Ogo type of program for handheld devices.
Here's a suggestion: some mobile devices have volume-bound
communication tariffs (internet or text messaging
> Thanks again for more explanations. I think the AMAF is clear to me now.
For what it is worth: I read the AMAF section as indicating that the bots
are to play using AMAF heuristics - random playouts, followed by playing
the AMAF-scored winning move, rinse and repeat. Which is why I thought
I sho
> It's a new area and the systems are very complicated. What kind of
> theory are you after, and what would you like it to tell you?
Currently, what seems to happen is (no offense intended, and please
correct me if my incomplete view is wildly off!-):
- have an idea for a great improvement (one t
> You'll probably enjoy an article I wrote last year on this theme:
> http://dcook.org/compgo/article_the_problem_with_random_playouts.html
Hi Darren,
yes, I particularly liked that you explained what you were trying to
show and how you think your data supports this - one might agree or
disagree
>As for me, i'm really NOT interested in knowing "what langage is good for go
>programming". That's simply not a question i can ask myself, nor anyone else.
> This question doesn't make any sense for me. Still if someone can get the
>"standard light playout" right in less than 10 code line, and the
> Just out of curiosity, what did you expect from the playouts?
Nothing in particular, really; at this point I'm just trying to build up an
intuition
about what I can or cannot expect from them. At first, I thought light playouts
would not fully explore, but at least randomly cover all possible g
> .. I think people (me included) feel that replacing a whole swath
> of relevant information by a single number points to potentially some
> serious inefficiency and loss of information. The fact that nobody
> has found how to make use of the excess of information is no proof of
> course that it c
> Thanks! Here goes another attempt, this time trying to construct an
> example where pseudo-eyes prevent a necessary fill-in ('a' is J15,
> 'b' is L17, 'c' is F12, and 'd' is K16).
..
> GN[playout-eyes2]
Sorry about that one! I must have been thinking of some form of
Carpenter's square or square
Don's draft standard reminded me of the corner cases. So here's
an even simpler example, this time trying to show that dead invading
stones can poison playout analysis depending on which definition of
pseudo-eyes is used ('a' is A1, 'b' is C1).
That makes three attempted examples so far (are the e
> It is important to know about potential blind spots introduced by pseudo-eye
> variations, or any
> other rules.
>
> Borrowing from Eric S Raymond, the more eyes inspecting the ideas, the
> shallower the bugs.
Thanks! Here goes another attempt, this time trying to construct an
example where p
> There is a de facto standard light playout policy (algorithm).
I have a rough idea of what that might be. And I suspect that keeping this
"de facto standard" implicit has been hiding some actual differences in what
different people think that standard is. Some of my questions arise from trying
t
Thanks everyone for the answers regarding playout terminations. I still
have my suspicions regarding how artificial game length bounds affect
the position evaluation (I'd expect the values to fluctuate with length,
so arbitrary bounds would result in arbitrary differences).
For the moment, however
>> Anything can exist in a random game :-)
> Occur yes, repeat forever requires very special situations.
That makes long repeats unlikely in any individual run, and infinite
runs infinitely unlikely, unless we run into one of those very special
situations. But how special do these actually need to
>>What about that claim that "the program could figure out the rule by itself"?
>I made experiments with no-go-knowledge. (no eye knowledge).
Any random player that accurately avoids suicide seems to need an awful lot
of Go knowledge implicitly:
- liberties (or at least pseudo-liberties, since we
Hi again, with yet another question:-)
Could someone please summarize the state-of-the art wrt the various ways
of limiting random playouts, and the their consequences?
There are several variations on the "don't fill your own eyes" (dfyoe) approach,
but the way this approach is often described te
>>> For instance, if an intersection belongs to the same colour in all
>>> playouts, chances are
>>> that it is fairly secure (that doesn't mean one
>> shouldn't play there, sacrifices there may have an impact on other
>> intersections).
Ok, that one was well know (ownership maps, territo
>> Now, for the technical matter: Could somebody please point me to a quick
>> rundown of how modern
>> Go engines exactly utilize multicore environments and the workload is
>> segregated and
>> distributed? I don't have any significant knowledge on that, so any
>> pointers would be much
> But for grids (instead of clusters), the communication will become much much
> bigger - I'd like to study that carefully one day, I have no clear idea of
> what is possible.
>
> A trouble is that on grids (at least the ones I've seen) there are often
> faults. We'll have to be fault tolerant I g
> Since statistics play such a vital role in modern Go engines, is there a
> danger
> that good old-fashioned low-level optimizations interfere with those
> statistics?
>
> Things like not re-evaluating symmetric positions (boar mirroring/rotation,
> move transposition, etc.) multiple times inter
Since statistics play such a vital role in modern Go engines, is there a danger
that good old-fashioned low-level optimizations interfere with those statistics?
Things like not re-evaluating symmetric positions (boar mirroring/rotation,
move transposition, etc.) multiple times interacting with sta
>I agree with much of what you say (to the degree that anyone needs to "agree"
>with questions).
Good of you not respond as Kosh might have: "Yes" (warble sound effects;-)
> The discussions on this list dealing with "ownership maps", RAVE and AMAF have
> to do with using additional information f
>From browsing Monte-Carlo Go papers (*), I get the impression that random
playouts are used mainly to approximate an evaluation function, determining
some value for board positions arising in more traditional tree search.
Is that correct? It seems somewhat wasteful to calculate all those poss
> If you're looking for spare processors, how about a "[EMAIL PROTECTED]"
> program for Go?-)
It appears that the Chess community has had such a project already:
ChessBrain: a Linux-Based Distributed Computing Experiment
http://www.linuxjournal.com/article/6929
ChessBrain II - A Hier
This beast goes online in 2011. Better start lobbying now for some Mogo
time.
By coincidence I was looking at the Top 500 list yesterday and the top
machine already does petaflop (peak) performance [1]. I wonder how many
playouts/second Mogo would do on that :-).
If you're looking for spare p
34 matches
Mail list logo
