Petr Baudis wrote:
Hi,
is there any way to send game comments through kgsGtp on your own
(without the opponent triggering you)?
I think some possibility to send messages would be great. I could swear
I saw MogoBot do this, but I couldn't find anything in the KGSGtp
documentation.
The
Joshua Shriver wrote:
FPGA boards are expensive
How many gates do you need?
It's not because the eval boards you find everywhere are expensive that
FPGA's are. Low-cost ones go from 10 to 70 USD depending on the gate
count. A bargain compared to an ASIC solution as long as the quantities
are
Mogo is around 2500 on CGOS:
http://cgos.boardspace.net/9x9/cross/MoGo_psg7.html
This implies you believe the ratings didn't shift over time.
http://computer-go.org/pipermail/computer-go/2007-October/011405.html
http://cgos.boardspace.net/9x9/cross/MoGo_monothreadC.html
Jason House wrote:
MoGo uses TD to predict win rates.
Really? Where did you get that information?
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
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 with TD, but MoGo itself
doesn't use TD (directly).
There are posts from Sylvain
Chris Fant wrote:
CGOS 19 is has been stuck for a while now.
At the bottom of the page, it says Many Faces is in a game, but does
not show it as currently playing at the top of the page. Perhaps the
problem is related to a bot leaving near the time a round is
ending/beginning.
I guess Oliver
Rémi Coulom wrote:
In Crazy Stone (maybe that is the case of MoGo, too), nakade is such a
big problem because the program avoids playing self-atari in playouts.
Crazy Stone will play the self-ataris anyway, but with a low
probability, so they are played at the end of the playout only. In case
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 double that because of the protocol, right?
Yes, the server sends out the move
Yamato wrote:
I guess the current top programs have much better playout policy than
the classical MoGo-style one.
The original policy of MoGo was,
(1) If the last move is an Atari, plays one saving move randomly.
(2) If there are interesting moves in the 8 positions around the
last move,
Yamato wrote:
I finally improved my playouts by using Remi's ELO system to learn a set
of interesting patterns, and just randomly fiddling with the
probabilities (compressing/expanding) until something improved my
program in self-play with about +25%. Not a very satisfying method or an
Don Dailey wrote:
It's not very clear to me how strong Mogo is at 19x19. I have no idea.
Can't we estimate from KGS games?
You'd need to know exactly how fast the hardware is, of course.
--
GCP
___
computer-go mailing list
Olivier Teytaud wrote:
Also, there are probably other people interested in combining
UCT and mpi; I don't know if some people have a more precise idea
of the level of the MPI+UCT combination than us. Someone ?
MPI is just a parallel programming model/library, right?
So the only thing to know
Michael Williams wrote:
Gian-Carlo Pascutto wrote:
Olivier Teytaud wrote:
Also, there are probably other people interested in combining
UCT and mpi; I don't know if some people have a more precise idea
of the level of the MPI+UCT combination than us. Someone ?
MPI is just a parallel
Don Dailey wrote:
But with the type of scoring that MC does (where we optimize for winning
percentage over score) it's more difficult to construct go problems.
You have to construct them so that you LOSE the game if you don't play
the right move, but if you do play it you win the game.
Hideki Kato wrote:
No. Remember UCT is a sequential algorithm. Parallelizing UCT make
playouts ineffective. Increasing the number of threads and/or
communicating delay decreases the effectiveness of the playouts. With
my experiments on a symmetrical threads implementation on a four core
Hideki Kato wrote:
What is correct move? It has sense only for some artificial
problems or very limited positions, and so, it cannot evaluate total
performance of a program.
This is true, but we are interested in search performance. So, it makes
sense to evaluate on those positions where
No wonder it plays so well at 9x9, because the max length of playout is
only
81, it can 'see' what the board look like when the game ends.
The *average* length of a 9x9 playout is roughly 100 moves.
The max length is much larger.
On a 2.2Ghz Athlon64, I get about 10 000 playouts/second, at
Playing randomly like that shouldn't work, but when you play Mogo et al,
you see that intelligent behaviour emerges.
Although interesting, I would hardly call that 'intelligence' :-)
Ah, the traditional flamewar topic: the definition of intelligence
shifts whenever a computer achieves what
Harri Salakoski wrote:
The *average* length of a 9x9 playout is roughly 100 moves.
The max length is much larger.
The *average* length of a 9x9 playout is roughly 100 moves.
The max length is much larger.
Hmm, sorry if this is old subject but does it effect much for playout
quality if I cut
Rémi Coulom wrote:
Gian-Carlo Pascutto wrote:
Multi-stone suicide is allowed, single stone not.
Strange. The reverse would make more sense to me.
I do not track liberties, so the speed penalty for doing it that way is
too much.
I wrote my program to track psuedoliberties because
[EMAIL PROTECTED] wrote:
Um, by easier I mean faster. Also, I think single point suicide is more
likely to lead to infinite loops, depending on your eye-filling rule.
- Dave Hillis
Yes.
Particularly near the end of the game there are zillions of bad single
stone suicides, but not often
Christoph Birk wrote:
On Jan 15, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote:
Um, by easier I mean faster. Also, I think single point suicide is
more likely to lead to infinite loops, depending on your eye-filling
rule.
- Dave Hillis
I don't understand why anyone would allow suicide in
Gian-Carlo Pascutto wrote:
Multi-stone suicide is allowed, single stone not.
I hadn't even considered suicide.(It would be a major change for me,
as neither my Gui nor my board system allow such moves.)
The question is Why do you do it?
a. Just in case you wanted the entire program
terry mcintyre wrote:
That key play might even have been discouraged by some pattern.
MoGo probably does not allow self-ataris. If you do not allow self-atari
you cannot see such a shape is dead.
--
GCP
___
computer-go mailing list
So I wouldn't be surprised at all if at some point you'll see a
marriage of the best ideas of traditional Go programs and Monte-
Carlo / UCT. In fact, this is most likely already happening as these
Monte-Carlo programs use algorithms / ideas from the traditional
programs for tactics,
John Fan wrote:
If we are talking about real suicide, I do not see any point to allow
the real suicide in the play out. What would be the gain if we allow the
real suicide in the play out.
The answer to this question has been given at least 3 times:
Speed.
It can take time to disallow a
Mark Boon wrote:
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
David Fotland wrote:
This is an odd idea. When computers started beating people in chess, humans
did not abandon the game and change to some other similar game. Why do you
think go players would stop playing go when computers get strong?
At some point human players playing computers started
Don Dailey wrote:
If a nakade fixed version of mogo (that is truly scalable) was in the
study, how much higher would it be in your estimation?
You do realize that you are asking how much perfect life and death
knowledge is worth?
--
GCP
___
Don Dailey wrote:
I must not understand the problem. My program has no trouble with
nakade unless you are talking about some special case position.My
program immediately places the stone on the magic square to protect it's
2 eyes.
Can your program identify sekis? Nice examples in
Don Dailey wrote:
So I think this is nakade.
Yes. Leela 0.2.x would get it wrong [1].
[1] Not eternally, but it would still take unreasonably long.
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
Don Dailey wrote:
Yes, the tree generates pass moves and with 2 passes the game is scored
without play-outs.
How do you detect dead groups after 2 passes? Static analysis? All is
alive/CGOS?
I can't believe mogo doesn't do this, it would be very weak
if it didn't.
That's just an
Don Dailey wrote:
I am concerned that the current study is, as Jacques has so ably
described, a study of a restricted game where nakade and certain
other moves are considered to be illegal; this restricted game
approaches the game of Go, but the programs have certain blind
spots which humans can
Don Dailey wrote:
I don't know how David figures 1000 ELO, but I would expect the
difference to be much larger than that for 19x19 go. I don't believe
they are yet very close to 1 Dan.
http://www.gokgs.com/graphPage.jsp?user=CrazyStone
You're right. They're closer to 2 Dan.
:)
--
David Fotland wrote:
So, can the strong 19x19 programs please tell us your playout rates? I
expect the higher the rank, the fewer playouts per second. I'm not
interested in 9x9 data, since I think much less go knowledge is needed to
play 9x9. With your playout rate, please include the
Andy wrote:
CrazyStone hasn't played since the initial spike to 1k in December. The
movement of the chart afterwards is rating drift.
Ok. For me this is actually GOOD news :)
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
Michael Williams wrote:
So do I. I just stated a simpler version here because I previously
suggested a more integrated approach and got zero replies. I'll state
it again:
Start with a UCT+MC engine. When a tree node reaches X number of
playouts (1000?, 1?), do a tactical analysis.
Harri Salakoski wrote:
Hi such question that do you typically traverse all child objects or is
there faster way to select explored node child object.
I have concluded that it is not at least easy as multiple nodes uct
values change each simulation so trying to keep biggest uct value in
first
I'm not sure what to think about the following:
Leela 0.3.0 vs Leela 0.3.7, 455 game match
177 vs 278 = +78 ELO points for Leela 0.3.7
CGOS rating
Leela_0.3.0_1CPU 2335
Leela_0.3.7_2CPU 2333
Hmm..but also
Zen-0.9 2386
Zen-1.0 2385
or more:
Uct-200801122348
Uct-200801132334
Olivier Teytaud wrote:
Basically, the formula in MoGo combines the success ratio and the
RAVE-success ratio, with more focus on the success ratio when the
number of simulations is large.
You have no bias which favors exploration at all?
--
GCP
___
I also implemented RAVE in Mango. There was a few points of improvements
(around 60 Elo points with gnugo as reference), but as much as in the
paper of Gelly and Silver :( (around 250 Elo points if I remember well)
It might be that the effect of RAVE depends a lot on the simulation
strategy.
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] =
color) by tracing the moves and the colors returned by the playout
forward
Hi Jonas,
welcome to the list.
The idea of using f(score) instead of sign(score) is interesting. Long
ago, I tried tanh(K*score) on 9x9 (that was before the 2006 Olympiad, so
it may be worth trying again), and I found that the higher K, the
stronger the program. Still, I believe that other
Hideki Kato wrote:
delta_komi = 10^(K * (number_of_empty_points / 400 - 1)),
where K is 1 if winnig and is 2 if loosing. Also, if expected
winning rate is around 50%, Komi is unmodified.
I don't think the formula you posted is correct.
In the opening it gives delta_komi = 0.8 and in the
Hideki Kato wrote:
Gian-Carlo Pascutto: [EMAIL PROTECTED]:
Hideki Kato wrote:
delta_komi = 10^(K * (number_of_empty_points / 400 - 1)),
where K is 1 if winnig and is 2 if loosing. Also, if expected
winning rate is around 50%, Komi is unmodified.
I don't think the formula you posted
Magnus Persson wrote:
Quoting Don Dailey [EMAIL PROTECTED]:
Just to make it clear, the case we want to fix is the case where many
bots are programmed to resign. Lazarus will resign when the score is
below 1% (and has remained so for a couple of moves in a row which is
probably just a
Unfortunately, no-one has yet registered. If you are considering
entering, please do so soon (either by telling me or via the Congress
web site), otherwise there is a danger that the computer event will be
cancelled.
To prevent chicken and egg problems:
for me both the timing and the
So to sum up we have the following pseudo code :
at a given node :
- find the child (among the visited child only) that maximizes de UCT-RAVE
value
- if this maximum UCT-RAVE value is less than FPU value and if there still
exisits unvisited nodes :
choose one unvisited node
- continue
Hi all,
the result of the scalability study at
http://cgos.boardspace.net/study/13/index.html
seems to look a lot like 2 parallel lines over the entire range, which I
find very surprising, since I'd have expected at least some differences
caused by different playout strategies.
I am now
Olivier Teytaud wrote:
I am now wondering if scalability could be unaffected by playouts
(just adding a constant offset) and only depend on the UCT/search
implementation. From the publications of the MoGo team it seems likely
that the programs are very similar there.
Leela and mogo are
Olivier Teytaud wrote:
light-playout variant of leela, but perhaps the
nakade-patch version of mogo and maybe even some third
no problem for the nakade-patch version of mogo, but results
are only known in 9x9, no idea for 13x13. Maybe it is better,
maybe it is worse :-)
At 9x9 you see a
Don Dailey wrote:
Gian-Carlo,
We could probably add this new version to the mix and extend the
study.But what kind of data has your own testing produced? Do you
have an indication that it is roughly as strong at the same basic time
setting (because of it's being 3X faster or so?)
It is
[EMAIL PROTECTED] wrote:
Doesn't the total number of playout simply relates to the search ply depth?
I have no idea what you mean or what the relevance is in the discussion.
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
Martin Møller Skarbiniks Pedersen wrote:
Since I sell software, building Linux apps is out of the question, since
Linux users will insist that I give them my work for free.
OK ? Many companies creates linux software and make a good living.
Sendmail is one of them.
They don't make a living
A van Kessel wrote:
decades it has been understood that a chess program with a better
evaluation function improves MORE with increasing depth than one with a
lesser evaluation function so it appears that Go is not unique in this
Well, isn't that trivial?
suppose, you have a perfect
A van Kessel wrote:
I don't understand how what you describe relates at all to the study.
It doesn't.
It is a reaction to Don's explanation of it.
I don't think what you say can relate in any way to chess
or alpha-beta either.
Alpha-beta gets better with increasing depth even with a random
Don Dailey wrote:
It looks like we have a clear trend now. Light play-outs do not scale
as well as heavy play-outs.
This is the same behavior we get with computer chess. For the last few
decades it has been understood that a chess program with a better
evaluation function improves MORE
Don Dailey wrote:
First of all, I am not aware of any published work on this specific
thing. There may be some, but I'm not aware of it.
Thanks, this was what I was curious about.
The rest of your story is rather anecdotal and I won't comment on it.
Note that I agree on the starting
Don Dailey wrote:
The rest of your story is rather anecdotal and I won't comment on it.
Are you trying to be politely condescending?
No! Thing is:
1) I disagree with quite a few things which I have no interest in
arguing (much) about because...
2) I wouldn't trust any opinion (including
I attached the fixed version to this email. Thanks for your help.
Leela 0.3.14
1k - 19/50 passes
10k - 28/50 passes
100k - 36/50 passes
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
Don Dailey wrote:
BOTH versions have NullMove Pruning and History Pruning turned off
because I feel that it would bias the test due to interactions
between selectivity and evaluation quality (I believe it would make
the strong version look even more scalable than it is.)
There is nothing in
Evan Daniel wrote:
It is entirely within the power of the other bots to not lose on time.
I am not sure that is true.
LeelaBot should be perfectly capable of playing about 12 moves per
second in the default configuration.
However, it seems either KGS or kgsGtp do not (correctly) account
Don Dailey wrote:
Gian-Carlo Pascutto wrote:
If it is indeed a KGS flaw I may add a workaround to Leela as simple
as doing time = time / 10 as soon as winrate 95% or so. There is
still a possibility of losing on time then but it should happen less.
That is almost the identical heuristic
Rémi Coulom wrote:
Some answers by the organizers.
[...]
2) Cluster Computing
Is allowed. However, we don't have confirmation regarding the
internet access. The Chinese are busy with it.
I am surprised. I thought that remote hardware would be forbidden for
the go tournament.
For sure
Peter Drake wrote:
I *think* the
two processors are actually two-way hyperthreading, but
I'd have to check.
physical id : 0
[...]
physical id : 0
They are indeed hyperthreading, not real CPUs.
--
GCP
___
computer-go mailing list
Ian Osgood wrote:
By contrast, the ICGA Go events never get top candidate program
participation, and before this year have had smaller turnouts than the
chess event. Since the expiration of the Ing Prize, the last event of
any kind which had such participation was the 2003 Gifu Challenge (KCC
This was just announced on the ICGA Tournaments web site:
http://go.nutn.edu.tw/eng/main_eng.htm
It is right before the Computer Olympiad, and registration is free for
participants in the Olympiad.
That event runs 26 (computer-computer) and 27 September
(human-computer). The Human-Computer
As I'm sure all those interested already know that there is
a computer go event in European Go Congress:
http://www.computer-go.info/egc2008/
If someone needs an operator, I can be one (as I have been in Sweden
several times, so sightseeing on the rest days is not a must for me).
Álvaro Begué wrote:
On Sun, Jul 20, 2008 at 3:40 AM, Rémi Coulom
[EMAIL PROTECTED] wrote:
Rybka 3 has Monte-Carlo evaluation:
http://www.chessbase.com/newsdetail.asp?newsid=4772
If I understand the release note correctly, Monte Carlo Analysis is
something like a feature of the GUI for
Hi all,
there doesn't seem to be any news from the European Go Congress.
Nevertheless, I see that partial results were posted:
19 x 19
Results
1st Crazy Stone 6/6
2nd Leela 5/6
3rd Many Faces of Go4/6
9 x 9
Results
1st Leela
Xiao Ai Lin, 1p vs LeelaBot
This game did happen. It was not meant as a challenge, but as a
friendly game to get an idea of what can be done to develop the
leading programs on 9x9. It was relayed to the cinema-screen as a
warm-up before MoGo's game.
I will be back with the review as an
In message [EMAIL PROTECTED],
When I look at the game record, I see that at the end, the pro has 7:59
left, Leela 4:25. And Black is totally lost: White will capture the d4
group which only has two liberties, connecting her three groups which
already have at least four liberties each, and
In message [EMAIL PROTECTED],
This was foolish of me because I had resumed the game, and was allowing
LeelaBot's time to pass. I have carelessly destroyed the evidence of
LeelaBot's remaining time. There is now only my word (and perhaps the
operator's) for my claim that LeelaBot had more
Erik van der Werf wrote:
On Mon, Aug 11, 2008 at 4:54 PM, Gian-Carlo Pascutto [EMAIL PROTECTED]
wrote:
She was also a bit unlucky in the sense that Leela did not
understand it was dead lost.
I use quotes because had it understood better it was losing, it
would have put up more of a fight
Don Dailey wrote:
On Mon, 2008-08-11 at 17:26 +0200, Rémi Coulom wrote:
Basti Weidemyr wrote:
What would you have done in a case like this? :)
You could not declare that game a win for the computer and survive.
Yes, and I really hate this. You have a situation where the actual
winner has
Robert Waite wrote:
whether or not computers can beat humans at go on a
19x19 board in a reasonable amount of time is unrelated
to mathematics.
Why? Let's say you can prove that the game is solvable so that black
wins. Let's say that you can prove that it is solvable in linear time.
You
terry mcintyre wrote:
I guess we're all different. Last week, I actually did win a 9-stone
handicap game in a simul match against a pro, but I'm not about to
claim that this gives me bragging rights or anything, lol.
[explanation of how this game made you a better player deleted]
I see.
If
Jason House wrote:
On Aug 11, 2008, at 4:00 PM, Don Dailey [EMAIL PROTECTED] wrote:
I would be angry if I worked hard to control my time usage, only for my
opponent to be forgiven at my expense, despite the rules.
Hmmm... This sounds very familiar...
Yes. Notice how there is a clear
Erik van der Werf wrote:
You're right, my reply was sloppy (it seems I'm too much used to
Japanese rules). Also I should have read GCP's email more carefully; I
did not realize that his program, even with a large tree, would not be
able to recognize the seki. I knew of course that the original
terry mcintyre wrote:
Thank you! At present, computer go programs may be strong relative to
each other, and they may actually beat some humans of moderate
ability, especially at timescales too quick for amateur humans, but
most programs also have high-kyu-sized gaps in their knowledge,
My first impression of watching the game was that Leela was handicapped
by having a handicap. By that I mean it would have seen itself so far
ahead for the first few moves that is was playing arbitrarily.
In fact, Leela thought itself ahead at 80% for most of the game. It's only
in the last
Uct also has the advantage that it is much easier to use with multiple
CPUs. I know parallel alpha-beta exists, but my evaluation function is
not designed to be thread safe. If I put a big lock around it, there will
be almost no SMP scaling, since almost all the time is in the evaluation,
On Mon, 2008-08-11 at 20:39 -0700, David Fotland wrote:
Uct also has the advantage that it is much easier to use with multiple
CPUs. I know parallel alpha-beta exists, but my evaluation function is
not designed to be thread safe. If I put a big lock around it, there
will be almost no SMP
Mr. Okasaki, a strong amatur, tested MoGo with a 9 stones handicap
game at winning rate around 50% by adjusting komi on each move and
reported it played clearly stronger than others, say, on KGS and the
cluster version at Paris.
Unfortunately it sounds rather like a subjective measurement.
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 architecture (mostly due to locking and
memory bandwidth
On 12-aug-08, at 10:40, Gian-Carlo Pascutto wrote:
Well... no. Because if you have a perfectly ordered tree, in theory,
you don't need to search at all.
You need to search it to *prove* that it's perfectly ordered :-)
--
GCP
___
computer-go
On Tue, 2008-08-12 at 15:40 +0200, Gian-Carlo Pascutto wrote:
Even in the theorethical case of a perfectly ordered game tree?
I'll have to check my facts, but I remember seeing actual numbers on
this. It has something to do with the minimial tree and it was a proof
think that alpha-beta
Don Dailey wrote:
We need to define terms so we don't end up arguing about something we
probably agree on.
Here is my assertion (which I admit needs to be checked):
Given perfect move ordering, but not a-priori knowledge of this, a
parallel program will search more nodes on average than a
Jason House wrote:
Maybe the best method is to mix the top down
style of MTD(f) to drive localized alpha beta searches.
MTD(f) *is* a sequence of alpha-beta searches.
I definitely don't have all the answers.
MTD(f) doesn't parallelize any better than normal alpha-beta. The only
Don Dailey wrote:
Here is an important snippet, but proofs follow in the paper:
The critical path length C is the time it would take for the program
to run on an infinite-processor machine with no scheduling overheads.
Note that it doesn't mention anything about useful WORK, because this is
steve uurtamo wrote:
And what language/platform is Mogo written in; C/C++, Java, Assembly, PHP,
etc.?
This made coffee spray out of my nose (PHP).
I think that C is most likely, based upon how they parallelized it. Did you
read the list posting that mentioned (briefly) how they scaled it up?
Mark Boon wrote:
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
One might consider heuristics like AMAF, pattern knowledge, etc. to be
simply a more effective way to guide exploration. The UCB term has no
domain-specific knowledge. It works surprisingly well but it should be
no surprise that one can do better with domain-specific knowledge.
The problem of
Andy wrote:
I think for bot vs human, the time control should include
byoyomi/overtime of some kind instead of sudden death. I'm afraid in
one of these exhibition matches the human will be winning but lose on
time. It would be especially bad if the bot was playing meaningless
invasions or
Andy wrote:
Just to prevent losing a won game on time.
By the way, most bots on KGS resign lost games. So most people who lose
on time are usually in a lost position themselves.
There are exceptions with difficult LD situations, but really, I expect
almost nothing to happen to the bots
Rémi Coulom wrote:
I would like to see MogoTiTan play many rated games on KGS and see how
it does there. Anyone have a few million dollars lying around to
sponsor this? :)
Leela is becoming strong. It has reached 1k now.
The gold medal in Beijing will not go to France without a fight!
Don Dailey wrote:
In such a case, I think it's better for the human not to have a time
control at all. This is more satisfying than having a human lose on
time, but giving the win to him anyway under the assumption that he
didn't really need all that time even though he used it.
I think
Especially I was able to reproduce the
following behaviour of MC in a very clear model:
MC is playing most goal-directed (zielgerichtet
in German) when the position is balanced or when
the side of MC is slightly behind. However, when
MC is clearly ahead or clearly behind it is playing
Don Dailey wrote:
That probably just means I have not stumbled on the right ideas or that
I was not able to properly tune it. I would be delighted if someone
was able to show us a workable scheme. I believe if something is found
it will result in a very minor improvement, but that it will
Don Dailey wrote:
Would a discrepancy on the amount of ELO gained or lost per handicap
stone, when comparing MC bots to humans classical computers, be a good
measure of the maximum possible improvement?
Maybe. How could you accurately make such a measurement without
thousands of games?
1 - 100 of 244 matches
Mail list logo
