Christian Nentwich wrote:
Steve,
I wouldagree with you that writing a good score estimator is extremely
difficult, probably as difficult as writing a computer player.
However, your argument of equivalence (if that is how I understand it)
does not follow. Just because you can score any
Fred Hapgood wrote:
I have a really basic question about how MC works in the context of Go.
Suppose the problem is to make the first move in a game, and suppose we
have accepted as a constraint that we will abstain from just copying
some joseki out of a book -- we are going to use MC to figure
George Dahl wrote:
I think he is missing the tree search part. Just doing a one-ply
lookahead and then doing playouts will not make a strong bot. I would
like to defer an explanation of UCT (or something else) to someone who
is more of an expert.
UTC would add little if MC itself were not a
Ingo Althöfer wrote:
A program named stv has won the 9x9-KGS bot tournament
today by a laaarge margin, ahead of Fuego, Zen9, Aya,
Valkyria and Rango.
More details under
http://www.gokgs.com/tournEntrants.jsp?sort=sid=463
Does someone here know who stv's programmer is?
Ingo.
The only
Darren Cook wrote:
It's just a can of worms to require some proprietary binary that people
have to use, trust, and believe is unhackable.
Reverse-engineering the binary itself to then make your own client is
still a risk, but is a specialist skill beyond most go programmers.
I could most
Ingo Althöfer wrote:
During the last few days I have been meditating a lot about
the questiion whether taking into account the margin of
win into MCTS (UCT) may help or hurt.
I do not have a go program by my own, so for the moment
I have to believe what programmers are saying, namely
that MCTS
Don Dailey wrote:
Are you speculating that if enough play-outs are done, the idea might
prove to be superior?I never actually considered that. So perhaps
with 5000 playouts using the win/loss score wins, but at 50,000 using
the margin might be better? This is easy to test with simple
Don Dailey wrote:
I can't think of any really clever way to handle this. Here is about
the best I can think of right now:
Keep statistics on each program - how often it loses due to time or
illegal moves. Use those statistics to reduce the impact of the rating
formula. I could
Don Dailey wrote:
The utility of CGOS wouldn't change except for the better.The way it
works is this:
After each game:
1. The ill-behaved bot gets rated by the full formula.
2. The opponent of the ill-behaved bot gets a smaller adjustment
than usual.
Excellent, that makes
Don Dailey wrote:
Hideki Kato wrote:
I'd like to give here an example to make things clear.
The conditions are:
1) Using digitizing scheme that maps real score to [0,1] (or [-1,1])
so that the program cannot distinguish losing/winning by 0.5 or 10.5
pt at all.
2) Playouts include some
Don Dailey wrote:
Raymond Wold wrote:
Don Dailey wrote:
No. cgos does not use GTP protocol for communicating with server.
Also, I have eventual plans to extend what is communicated to the
client and this is not compatible with the current GTP set.
The more you add as requirements
Don Dailey wrote:
No. cgos does not use GTP protocol for communicating with server.
Also, I have eventual plans to extend what is communicated to the
client and this is not compatible with the current GTP set.
The more you add as requirements on the client side, the more those bot
coders
Once we're on the topic, is there a good reason why CGOS does not use GTP?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
ivan dubois wrote:
It does use GTP.
I mean, why do you have to download a client to run locally? Why can't
you just use GTP directly against a socket?
___
computer-go mailing list
computer-go@computer-go.org
Nick Wedd wrote:
Another fix which would have worked in this case: if after consecutive
passes your opponents proposes a set of dead groups which would cause
you to win, then accept.
I don't think kgsGTP tells you what dead stones are being proposed. You
just have to give your own opinion,
Heikki Levanto wrote:
On Thu, Jan 17, 2008 at 10:36:09PM -0500, Michael Williams wrote:
I have not tried it myself, but I'm guessing it will not improve your
engine. The cost of testing for simple ko is negligible and allowing it
will probably prolong the playouts.
I am not far enough with
Jason House wrote:
On Jan 18, 2008 11:30 AM, Raymond Wold wrote:
With simple ko checking, around 3% of games ended in infinite loop with
double ko.
Double ko's should not have an infinite loop. black takes ko A. White
takes ko B. Black can't retake ko B, so must fill ko A. White
On Fri, 2008-01-04 at 16:50 -0800, steve uurtamo wrote:
TCP/IP communication can be viewed as round-trip.
UCP is one-way, TCP requires a response for each
packet.
For a high-level protocol, it's all the same. The fact that a TCP/IP
packet is acknowledged matters not at all because the
On Tue, 2007-12-11 at 21:17 -0500, Don Dailey wrote:
But what does this have to do with anything? What we are arguing
about is whether it's good to try to estimate probabilities. That's
what you have been critical of. Adding ladder code will improve any
evaluation function if done
On Tue, 2007-12-11 at 13:45 -0500, Don Dailey wrote:
Do you know of an approach that evaluates go positions perfectly?You
are attacking the fact that MC programs have errors in their probability
estimates but completely ignoring the fact that SO DOES EVERY OTHER
EVALUATION FUNCTION.
I
On Thu, 2007-12-06 at 14:21 -0500, Don Dailey wrote:
However, the estimated probability of winning may be way off. It is
well known that Mogo, and perhaps some other programs, fail to
recognize common nakade placements, which leads to fundamental
estimation errors. An algorithm with more
The general rule (in my opinion) is that playing strength will require a huge
amount of power because that's what A.I. is. This in no way implies that
it should not be efficient or that it should foolishly squander resources
(as an internal combustion engine does.) Instead it should be
Don Dailey wrote:
Raymond Wold wrote:
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded C is fastest (next to properly code assembly) and if performance
is your goal, then anything else accepts some
Dave Dyer wrote:
Arguments about the quality of compiler optimizations vs. hand coding
are pointless, because programmers optimize programs in ways that compilers
are (correctly) forbidden to do; by changing the algorithm.
I've heard of no such law or rule. There are several compilers or
Jacques Basaldúa wrote:
Of course, what is cool is very subjective debate: Some people
find it cool to depend on runtimes that increase at mega/month rate,
do what the API already does only much worse, gift the user with the
gray rectangle experience even on a quad-core. After two seconds of
Don Dailey wrote:
So I must give up on this. I know if I do the plot again someone will
say, it only applies to depths we can currently test. Surely it
will flatten out next year when the new processors come.
I cannot answer to those arguments when no evidence is presented to back
it up
Dave Dyer wrote:
Languages like SQL and Prolog don't specify algorithms, they describe
the desired result.
What's the difference? The two are very much intermingled when you get
to high-level optimizations.
I agree that the quality of compilers that turn these
specifications into
Nick Apperson wrote:
But, to be fair, I totally agree that compiling python or ruby would give
you noticable speed gains. And as always, speed comparisons are only useful
in context. In terms of go programming if you are prototyping use
whatever the hell you want. If you are finishing
Don Dailey wrote:
For that, C currently appears to be the best choice.This in not
just my opinion, there is empirical evidence to support this claim.
The problem with empirical evidence is that you don't get the very
much needed all else being equal. The people that code in C (and get
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded C is fastest (next to properly code assembly) and if performance
is your goal, then anything else accepts some compromise. That
compromise may work well for a
Nick Apperson wrote:
If
you can't avoid memory leaks, fine, don't use C++ or C, but don't blame the
language. You could use garbage collection if you need it; don't make us
all stoop to your level of competency and don't try and claim that your
language is just as fast when it isn't.
There
terry mcintyre wrote:
An interesting recap of how the hype can sometimes far outpace the reality:
http://www.cs.ualberta.ca/~chinook/project/legacy.html
I liked this quote from Robert Nealey, which I think is applicable to go
as well;
By sticking to its programmed instructions, it may find
Dmitry Kamenetsky wrote:
I have been reading this list for nearly a year now and it is very discouraging
to receive so much criticism for my first post.
The yahoo groups was merely an example to show how easy it is to get a forum
started. I also agree that yahoo appends too much spam to its
33 matches
Mail list logo
