On 27-nov-06, at 08:35, igo wrote:
It is said if has 4 stones handicap, every Pro will accept games
play with God even if bet his life.
I don't know if that's a generally accpted estimate. But I know that
Otake Hideo once said he'd bet his life with 4 stones against God. He
also added
On 29-nov-06, at 08:43, Stuart A. Yeates wrote:
Other tricks for faster java include ensuring that, wherever
possible, you use the final, static and private keywords. This
enables the compiler to apply more compilation tricks in more places.
More and more I find that using 'final' or
On 4-dec-06, at 15:23, Don Dailey wrote:
But it seems like more of a travesty in Java.
Well, this may be subjective. What may seem like travesty to one may
appear completely normal to someone else.
I'm curious though. If you have the time, could you point out in the
code in my public
Don,
I disagree rather strongly with some of your statements.
On 4-dec-06, at 18:35, Don Dailey wrote:
This isn't a Java issue, it's most if not all computer languages - if
you really go all out to optimize your code for performance, you will
sacrifice readability, clarity, etc.
In
On 31-dec-06, at 15:34, David Fotland wrote:
A strong chinese player using chinese rules will pick up a point or
two
during the dame filling stage when playing a strong japanese
player. The
Chiense player will choose earlier moves that gain a later dame
point that
the japanese player
On 4-jan-07, at 19:37, Don Dailey wrote:
If 2 perfect players played a game where one
was given the 9 stones, and they played for maximum territory
(obviously
it doesn't make sense to play for a win) would the handicapped player
be able to hold some territory at the end of the game?
This
On 4-jan-07, at 18:53, David Doshay wrote:
I see it as perfectly fair that the bot with
the better ability to read, and thus knows it can pass, should be
rewarded for that reading skill.
I think you are mistaken for the real reason of the 'second phase',
where he who passes has to pay a
On 12-jan-07, at 14:16, Chris Fant wrote:
Plus, some would argue that any Go
already is solved (write simple algorithm and wait 1 billion years
while it runs).
To 'solve' a game in the strict sense you need to know the best
answer to every move. And you need to be able to prove that it's
The problem is: how do you check? You'd need twins and have one of
them play Go or Chess.
I even don't know if the intelligence of twins is the same from the
start. When at university there were two identical twins in the same
year. With identical I mean, really identical. They were
This seems to be only a small variation of hashing methods I was
taught at university in the 80s.
The method I always used was simply putting the new value and key in
the place of the old one, with one simple addition. In case the spot
is filled it would look at the next 'n' spots until it
On 21-jan-07, at 19:27, Don Dailey wrote:
not considering biological factors
which would cut into this a bit.
There was a time when there were no time-limits in Go, which was
abused by many players by turning a game into a stamina contest. I
believe this practice was abandoned when
On 7-feb-07, at 02:20, 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.
Don't be discouraged please. The big-mouths don't always represent
what the majority thinks.
The yahoo
On 2-mrt-07, at 16:34, Don Dailey wrote:
Łukasz,
Yes, I would like to see some of these problems solved.
As I mentioned, UCI doesn't have any of these issues.
After thinking about this, there is perhaps a backwards
compatible solution:
1. Don't change GTP, just add to it.
2. Have a
I watched MoGo play a few games on KGS. I think it plays very nicely
most of the time. I find it hard to judge its strength, as it
occasionally does some strange things, but overall it plays a sound
game.
One thing that may make human players biased with regards to its
strength is its
On 6-dec-07, at 19:29, Don Dailey wrote:
Here is an example of why this works so well and why your greedy
approach is so wrong:
Consider a position where there are 2 groups left that are being
fought over. One of these groups is very large and the other is quite
small.The computer
Question: how do MC programs perform with a long ladder on the board?
My understandig of MC is limited but thinking about it, a crucial
long ladder would automatically make the chances of any playout
winning 50-50, regardless of the actual outcome of the ladder. If
this is the case then:
Don,
This has taken me some time to formulate an answer. Mainly because
you are making so many assumption about what I understand or imagine
and what not. It makes for a confused discussion and I didn't feel
like getting into arguments like no, that's not what I meant etc.
Let me
On 5-jan-08, at 11:48, Gian-Carlo Pascutto wrote:
Would you explain the details of the playout policy?
(1) Captures of groups that could not save themselves last move.
(2) Save groups in atari due to last move by capturing or extending.
(3) Patterns next to last move.
(4) Global moves.
I have a Java version of the old Goliath 3. I have a GTP bridge also.
If it's not a lot of work I'd consider putting it on 19x19 CGOS. How
would I go about doing that? (I have a Mac but could possibly arrange
a PC.)
At the moment the Java translation has an annoying bug that I haven't
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Mark Boon
Sent: Wednesday, January 09, 2008 8:52 AM
To: computer-go
Subject: Re: [computer-go] How to get more participation in 19x19
CGOS?
I have a Java version of the old Goliath 3. I have
On 9-jan-08, at 16:11, Don Dailey wrote:
cgos3.tcl is the equivalent of kgsGTP. cgos3.tcl communicates
through stdin and stdout.The Java wrapper will not benefit you
unless it actually provided GTP to a program that doesn't know gtp.
- Don
I hope we're having a bit of
On 9-jan-08, at 15:45, Don Dailey wrote:
The cgos3-darwin.zip client on the web site will attach you to the 9x9
server - unless you actually modify it by unwrapping it, changing it,
then wrapping it back up. If you want, I will wrap up a version
that will work for 19x19.
OK, I think
OK, got it working. But it didn't remove all the dead stones
unfortunately. Is there any way to get the SGF file of the game so I
can test why it didn't do that? Or do I need to save it locally?
Mark
On 9-jan-08, at 19:51, Don Dailey wrote:
Mark Boon wrote:
On 9-jan-08, at 15:45, Don
I see now what people mean with regards to the starting of rounds.
Most bots are idle most of the time while a few slow ones slug it out.
The way it's currently configured was probably the simplest way to do
it and get reasonably uniform results. Otherwise you may end up with
fast bots
I came back to my computer to see an error message about a broken
pipe. I also see my program lost a game on time to Odie, which is
probably caused by this. Is this common? Or does it mean I have a
problem on my end? I do have a rather slow internet connection.
Mark
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Mark Boon
Sent: Tuesday, January 15, 2008 10:11 AM
To: computer-go
Subject: Re: [computer-go] How to get more participation in 19x19
CGOS?
As suggested by David Fotland I made a simple
On 16-jan-08, at 11:54, Christoph Birk wrote:
I think this is very wrong, like allowing suicide.
If you allow (or forbid) moves that cannot really (should) be
played in the
random games you are not sampling the true status of the board.
I think most people take a much too dogmatic point of
On 16-jan-08, at 17:22, [EMAIL PROTECTED] wrote:
We can use math to shed some light on the topic:
* Assume that doubling the speed of a machine
increases the rank of a program by 100 ELO,
as Don has previously concluded.
* Then we have the following table of approximate
costs, which
Don,
Although I'm not interested in this feature at this point in time I
applaud the effort you put into this server.
Just some information with regards to Mac clients: it turns out Macs
come with a tcl runtime out of the box. So you should point Mac users
simply to the cgos3.tcl file
On 18-jan-08, at 12:47, Don Dailey wrote:
I recently read an interesting blog on this, where it was claimed
that
early optimization SHOULD be done when performance is actually a
consideration (and sometimes it isn't.) The idea is that if ignore
performance consideration early, you
I'm fairly new on the subject of Monte Carlo and am in the process of
catching up on reading, so I hope you guys have some patience with me
while I get into this and ask a lot of questions. I got side-tracked
away from computer-Go programming for quite a while for various
reasons but have
On 18-jan-08, at 12:01, Gian-Carlo Pascutto wrote:
But the speed of the random playout becoms less and less important
with heavy playouts.
This I don't understand at all. The improvement curve for being
faster isn't different with heavy than with light playouts.
I see I didn't word this
On 22-jan-08, at 10:31, Erik van der Werf wrote:
On Jan 22, 2008 11:14 AM, Petri Pitkanen
[EMAIL PROTECTED] wrote:
9x9 is not Go
At some point in history the common board size was 17x17.
Are you suggesting that 17x17 wasn't Go either?
In the future, when humans are consistently defeated
On 22-jan-08, at 11:21, Don Dailey wrote:
Hi Mark,
I think it's Petri who was the condescending one.
Well, you could see it as condescending if someone pooh-poohs 9x9 Go.
But then one should argue that if you'd want to. But to pretend by
deduction he also claims 17x17 or 19x19 are not
On 22-jan-08, at 11:33, Magnus Persson wrote:
So feel free to argue that 19x19 has properties that are unique,
but in doing so please *specify* exactly what this means and why a
computer program has to deal with it to play really strong.
Magnus,
Would you argue the same for 3x3 Go?
I
Recently one of the things I've been doing is introducing more and
more generics in my code. In the days when I was using C++ I always
felt templates were a mixed blessing. It's a powerful concept but it
also often makes code extremely difficult to read and debug. Maybe
this has improved a
30, 2008 at 01:15:39PM -0200, Mark Boon wrote:
There's one bit that so far thwarts my effort to obtain maximum
modularization. And that is I have a GoEngine interface that is kind
of mirroring GTP, since GTP is the preferred communication method
between Go-playing engines. My design could be a lot
On 30-jan-08, at 15:06, Jason House wrote:
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 ;)
Which is of course exactly what I said in my message. Maybe it's the
idealist in me thinking we
Although most of my time has been eaten up by implementing/improving
some general framework parts I did get a chance to play a bit with a
simple UCT search. Some things that I found puzzled me a bit and I
hoped someone had an explanation or similar experiences.
I implemented a very basic
At the moment it's not possible to develop iPhone applications. An
SDK comes out this months and we have to wait and see what it supports.
Mark
On 6-feb-08, at 18:21, Don Dailey wrote:
Jason House wrote:
Just curious if anyone knows if this is possible. cgosView has a mac
(universal)
On 12-feb-08, at 17:39, Christoph Birk wrote:
All games that white won W+0.5 would reverse to B+0.5 if you
lowered the komi by 1 pt.
Unless you used some MC bot, then W would still win by 0.5 :)
___
computer-go mailing list
On 3-mrt-08, at 18:43, Don Dailey wrote:
I base that logic on my observations that once the score goes below
10%
for Lazarus, it is losing. It's extremely rare that it salvages a
game
once the score goes below even 20%.
In which case I could argue that attempts at winning by playing
On 4-mrt-08, at 14:34, terry mcintyre wrote:
Knowing that most current programs have a weakness
with regard to nakade, then any program which believes
it is behind ought to try and exploit such weaknesses,
no?
That assumes creating a situation where the nakade is misevaluated
once you're
Lately I have been putting some effort into pattern-matching.
Although I have made progress, the result was not as good as what I
had hoped for by about an order of magnitude. This makes me wonder
what is currently actually the state of the art of pattern matching
in Go.
Of course it's a
By the way, is CGOS working? I get connection refused when starting
the viewer.
Mark
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
is complete, the server
will
shutdown and restart. Don't know if this is an issue, but I
did it
anyway - it does hurt in view of the bug.
- Don
Mark Boon wrote:
By the way, is CGOS working? I get connection refused when starting
the viewer.
Mark
, basically a single
pass statistics gathering. So you must basically show it a gazillion
sample patterns with known classifications.You could build these
from games of strong players for instance.
- Don
Mark Boon wrote:
Lately I have been putting some effort into pattern-matching
a connection error unless the server is off-line.
- Don
Mark Boon wrote:
Strange. I even tried downloading a new file from the web-page. I get
the following:
could not execute couldn't open socket: connection refused
logout
[Process completed]
I used to be able to run it, I'm not aware of changing
:
Mark Boon wrote:
What I have now takes 10-15 microseconds on a 2Ghz Intel computer
to find all the patterns on a board (on average for 9x9, for
19x19 it's more like 15-20 usec)
From your difference between 9x9 and 19x19 I assume that you are
updating
the patterns of the cells after a stone
On 28-mrt-08, at 09:43, Jacques Basaldúa wrote:
The first source code was just an example to see what kind of code
is generated. The second is useful, if you understand asm you
should understand it.
Well, the only serious assembler I ever wrote was on a 6502 :-) And
that was a very long
On 29-mrt-08, at 10:47, Jacques Basaldúa wrote:
I don't use don't care. I mask code in 2 bits: void, own,
opponent, out_of_board. This produces bigger database size,
because the only way to introduce don't care is to repeat the
pattern.
OK, so we were comparing apples and oranges. I know
On 29-mrt-08, at 14:13, terry mcintyre wrote:
Considering how inexpensive memory is, and how
branches cause processor pipelines to stall, it seems
to make sense to convert don't care patterns into
however many fixed patterns would be equivalent. If
there are three don't care elements, which
On 31-mrt-08, at 12:36, Don Dailey wrote:
Are these fixed patterns or wildcard patterns? I'm interested in
wildcard patterns too and how to automatically generate them.
A wildcard pattern is exactly the same as a decision tree (it can be
represented perfectly by a decision tree.)
On 31-mrt-08, at 20:28, Don Dailey wrote:
You could be
blind-siding the program.
I think this is the crux of the matter. Not just in MC but in Go
programming in general. If you add 'strong' knowledge you can create
blind-spots. For example, I guess a ko rarely gets played during
On 1-apr-08, at 17:37, Don Dailey wrote:
That's partly why I'm interested in exploring on the fly leaning.
Learning outside the context of the position being played may not have
much relevance.
That would be most interesting indeed. I'd like to try but keep
running into obstacles.
For
On 7-apr-08, at 11:52, terry mcintyre wrote:
Perhaps folks should upgrade from Windoze to Linux?
ducking real quick
Linux is for hobbyists. Mac OS X rules! ;-)
time for a real my-OS-is-better-than-yours flame war___
computer-go mailing list
On 8-apr-08, at 08:50, steve uurtamo wrote:
There's another way, and it's not too bad, depending upon how
often you want to switch operating systems.
Get a second drive.
Oh, that is so passé! ;-)
I gladly pay $80 for VMWare Fusion and can use whatever OS pleases me
at the same time as
it on only one computer.
Cost-of-ownership is different for everyone of course, but despite
Linux being free it never seemed worth it to me.
Mark
On 8-apr-08, at 12:00, Don Dailey wrote:
Mark Boon wrote:
On 8-apr-08, at 08:50, steve uurtamo wrote:
There's another way, and it's not too bad
On 8-apr-08, at 15:13, Don Dailey wrote:
Cost-of-ownership is different for everyone of course, but despite
Linux being free it never seemed worth it to me.
My main point is that MS has been very successful at making you
feel the
way you do.
I don't want to pretend that I'm not
On 9-apr-08, at 13:11, David Fotland wrote:
Does Linux have a decent development environment yet?
It probably depends on the language. Java has several excellent
development environments that are superior to Visual Studio IMO. And
they're portable. I believe Eclipse can be made to work
On 13-mei-08, at 14:10, Álvaro Begué wrote:
What others do is the right thing to do. Your method will introduce
some biases.
Could you elaborate what bias it could lead to? I also do the same as
Jason. I did consider the possibility of a bias but couldn't
immediately think of one.
What
On 13-mei-08, at 14:15, Don Dailey wrote:
Yes, it's not random at all. The points near the end of the list
are much less likely to be chosen for instance.
OK, I'm not very good at statistics, but I don't see how the last
points are much less likely to be picked. At best they are a
On 13-mei-08, at 15:08, Jason House wrote:
The range of the random number is reduced by one after each failed
lookup. Shuffled data has no impact on future use of the array of
empty points.
OK, I understand now why a point at the end (or beginning) is a
little less likely to be
On 13-mei-08, at 16:17, Don Dailey wrote:
I missed this from you. I assumed that you did this anyway. If
you choose a random point and then traverse linearly to the end,
what do you do when you reach the end? Do you just pass?I
assumed you viewed the empty point list as a
You need to move away from light playouts and play ladder-capturing
and ladder-escaping moves during playout. It will then still
occasionally play out a ladder, but only if it thinks it's far behind.
On 16-jun-08, at 17:20, Peter Drake wrote:
In Sunday's tournament, Orego lost a game
On 17-jun-08, at 22:26, Peter Drake wrote:
Without the 10% random moves, would every playout from a given leaf
be identical?
I have not exprimented with introducing randomness. I always play
ladder-capturing and ladder-escaping moves.
But that does not imply at all that all playouts
Seems David instigated a nice little platform war :)
Oh, platform discussions are sooo 1990s. Don't you guys use a
platform independent language yet?
OK, time to duck...
Mark
___
computer-go mailing list
computer-go@computer-go.org
Like David pointed out, cycles can be very complex. In theory. But
with random playouts I believe only triple-ko is possible. And rare
at that. The reason is simple: it will only keep going on if there's
no choice. Otherwise a deviation will be played at some point,
reducing the situation.
And your idea is an extension and improvement of these 2 things.
I don't agree with all the details, but probably no 2 people would!
- Don
Mark Boon wrote:
It's a question I have often contemplated. I don't think you can do
anything now that will greatly influence what the level in 2010
On 31-jul-08, at 19:50, Peter Drake wrote:
I know we had this conversation recently, but I just can't seem to
get my head around writing a ladder reader. What, exactly, does the
ladder reader do?
Our approach was to read out ladders involving the last stone
played. In the playout
On 31-jul-08, at 21:00, Peter Drake wrote:
What you're missing (or so it seems to me) is that it's not to
prevent from running a ladder that is caught.
Really? My motivation has been to prevent my program from
embarrassingly running in just those situations. Is there something
other
On 1-aug-08, at 14:15, Peter Drake wrote:
On Aug 1, 2008, at 8:08 AM, Mark Boon wrote:
The neighbours of the last move come in the picture because
usually it's only the last stone played that can be escaping a
ladder and it's the neighbours of the last move that could have
been put
I have a SGF parser in Java in my library. I haven't updated it in a
while. You can find the SGF package here:
https://tesujigoframework.dev.java.net/source/browse/
tesujigoframework/TesujiGoFramework/source/tesuji/games/sgf/
I think it's pretty efficient and easy to use. For examples look
First of all, congratulations to the MoGo team.
As some have remarked already, the difference in level between the
fast games and the slow games was considerable. I didn't think the
level of the fast games was anything to boast about. And my opinion
is more informed than many other
Thanks for posting the game Eric.
When I look back at it it's obvious to me S1 was much better. After
the likely sequence of R1, T3, T2, T4, S7, Q1, R7 Black still has a
serious weakness at N4.
I also still question W's play in the upper-right. I doubt W S15 was
a good move and think S19
On 8-aug-08, at 14:16, Don Dailey wrote:
Also, it seems silly to me to find super strong players only to
heavily
handicap them. What's with that?
Actually, that's not so silly. I think a case can be made that super
strong players tend to have a more consistent level than weaker
I'm sure you can find quotes from 'experts' claiming really wild
things on just about any subject.
I think generally that reaching 1-dan in computer-Go was thought to be
attainable with today's hardware but that it would still take
considerable work. I don't think MoGo's recent success suddenly
On 11-aug-08, at 08:56, Basti Weidemyr wrote:
However, maybe we do not need to use these kinds of challenges as a
means of getting media attention.
We would like to find a way to cooperate with the traditional go-
community with little friction. What do you think?
We come in peace! ;-)
On 10-aug-08, at 17:24, Don Dailey wrote:
Of course there is also the possibility of some exciting new hardware
breakthrough around the corner that doesn't just extend Moore's
law, but
blows it out of the water.
Of course there's that possibility. But I'm actually wondering if we
On 11-aug-08, at 15:23, Don Dailey wrote:
But is it really? Now instead of clearly defined rules, you enter
the
domain of judgment calls and these should be minimized.
I don't agree with such an unforgiving attitude at all. It works for
tournaments but not for demonstration games. You
On 12-aug-08, at 10:40, Gian-Carlo Pascutto wrote:
On Tue, 2008-08-12 at 09:15 +0200, Gian-Carlo Pascutto wrote:
Aside from that, it's not theorethically necessary for alpha-beta
to do
wasted work (although it will in practise), and more CPUs can
make the
program worse on any practical
On 13-aug-08, at 00:18, David Fotland wrote:
I don't know that joseki knowledge mad Many Faces stronger. Go
Intellect
always used to turn off the joseki libraries in tournaments against
Many
Faces, since it had a better win rate if it avoided joseki moves.
I suppose
that's some
Not an expert on AB-search or UCT search but there's a subtle
difference I think. In AB search, if some processors have been
searching in a branch that is subsequently cut off, the work is 100%
wasted. In UCT there's no such black-and-white cutting. If you do
sampling in what then turns
Is Microsoft now selling computers? Interesting...
Let me chime in with my congratulations to David.
Mark
On 2-okt-08, at 20:52, Darren Cook wrote:
investment. If we can find corporate sponsors, it should not be hard
to gain access to such hardware. Reading between the lines, I
On 7-okt-08, at 21:40, Don Dailey wrote:
On Wed, 2008-10-08 at 08:25 +0900, Darren Cook wrote:
And now I look at the ATS implementation of binary-trees, it is using
threads, while the C++ version is single-threaded.
Lots of apples and oranges comparisons here :-).
And there is no single
I'm not sure if it's wise to ignore games lost on time. For a MCTS
program it makes sense to adjust the time taken for the move based on
its perceived chance of winning. But that means a program is more
likely to lose on time because it's losing anyway, and that judgement
involves the
On 9-okt-08, at 10:15, Don Dailey wrote:
If the play-outs are uniformly random and you have eye rule, it is
guaranteed to terminate as long as you use simple ko.
I don't think this is quite correct. With using just simple ko
there's a chance you end the game in a never-ending triple-ko.
On 9-okt-08, at 17:39, Don Dailey wrote:
On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote:
Computers + random = can of worms.
What if I get a fast benchmark by implementing the fastest, most
awful, random number generator imaginable? What if every one of my
random playouts looks
On 11-okt-08, at 20:32, Don Dailey wrote:
I believe there have been many attempts to make this work. These
attempts are based on the intuition that the margin approach should be
better even though it is clearly inferior. So in my opinion they
start
with a wrong premise. And this wrong
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
Prompted by a few requests I had very recently with regards to the
computer-Go framework I once started, plus some free time between a
project I just finished and waiting for a visa to start my next, I
have started on a project probably best described by the title of
this message.
On 21-okt-08, at 23:11, Michael Williams wrote:
You could have a copy of CGOS running on a different port that
pairs up anything that
connects to it against itself and starts a new game as soon as the
first game ends.
I don't know if it's a good idea to have it run against itself. I'm
I'm using unit-tests also, although somehow for Go programming not
nearly as much as I usually do.
And I use CruiseControl. It monitors changes in my repository, builds
the project and runs the tests. That way I don't have to think about
it, it happens automatically.
Another thing that I
I'm getting close to something I'd like to show people and get feedback.
One thing to decide is how to make it public. Previously I used
dev.java.net to host my project. But I stopped using it because I had
a very slow internet connection and I was getting annoyed with the
time it took to
FWIW, since I don't have exactly the same outcome yet, but my stats are
Mac Pro 2.8Ghz 2 x Quad-Core Intel Xeon
Memory is 4Gb 667Mhz DDR2
L2 cache per processor (of 4 cores) 12Mb
Java version: Java HotSpot version 1.5.0.16
Run with java -server (javac optimization level of Eclipse is unknown
of
wider lines you get a different number. Or at least you'll have to
include the exploration-factor K in your UCT tree as a criteria.
Mark
On 22-okt-08, at 20:57, Don Dailey wrote:
On Wed, 2008-10-22 at 20:29 -0200, Mark Boon wrote:
On Wed, Oct 22, 2008 at 6:07 PM, Don Dailey [EMAIL PROTECTED
, at 11:19, Don Dailey wrote:
On Thu, 2008-10-23 at 09:38 -0200, Mark Boon wrote:
Don,
I have figured out the discrepancy in the average game length. As
playout length I count from the start of the game, which gives me
114-115. I believe you count from the starting position where the
playout
Thanks again for more explanations. I think the AMAF is clear to me now.
When you say you count all the playouts starting from an empty board,
then
I have no idea how our outcome can be different by 3-4 moves,
which is
coincidentally the average depth of a uniform tree of 1,000,000 moves
on
-okt-08, at 15:32, Weston Markham wrote:
On Thu, Oct 23, 2008 at 1:00 PM, Mark Boon
[EMAIL PROTECTED] wrote:
This is still something I don't understand. Are there others who
implemented
the same thing and got 111 moves per game on average? I tried to look
through some posts on this list
Due to several recommendations from this list I decided to take a
look at git.
After wasting a few hours trying to get the Eclipse plugin to work I
decided to give up. I might give it a look again when it comes with a
reliable installer / update-link.
Any other ideas?
I can keep using
1 - 100 of 249 matches
Mail list logo
