Hi.
First things first : i think the specification is enougth as it is.
I hope that we can end up with something useable by anyone,
even non go people as a final goal. We'll have to get non-go experienced
people to beta-read it (and criticized) for us, i suppose. And we'll probably
have to
Thanks for the comments and suggestions. My responses below ...
On Tue, 2008-10-14 at 09:00 +0200, Denis fidaali wrote:
>
> Hi.
> First things first : i think the specification is enougth as it is.
> I hope that we can end up with something useable by anyone,
> even non go people as a final
On Tue, 2008-10-14 at 16:22 +0100, Claus Reinke wrote:
> > .. 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
Seems like we need a short introduction too:
"Go is a board game played on a rectangular grid, usually 19x19.
Pieces (or stones) are placed alternately by the black and white
players. Pieces are played onto empty vertexes with the aim of
surrounding and capturing the opponents pieces. The game con
On Tue, 2008-10-14 at 16:22 +0100, Claus Reinke wrote:
> > .. 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
Would you be willing to take what I have and integrate this for us?
My currently "official" document is in the README file here:
http://cgos.boardspace.net/public/javabot.zip
(which has been slightly corrected, the Makefile didn't produce a valid
jar file because the main class was not prop
On 14-okt-08, at 14:02, Don Dailey wrote:
Mark Boon went off on a tangent here when he talked about a "swath of
information available" and his imaginative discourse on how it
might be
used. He really launched into a different discussion and I don't
disagree with him. It was just something
On Tue, 2008-10-14 at 15:27 -0200, Mark Boon wrote:
> On 14-okt-08, at 14:02, Don Dailey wrote:
> > Mark Boon went off on a tangent here when he talked about a "swath of
> > information available" and his imaginative discourse on how it
> > might be
> > used. He really launched into a different
> .. 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
---
Don said
---
I don't really want to be too involved in drafting this as it's not my
forte. However I hope someone else (who is a better writer) will be
willing.
+++ Answer +++
+++
What you did up now has great value. It gives us a strong basi
Here is a quick answer to most of your sticky points:
But first of all, thank you for you generous praise, I probably don't
deserve it (but I'll take what I can get :-)
An external tester will test for conformance and it will compare 2 bots,
one of which we "trust" as being conforming. But the
Claus Reinke wrote:
> Second, having now looked at some more random "light playouts"
> (just instrument your engine to output sgf before starting the next run),
> I feel that the name is highly misleading. These simulation runs have
> very little in common with actual play, eg, in a 19x19 run from
> 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
> Second, having now looked at some more random "light playouts"
> ...
> an empty board, but if you look at move 300 and try to compare the
> strings and eyes that almost make it vs those that do, it drives home
> the message that the individual run is nearly meaningless,...
Hi Claus,
You'll proba
>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
Hi Claus,
> In sum, there doesn't seem to be a good basis for understanding playouts
> and their optimisation, other than by trial and error. Those who've been
> through some cycles of trial-and-error probably have at least a vague
> intuition of what works and what doesn't (or didn't when they la
Many Faces uses quite light playouts, and is 1 kyu 19x19 on KGS when run on
32 cores. So I think you can make a fairly strong program using light
playouts. My playouts are certainly far lighter than Crazystone or Mogo.
David
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:compute
> Many Faces uses quite light playouts, and is 1 kyu 19x19 on KGS when run on
> 32 cores. So I think you can make a fairly strong program using light
> playouts. My playouts are certainly far lighter than Crazystone or Mogo.
Hi David,
"quite light" is a bit vague, and I got the impression you we
I use Many Faces' knowledge in the search, but not the playouts. I made
them as light and fast as I could.
I don't have a way any more to just do playouts without the uct search. In
your position after a few thousand playouts, it gets over 95% win for white
and 5% win for black (depending on who
Hi,
On Wed, Oct 15, 2008 at 02:51, Claus Reinke <[EMAIL PROTECTED]> wrote:
> So, once you've got your representations (sets/bitmaps, arrays/hashtables,
> etc.) implemented in libraries, the programming language itself may not
> matter much any more (recursion simplifies things, but whether one
> r
20 matches
Mail list logo
