On Wed, Apr 9, 2008 at 10:54 AM, [EMAIL PROTECTED] wrote:
I got excited about the free software sometime ago and bought a copy of
Susie Linux. But the installation always hang up at some point and can never
complete.
I too have had some horrible linux installation nightmares. Most of that
On Apr 9, 2008, at 6:00 PM, Rémi Coulom [EMAIL PROTECTED]
wrote:
Since most programs on CGOS are constant, I believe that Bayeselo
would be very difficult to beat.
That's partly a side effect of the current rating system...
Rémi
___
Views fine on my iPhone. My only advice is to review the paragraph
after equation 3. For example, what the difference is of is unclear. I
was also unable to read the exponent in the equation for phi. It may
just be insufficient zoom...
Sent from my iPhone
On Apr 6, 2008, at 10:55 PM,
On Apr 7, 2008, at 8:22 AM, Petr Baudis [EMAIL PROTECTED] wrote:
Hello,
On Sun, Apr 06, 2008 at 08:55:26PM -0600, David Silver wrote:
Here is a draft of the paper, any feedback would be very welcome :-)
http://www.cs.ualberta.ca/~silver/research/publications/files/MoGoNectar.pdf
you are
On Fri, 2008-03-28 at 11:20 +0100, Jaonary Rabarisoa wrote:
- its rave and uct value are defined ( in this case we can
compute the above score)
- only the rave value is defined (in this situation the n(s,a)
= 0 and the uct value is not defined)
-
to throw away all non visited node and
only consider the node that have a rave value first. Precisely use
the FPU but only for unvisited node that have Q_rave value.
On Fri, Mar 28, 2008 at 12:41 PM, Jason House [EMAIL PROTECTED]
wrote:
On Fri, 2008-03-28 at 11:20 +0100, Jaonary
On Mar 17, 2008, at 7:49 AM, Nick Wedd [EMAIL PROTECTED] wrote:
I have been discussing the Computer Go event with the organisers of
the European Go Congress, and have some news.
For those who plan to enter the Computer Go event(s) only, there
will be no fee. Entry for them will be free.
I've been trying to participate in the 10k UCT thing but have not had
much luck...
My latest problem is the cgos gtp client... I have never gotten it to
work. In fact, I have been of off cgos ever since I switched to it! I
submitted two bug reports... One prevents use of multiple bots and
this morning to use my laptop instead,
but then I hit the client bug.
Sent from my iPhone
On Mar 14, 2008, at 12:33 PM, Don Dailey [EMAIL PROTECTED] wrote:
I'll try to take a look at it in the next couple of days. Today
may
not be possible but I will try.
- Don
Jason House wrote:
I've
platform are you running on. How many bots?
2. Who is using the client with success?
Can I see your configuration file?
- Don
Jason House wrote:
Thanks Don!
There is no rush... I can download an old client from sf.net.
I'm just frustrated by all the little problems I'm hitting. My server
On Mar 14, 2008, at 3:38 PM, Jason House [EMAIL PROTECTED]
wrote:
Bug 1914235 was on Ubuntu 7.10. The config file and error message
are included in the report.
This is correct.
Bug 1879326 was on 64-bit Ubuntu 7.10. The config file and error
message are included in the report
On Mar 11, 2008, at 2:41 PM, Christoph Birk [EMAIL PROTECTED] wrote:
On Tue, 11 Mar 2008, Don Dailey wrote:
I am going to keep the 25k playouts running and add a 10k play-out
version of UCT. I want to establish a standard testing size so
that
Great! That way Jason can also
On Mar 12, 2008, at 2:17 PM, Don Dailey [EMAIL PROTECTED] wrote:
Tim Foden wrote:
Don Dailey wrote:
I suggest
exactly 25,000 play-outs that we should standardize on.50,000
will
tax my spare computer which I like to use for modest CGOS tests.
If it is agreed, I will start a 25k
If the speed was lowered to 10k, I'd also participate. One of these
days, I'll speed up my engine...
Sent from my iPhone
On Mar 11, 2008, at 11:18 AM, Don Dailey [EMAIL PROTECTED] wrote:
Don Dailey wrote:
Petr Baudis wrote:
On Mon, Mar 10, 2008 at 06:57:07PM -0400, Don Dailey wrote:
On Mar 10, 2008, at 8:07 PM, Don Dailey [EMAIL PROTECTED] wrote:
Some programs hash each position and the tree is more abstract, no
pointers just positions leading to other positions by zobrist hash
keys in a hash table.
My scheme probably wastes a lot of space on nodes that are left
On Mar 8, 2008, at 7:41 AM, Don Dailey [EMAIL PROTECTED] wrote:
Petr Baudis wrote:
Hi,
is there source code available for the binary CGOS client, please?
Get the Multi-platform starkit version of cgosGtp_kit.zip on the web
site.
Why not tell people to use the subversion repository?
On Sat, 2008-03-08 at 17:02 +0100, Petr Baudis wrote:
On Sat, Mar 08, 2008 at 04:56:16PM +0100, Moi de Quoi wrote:
Well, it depends on the server's policy, whether you are allowed to be
logged in more than once under the same name. (I can see no good reason
to allow it, but it's Don's
I only back up along the path I took to reach the leaf node. When
reevaluating nodes, I re-check the number of simulations for all
children.
___
computer-go mailing list
computer-go@computer-go.org
Good catch Yamato. I think the idea is that they're trying to calculate the
true variances rather than the sample variances. It's true that q_ur would
probably give a better estimate than q_u or q_r alone. Of course, q_ur
depends on beta, and as they calculate it, beta depends on q_ur.
It may
That's 41% of the 206 games that begin with E5 {G5,C5,E7,E3}
On Feb 12, 2008 1:38 PM, Don Dailey [EMAIL PROTECTED] wrote:
This pattern doesn't appear to often:
5 E5 G5 G4
6 E5 C5 C4
8 E5 C5 C6
12 E5 E7 D7
12 E5 E7 F7
13 E5 G5 G6
14 E5 E3 D3
15 E5 E3
On Feb 12, 2008 1:01 PM, Don Dailey [EMAIL PROTECTED] wrote:
Here are frequencies that it plays each response to E5 out of 761 games:
1 E5 B4
1 E5 B6
1 E5 D8
1 E5 F8
1 E5 H4
1 E5 H6
2 E5 B5
2 E5 F2
3 E5 E4
3 E5 H5
5 E5 E8
6
On Feb 12, 2008 10:14 AM, Jason House [EMAIL PROTECTED] wrote:
If you would like to have a subforum created on a topic related to game
programming, then don't hesitate to ask, and I'll add a new subforum. It
is not my intention to be a competitor to established mailing lists and
forums, so
On Feb 12, 2008 8:49 AM, Rémi Coulom [EMAIL PROTECTED] wrote:
Hi,
I am now a little interested in developing a program to play the game of
Hex, and I started to search the web for some information. I found that
for many games played in the Computer Olympiad, such as Hex or Amazons,
there is
On Sat, 2008-02-09 at 11:50 +0100, Olivier Teytaud wrote:
I think it is time to share this idea with the world :-)
The idea is to estimate bias and variance to calculate the best combination
of UCT and RAVE values.
I have attached a pdf explaining the new formula.
It is written in the
On Sun, 2008-02-10 at 18:35 +0100, Olivier Teytaud wrote:
That translates to mean that MoGo no longer uses upper confidence
bounds, and only uses means. It also means that MoGo will _never_
explore improbable children (after a few sims) unless the RAVE value
yields an unusually high
On Feb 8, 2008 12:09 PM, David Silver [EMAIL PROTECTED] wrote:
I think it is time to share this idea with the world :-)
The idea is to estimate bias and variance to calculate the best
combination of UCT and RAVE values.
I have attached a pdf explaining the new formula.
Thanks!
The original
On Fri, 2008-02-08 at 16:39 -0700, David Silver wrote:
2. No, the assumption itself is not correct. The true value of a node
in the tree is 0 or 1, given perfect play. So the UCT value (which
just averages the outcomes of simulations) is significantly biased.
Who can predict perfect play?
On Feb 6, 2008 11:39 AM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
Hideki Kato wrote:
4) Before back-propagating the value of each playout, I setup a color
table for all intersections of the board for speed-up, in fact
(initialized with EMPTY). That is, fill the board (table[move] =
On Feb 6, 2008 3:39 PM, Don Dailey [EMAIL PROTECTED] wrote:
I asked that question wrong - what is the resolution of the screen?
Does it scroll to simulate higher resolution?
Poking around online, I see 480x320. The web browser allows a zoom/unzoom
and also scrolling... Two nice ways to
On Feb 5, 2008 2:08 PM, David Fotland [EMAIL PROTECTED] wrote:
It think many programs run several simulations through a node before
allocating the children. I can see how this saves memory, but then how do
you save the RAVE information from the early simulations?
For RAVE, after doing a sim
On Feb 5, 2008 2:22 PM, David Fotland [EMAIL PROTECTED] wrote:
Helps a little, but I'm still unclear on how a new node is handled.
Do you have lightweight nodes (that only contain info on one positions,
with pointers to children and siblings)? Then when uct finds a node with no
children,
On Feb 4, 2008 1:59 PM, terry mcintyre [EMAIL PROTECTED] wrote:
Does the KGS protocol permit one to propose a set of dead groups, then
upon discovery of a conflict, to say Ok, your proposal still leads to my
win, I'm perfectly happy to accept that result?
No. Any conflict immediately
I don't know if this is helpful, but it is fairly easy to do some adaptive
timing to ensure not running out on time.
Total external lag = (game time - time used internally) - time left
Mean external lag = Total external lag / moves made by bot
This lag can be used for creating a time buffer for
On Feb 4, 2008 2:18 PM, Nick Wedd [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED], Gunnar Farnebäck
[EMAIL PROTECTED] writes
terry mcintyre wrote:
Does the KGS protocol permit one to propose a set of dead groups,
then upon discovery of a conflict, to say Ok, your proposal still
On Feb 4, 2008 10:40 AM, Nick Wedd [EMAIL PROTECTED] wrote:
Also, how does kicking work? A manual kill of a bot+kgsGtp and
restarting by the user seems like it'd fix stuck bots. I'm guessing a
kick is for when bots (like HB06) are unattended? Does that make
kgsGtp exit? That'd require an
Open division round numbers appear out of sync. The quote from me uses
round numbers that are one off from what's in the official report.
Something should probably get fixed.
Also, how does kicking work? A manual kill of a bot+kgsGtp and restarting
by the user seems like it'd fix stuck bots.
I wouldn't stop there. I'd like a static analyzer to add tactical smarts to
playouts. If there's a pre-existing nakade, seki, etc, the playouts should
get it right.
On Feb 1, 2008 10:34 AM, Michael Williams [EMAIL PROTECTED]
wrote:
I think we would all agree that UCT+MC is quite good for
On Feb 1, 2008 4:18 PM, terry mcintyre [EMAIL PROTECTED] wrote:
UCT is based on a theory of a multi-armed bandit, with uncertain knowledge
about which arms would be most productive. Is it possible to graft various
sources of knowledge into a sort of meta-bandit algorithm?
IIRC, MoGo already
How do you compute that? I think the ELO values given are the rating
differences that correspond to the particular upset (win) rate. They're not
absolute ELO values. A truly absolute value is also tough to define. CGOS
picked its value somewhat arbitrarily.
On Jan 31, 2008 12:54 PM, David
I was shocked for a second, until I check Crazy Stone's playing record. Its
rating shot up after it stopped playing! It hasn't played a single rated
game on KGS since Dec 2, 2007.
On Jan 31, 2008 1:49 PM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
Don Dailey wrote:
I don't know how David
On Jan 31, 2008 2:20 PM, Don Dailey [EMAIL PROTECTED] wrote:
So if I get rated on KGS all I have to do is stop playing and my rank
will shoot up a few ranks?
It's a pretty common phenomenon on KGS... I've seen it happen many times
___
computer-go
I recently upped mine from 32 bit to 64 bit. Once I put more checks in my
code, I found that stale data was getting reused. I may be an exception to
the rule though because I've never implemented a way to clear out old search
data. My engine is slow, so that's less of a problem in short CGOS
On Jan 31, 2008 4:31 PM, Don Dailey [EMAIL PROTECTED] wrote:
FatMan doesn't use a hash table to represent the tree, it actually uses
a tree with pointers and so on.
For detection of repetition in the search part, FatMan uses a 64 bit
zobrist key.
How do you find a pre-existing node to
On Jan 30, 2008 12:02 PM, steve uurtamo [EMAIL PROTECTED] wrote:
you should rename the protocol TP then.
Or just call it game text protocol ;)
___
computer-go mailing list
computer-go@computer-go.org
On Jan 30, 2008 2:48 PM, Don Dailey [EMAIL PROTECTED] wrote:
So are you saying that if mogo had this position:
| # # # # # #
| O O O O O #
| + + + + O #
a b c d e
That mogo would not know to move to nakade point c1 with either color?
That's not nakade... Even if it was one shorter,
You're not crazy. Gmail shows it that way too.
On Jan 30, 2008 2:49 PM, Don Dailey [EMAIL PROTECTED] wrote:
Is is just my email client or does Terry's post have one word per line
when quoting others?
- Don
terry mcintyre wrote:
Someone recently posted a 19x19 example. Mogo failed to
. My
example shows 4 empty points in a big eye but they have even bigger
examples.
So I think this is nakade.
- Don
Jason House wrote:
On Jan 30, 2008 2:48 PM, Don Dailey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
So are you saying that if mogo had this position
On Jan 30, 2008 3:51 PM, terry mcintyre [EMAIL PROTECTED] wrote:
There are other shapes which are known to be dead. For example, four
points in a square shape make one eye, not two. If the defender plays one
point, trying to make two eyes, the opponent plays the diagonally opposite
point,
On Jan 30, 2008 4:35 PM, Don Dailey [EMAIL PROTECTED] wrote:
Heikki Levanto wrote:
On Wed, Jan 30, 2008 at 03:23:35PM -0500, Don Dailey wrote:
Having said that, I am interested in this. Is there something that
totally prevents the program from EVER seeing the best move?I don't
On Jan 29, 2008 10:01 AM, Don Dailey [EMAIL PROTECTED] wrote:
FatMan seems to hit some kind of hard limit rather suddenly. It
could be an implementation bug or something else - I don't really
understand this. It's very difficult to test a program for
scalability since you are limited
On Jan 24, 2008 8:00 AM, Heikki Levanto [EMAIL PROTECTED] wrote:
Everyone is looking at the top end of the scalability study
http://cgos.boardspace.net/study/
But what happens in the low end? Both programs show linear progress to
begin
with, then a corner, and more (almost?) linear
Maybe it's just a temporary thing, but I just happened to check and CGOS was
down... I get lots of messages like the following:
22:43:00Server startup return code: 1 msg: couldn't open socket:
connection refused
22:43:00Cannot connect to server. Will retry shortly
On Wed, 2008-01-23 at 18:57 -0500, Eric Boesch wrote:
I am curious if any of those of you who have heavy-playout programs
would find a benefit from the following modification:
exp_param = sqrt(0.2); // sqrt(2) times the original parameter value.
uct = exp_param * sqrt( log(sum of all
On Jan 22, 2008 2:50 PM, Michael Williams [EMAIL PROTECTED]
wrote:
Playouts can limit scalability.
No, I don't think so.
Actually, the given example seems legit. I may rephrase it as move pruning
policies can limit scalability. Depending on the severity, the bot may be
completely blind to
On Jan 18, 2008 11:30 AM, Raymond Wold [EMAIL PROTECTED] wrote:
My own experience when experimenting with random playouts were that
without ko checking at all, around 30% of games ended in infinite loop
with both sides having one (non-eye-filling) move possible, to retake
the ko.
My
On Jan 1, 2008 9:27 PM, Jason House [EMAIL PROTECTED] wrote:
I've started an open source implementation for computing the strength of
move features. It's not done yet, but will eventually be posted to
http://housebot.svn.sourceforge.net/viewvc/housebot/trunk/elo/
I posted this a few days
I think your question boils down to answering what is meant by
evaluate. Chess has a heuristic that is easy to compute and gives a
good evaluation. Go lacks this. While probably an inferior evaluator,
the Bouzy 5/21 score estimator is an example from go that can be quite
slow. UCT (or
On Mon, 2008-01-14 at 19:41 -0800, mingwu wrote:
1K ~ 100 K / sec is much faster than a dozen / sec of a conventional
program.
Do they calculate dragon safety (eyes, connections, patterns ...)? if
not, the estimate will be VERY unreliable.
That's just it, they don't. They play a
I don't have a copy of the code, but the bias of any given node should be
the sum of the bias of all of its children.
On Jan 9, 2008 1:49 PM, [EMAIL PROTECTED] wrote:
I'm looking at the code of Libgo110. I have a question. In the file
uct.cpp and the definition of class note_t, the
On Jan 8, 2008 7:42 AM, Don Dailey [EMAIL PROTECTED] wrote:
None of the KGS specific extensions are required or used. undo is not
necessary.
I know that CGOS will use kgs-time_settings if it's available.
___
computer-go mailing list
I haven't been using CGOS at all lately (planned gap in development around
the holidays). When I do start up again, it'll probably be on the 9x9
server. I'd do this because of the following reasons:
* Games finish faster on the 9x9 server
* Current testing/tuning is done on 9x9
(I have a short
Thanks for the write up.
To add to the list of misbehaving bots, in round 4, HBotSVN passed 41 times
out of 81 white moves. Probably not surprising, but the 81st white move
(move 162) was resign
Additionally, one nit pick: The text with the diagrams lists bot a vs. bot b
and then discuss black
On Jan 4, 2008 4:44 PM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
steve uurtamo wrote:
It was my understanding that the netlag to the Philippines was about
380 ms; accounting for an additiaonal 15% packet loss and we end up
at about 440 ms.
i think that it works out to roughly
On Jan 3, 2008 10:21 AM, Don Dailey [EMAIL PROTECTED] wrote:
Robert Jasiek wrote:
Don Dailey wrote:
you can never solve the problem of a
malicious opponent who wants to prolong the game needlessly.
I solved that many years ago: Constant game end rule.
If your bot has enough points to win under Tromp Taylor scoring, why
capture dead stones? Passing is the fastest way to end the game in your
favor. That trick should limit your game length to something manageable.
I've been thinking that I should add that feature to my bot.
I've also
On Jan 2, 2008 10:27 AM, Erik van der Werf [EMAIL PROTECTED] wrote:
I'd propose something simpler:
No time is deducted for pass.
That may be a bit too lax. A bot that thinks for 5 seconds before passing
could delay all bots on the server. I'd favor something in the same spirit
that limits
On Jan 2, 2008 3:29 PM, Don Dailey [EMAIL PROTECTED] wrote:
I am considering to implement Fischer time on CGOS, but I would like it
to be painless. I don't believe GTP has a provision to handle it -
but I will check to see what it does have. (I have no intentions of
doing the byo-yomi
I think of Bradley Terry as a generic class of mathematical models.
I have to assume you mean what Remi did in Crazy Stone.
http://remi.coulom.free.fr/Amsterdam2007/MMGoPatterns.pdf
If that's not what you're looking for, can you post more clarification?
I've started an open source implementation
, Rémi Coulom [EMAIL PROTECTED] wrote:
Jason House wrote:
For each iteration of batch updates, do you pass over the data
computing whatever you can and then pick a set of mutually exclusive
items to update? How bad would it be to update everything, including
those on the same team
On Dec 21, 2007 8:53 AM, Rémi Coulom [EMAIL PROTECTED] wrote:
Hi,
Minorization-maximization is a simple optimization method, and I agree
that it is likely that more efficient algorithms can be applied.
Newton's method implies estimating the inverse of the Hessian matrix.
Really computing
On Dec 21, 2007 10:03 AM, Álvaro Begué [EMAIL PROTECTED] wrote:
I am sure MM is a perfectly good algorithm for this purpose, but it has
the serious down side that I don't understand it. :) I do understand the
general idea behind it and how it works in some simple cases, but I don't
know
On Dec 20, 2007 10:15 AM, Arthur Cater [EMAIL PROTECTED] wrote:
With 8 hashes per position, the chance of two different boards
producing a different set of hashes but
the same canonical hash is greater than 1/2^64, because there will be
a bias in the choice of canonical
hashes - toward
On Dec 5, 2007 4:44 AM, Lars [EMAIL PROTECTED] wrote:
I have some questions concernig this paper of Remi:
http://remi.coulom.free.fr/Amsterdam2007/MMGoPatterns.pdf
@Remi: How many iterations you had used?
Anyone of you have similar or other experiences with the algorithm?
I seem to have
On Dec 20, 2007 11:43 AM, Jason House [EMAIL PROTECTED] wrote:
I seem to have more time to think than to code lately. I believe I've
derived an alternate update method.
Thinking more, I realize I messed up a three things...
For one, Newton-Raphson requires
new gamma - gamma = -*L/**L
On Dec 20, 2007 5:39 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
I was trying to come up with my own algorithm to maximize likelihood and I
am having a hard time getting it all in my mind. I managed to write a
working algorithm for the case of logistic regression, but it was kind of
brittle and
On Dec 19, 2007 9:27 AM, David Fotland [EMAIL PROTECTED] wrote:
I only use 2 random numbers per point, one for black and one for white.
I xor another random number indicating the side to move.
What about ko? I use another number for points that are illegal due to ko.
I think I define a hash
On Dec 19, 2007 10:24 AM, Don Dailey [EMAIL PROTECTED] wrote:
Why do you need to initialize the seed more than 1 time?You should
use zobrist hashing.
By design, my program reinitializes the random seeds. This is done at the
start of each genmove and is intended for repeatability.
In Remi's paper on ELO ratings of moves, how is mean log evidence computed?
Is that looking at the probability of the training set? e.g. if the
selected moves have estimated probabilities of 1/e, 1/e^2, 1/e, and 1/e,
then the log evidences would be -1,-2,-1, and -1 for a mean log evidence of
On Dec 14, 2007 12:43 PM, [EMAIL PROTECTED] wrote:
For purposes of discussion, let's say the bot takes a tactical snapshot
once at the root node and then uses that information to help pick a move. It
can apply it at the root, at internal nodes, at external nodes, or at the
very end (maybe it
On Dec 12, 2007 10:19 PM, David Fotland [EMAIL PROTECTED] wrote:
Many Faces' life and death search is best first and probability based,
but I don't use UCT to select moves. I select the move that has the highest
probability of changing the value of the root (from success to fail or vice
On Dec 13, 2007 2:03 AM, Harald Korneliussen [EMAIL PROTECTED] wrote:
Wed, 12 Dec 2007 07:14:48 -0800 (PST) terry mcintyre wrote:
Heading back to the central idea, of tuning the predicted winning
rates and evaluations: it might be useful to examine lost games, look
for divergence between
On Dec 13, 2007 11:39 AM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
Jason House wrote:
MoGo uses TD to predict win rates.
Really? Where did you get that information?
I can't seem to load http://www.lri.fr/~gelly/MoGo.htm at the moment, but I
found it there. One of the papers you can
On Dec 13, 2007 2:17 PM, [EMAIL PROTECTED] wrote:
I'd like to start a more specific discussion about ways to combine
tactical information with MC-UCT. Here's the scenario.
It's the bot's turn and, prior to starting any playouts, it runs a
tactical analyzer (for want of a better name) that
On Dec 13, 2007 2:37 PM, Don Dailey [EMAIL PROTECTED] wrote:
I am considering to enforce this basic protocol on the server soon:
Programs of the same family will not be paired against each other.
I frequently look at the games between my bot version more than I look at
them with other
On Dec 13, 2007 3:09 PM, David Fotland [EMAIL PROTECTED] wrote:
Isn't Greenpeep an alpha-beta searcher, not UCT/MC?
I could have sworn I heard it described as UCT/MC with MoGo-like
enhancements.
___
computer-go mailing list
On Dec 13, 2007 3:40 PM, terry mcintyre [EMAIL PROTECTED] wrote:
Jason House:
Don't forget that local tactical analysis can be reused many moves later
if the local area has remained unaffected.
In a multi-core system, it may become increasingly valuable to dedicate
a core to tactical
On Dec 13, 2007 3:52 PM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
Jason House wrote:
The paper introduces RAVE and
near the end talks about using heuristics for initial parameter
estimation. The heuristic they used was based TD.
Ah, you're talking about RLGO. RLGO was trained
On Dec 13, 2007 4:01 PM, Don Dailey [EMAIL PROTECTED] wrote:
I don't want to add more mechanisms. You can build your own mechanism
by making your own password naming convention or bot naming
convention.For instance you can use the underscore character to
build separate families of bots
On Dec 13, 2007 4:40 PM, George Dahl [EMAIL PROTECTED] wrote:
Please excuse me if this question has been answered before, my brief
look through the archives I have did not find it. How does one
compute unconditional life and death? Ideally, in an efficient
manner. In other words, I want to
On Dec 13, 2007 4:51 PM, Don Dailey [EMAIL PROTECTED] wrote:
Do you have a suggestion for a specific mechanism for this?
I was mostly just thinking a file that cgos looks for that includes bot
names and the preferences. The don't play list would need obvious
restrictions like what you've
On Dec 13, 2007 4:50 PM, David Fotland [EMAIL PROTECTED] wrote:
I think Martin Mueller published an improvement to benson's algorithm
that is also proved correct.
Yes. Safety under alternating play. It's more generally applicable but I
didn't think it met the needs of the original request.
On Dec 13, 2007 5:33 PM, [EMAIL PROTECTED] wrote:
-Original Message-
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thu, 13 Dec 2007 3:20 pm
Subject: Re: [computer-go] MC-UCT and tactical information
On Dec 13, 2007 2:17 PM, [EMAIL
On Dec 6, 2007 11:38 AM, Rémi Coulom [EMAIL PROTECTED] wrote:
Jason House wrote:
This may serve as a good test of if there is enough data to assign
values to the patterns.
I did not mention this in my paper, but you can rather easily estimate
uncertainty margins around Elo values
On Dec 12, 2007 2:59 PM, Rémi Coulom [EMAIL PROTECTED] wrote:
Do you mean a plot of the prediction rate with only the
gamma of interest varying?
No the prediction rate, but the probability of the training data. More
precisely, the logarithm of that probability.
I still don't know what
On Dec 12, 2007 3:09 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
On Dec 12, 2007 3:05 PM, Jason House [EMAIL PROTECTED] wrote:
On Dec 12, 2007 2:59 PM, Rémi Coulom [EMAIL PROTECTED] wrote:
Do you mean a plot of the prediction rate with only the
gamma of interest varying
On Dec 12, 2007 4:27 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
Clearly I'm missing something, because I still don't understand. Let's
take a simple example of a move is on the 3rd line and has a gamma value of
1.75. What is the equation or sequence of discrete values that I can
take the
As I understand it, gtp is for one way communication. I've heard of this as
an issue when developers try to provide output for the benefit of players
(or bot developer debugging the bot)
There's typically work-arounds that we use to overcome this.
On kgs, to inform the players, the version
What is the proper way to interpret the score and opponent columns?
On Dec 9, 2007 7:30 PM, Don Dailey [EMAIL PROTECTED] wrote:
I just put up the improved hall of fame page.
I'm using the values Rémi suggests and the values look more in line with
CGOS.
Also, FatMan-1 is fixed at 1800
On Dec 6, 2007 7:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote:
88|0|17.033168
88|1|12.263955
and
164|0|17.388714
164|1|25.862695
Are identical except for swapping the roles of white and black
Curiously, the gamma values in your example are way different
17.033168 vs 25.862595
and
On Dec 6, 2007 10:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote:
On Dec 6, 2007 10:06 AM, Jason House [EMAIL PROTECTED] wrote:
On Dec 6, 2007 7:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote:
88|0|17.033168
88|1|12.263955
and
164|0|17.388714
164|1|25.862695
201 - 300 of 522 matches
Mail list logo
