On 5/06/2016 5:36, "Ingo Althöfer" wrote:
> For all who do not know: LeelaBot is active on KGS,
> with a very stable 3-dan rating:
> http://www.gokgs.com/gameArchives.jsp?user=leelabot
For what it's worth, the 3d was established by an older version that
played the KGS tournament last month. The
Hi all,
I've done a major update of Leela, including integration of DCNN, and
optional usage of OpenCL to speed things up via the GPU.
https://sjeng.org/leela.html
I put a GTP commandline executable on the page. I hope the other people
developing engines find this useful - I found the dearth of
On 2/06/2016 0:21, David Ongaro wrote:
>> Note that the cuDNN license allows you to install and use as many
>> copies of the software as you need, for both individual and
>> corporate use. This intentionally permissive license is designed
>> to allow cuDNN to be useful in conjunction with
On 31-05-16 22:56, David Ongaro wrote:
> Isn't e.g. TensorFlow Apache 2.0 license and would allow its
> inclusion in commercial products?
TensorFlow relies on CuDNN for good GPU performance. Almost all
libraries do, because CuDNN is hand optimized by NVIDIA, and hence
rather hard to beat.
On 31/05/2016 20:45, David Ongaro wrote:
> I suspect Aja is right and Remi should go the path of integrating the
> GPU even if it's just to get more "oomph" for CS. That he tried to
> learn GPU programming from scratch is a noble attempt but I guess
> it's just to ambitious to accomplish in a
On 23-05-16 13:57, "Ingo Althöfer" wrote:
> Hi Gian-Carlo,
>
>> Unsurprisingly, self-play favors extreme selectivity, but this does not
>> hold against other opponents.
>
> is this just your personal experience, or are there systematic experiments on
> this?
> Is it true "only" for MCTS (and
On 22/05/2016 23:07, Álvaro Begué wrote:
> Disclaimer: I haven't actually implemented MCTS with NNs, but I have
> played around with both techniques.
>
> Would it make sense to artificially scale down the values before the
> SoftMax is applied, so the probability distribution is not as
>
On 10-05-16 16:20, Detlef Schmicker wrote:
> OK, this thread is quite long, and I am not sure I saw all posts
> :)
>
> My suggestion, rate the bots on CGOS before the tournament and
> take this rating for McMahon or for handicaps.
This doesn't work for the reason stated in the exact post you're
On 10-05-16 00:14, Erik van der Werf wrote:
> Oh that's silly! IIRC if your bot is not ranked than users can do all
> kind of cheating in the scoring phase (e.g., mark all your living stones
> dead).
I've not observed this behavior so far. Perhaps because in an unranked
game there's no rating to
On 10-05-16 11:23, Hideki Kato wrote:
> CGOS is better place for those lower programs, isn't it?
Not really, the pool of opponents is smaller and contains no humans. It
sort of depends on what the goal of the author is. Even if she's only
interested in measuring vs other computer opponents, a
On 10-05-16 14:39, Adrian Petrescu wrote:
> If KGS is indeed still doing that thing where your rating change is
> anchored to your opponents' ratings changes long after your game has
> finished, then it seems to me the right solution is for wms to simply
> disable that anchoring for accounts that
On 10/05/2016 0:01, Erik van der Werf wrote:
> Well then why not make that a criterion for entering the tournament? For
> any half-decent bot it shouldn't be hard to get a rating.
FWIW I requested ranked status for LeelaBot 3 weeks ago and this was not
granted.
Technically I'm not sure if this
On 9/05/2016 23:16, Erik van der Werf wrote:
> Why not McMahon? (possibly with reduced handicap). It works fine in
> human Go tournaments.
http://senseis.xmp.net/?McMahon
How does this work? That page doesn't mention handicaps. Indeed, the
idea seems to be to eliminate large strength
On 09-05-16 16:04, "Ingo Althöfer" wrote:
> Another point for discussion:
> Although there were only six participants they split in
> at least 4 classes, seperated by large gaps in strength:
> Zen >> abakus, HiraBot >> LeelaBot >> Imrsel, matilda
> Perhaps it makes really sense to think about a
On 16-03-16 22:17, Clark B. Wierda wrote:
> I'm not familiar with emscripten, but there is a process that will
> produce Javascript from Golang code that seems to be pretty robust.
emscripten is extremely robust and will produce much faster (and hence
stronger) results than a golang->JS
On 27-04-15 09:03, Ingo Althöfer wrote:
Some years ago, Gian-Carlo Pascutto had provided a large-board version of
Leela. For that he had introduced a natural extension of the sgf
board-coordinates.
I just followed the official specification, which allows up to 52x52:
http://www.red-bean.com
Hi all,
I'm trying to connect Leela to KGS after a period of absence, but I'm
running into the following error with kgsGtp 3.4.1:
8-feb-2010 22:30:41 org.igoweb.kgs.client.gtp.GtpClient d
SEVERE: Unexpected disconnect: Error No buffer space available (maximum
connections reached?): connect while
Ben Lambrechts wrote:
If you really want to test MFOG against Fuego, it is better to run Fuego
on a strong Linux-machine.
The Cygwin-version is significantly slower than the full-build I have on
the same machine with Fedora.
Isn't that just a matter of using a cygwin version with the same
Brian Sheppard wrote:
In this strategy, one chooses a random number p, and then select the
strategy with highest historical mean if p epsilon, and the
strategy taken least often otherwise. If epsilon = C*log(n)/n, where
n is the number of experiments so far, then the strategy has zero
Brian Sheppard wrote:
Running on your development computer, you might be limited by
clock time. Running on competition hardware, you might not be.
Only if the algorithm doesn't scale.
Which makes it uninteresting to begin with.
--
GCP
___
On Wednesday 10 June 2009 22:15:22 Ian Osgood wrote:
We have evidence against going this low: Rybka and several other
modern engines were ported to the dedicated computers Resurrection
(203 MHz StrongArm) and Revelation (500 MHz XScale). Rybka's rating
in the SSDF pool on these platforms
On Wednesday 10 June 2009 18:48:55 Martin Mueller wrote:
Currently, we try to sidestep this fundamental problem by replacing
local search with local knowledge, such as patterns. But that does not
fully use the power of search.
So, has anyone tried recursive UCT (using UCT again in the
steve uurtamo wrote:
But here is someting interesting: In the case of computer
chess it has been estimated that the progress in software
has been roughly the same as the progress in hardware.
Modern chess programs are truly amazing, and not just
a result of faster hardware. There is no
Michael Williams wrote:
Michael Williams wrote:
See the April 30 2009 posting: http://www.tobiaspreis.de/
The CUDA SDK also comes with a sample called Monte-Carlo Option Pricing
I don't think there is much more relevance to Go than it also uses
random numbers somewhere.
--
GCP
terry mcintyre wrote:
I promised an example of a monte carlo program mistakenly starting a
ladder; here it is.
I played white; Leela had a 2 stone handicap and 45 minutes on the clock.
Leela's move 32 initiates a ladder. Unfortunately for Leela, I have a
ladder breaker at D16.
Leela's
David Fotland wrote:
Yes, I walk both chains looking for duplicates. This is quite fast if done
efficiently, since group merging is rare enough. I found keeping the
liberty arrays to be slower since they are big, so there is more copy
overhead in the UCT tree, and they are not cache
Heikki Levanto wrote:
No amount on crypto-mumbo-jumbo will solve the problem that the server will
have to trust the program, and its author. Signing can provide some little
assurance that the program running today is the same as was running
yesterday, but that's about all. As long as we can
terry mcintyre wrote:
I notice that the 2008 icga chess tournament is limited to 8 cores.
David Levy's justification seems curious to me. He mentions that an
early microcomputer held its own against a mighty mainframe, and that
many top chess programs run on PCs, but he wishes to discourage
Dave Dyer wrote:
I think general hardware limits are good, because they will permit
more teams to be competitive without altering the nature of the
competition.
So in effect, it's an admission that the strength of some teams should
be crippled in a completely arbitrary way, because they
Mark Boon wrote:
Please, don't sneer.
???
I have seen a lot of discussion, but no good reasons that make sense for
the decision that was made.
What Davy Dyer said IS a good reason, and most likely the real one. But
the people in favor of the decision will not like to admit this. So it's
good
Ingo Althöfer wrote:
What prevents you from freezing in your chess
activities for the next few months and hobbying
full (free) time on computer go.
The amount of chess players compared to the amount of go players.
--
GCP
___
computer-go mailing
Rémi Coulom wrote:
Did you manage to get something to work with null move ?
When Leela runs the first simulation in a node, it plays 2 moves for the
same side, then does a playout.
If the playout loses for the not-passing side, I add x lost games to the
RAVE values.
I got maybe 10 ELO or so
Rémi Coulom wrote:
Null-move pruning only make sense in alpha-beta. MCTS/UCT are more like
min-max. They do no alpha-beta pruning, so cannot do null-move pruning.
Null move works like this: if after passing and a small search the
position still looks good, do not do a bigger search.
There is
Ian Osgood wrote:
(For that matter,
it isn't a foregone conclusion that they are better; GNU Go won the 2008
US computer go tournament against a field MC programs.)
Believe me, in match long enough to exclude pure luck, with the MC
programs running on something faster than a Pentium 4, it IS
terry mcintyre wrote:
From: Ian Osgood [EMAIL PROTECTED]
Now that Leela and Many Faces v12 are available for any Windows
user to purchase
Thanks for the heads-up, I must have missed the announcement.
Do either of these worthy programs work with Wine on Linux?
You can try the free
Ingo Althöfer wrote:
This last game is interesting because it was a win for Black.
However, so far it is not completely clear which game it is:
* Is it game 4 from
http://www.grappa.univ-lille3.fr/icga/round.php?tournament=180round=10
or is it (more likely in my eyes) from
Hideki Kato wrote:
I don't know the detail but the cluster (or the connection) had some
trouble and the play-off will be resumed this morning (at Beijing
time; +0800).
Leela has been online and ready the whole night but I still see no sign
of the Mogo team. Since it is now 9:25 Beijing time,
Ingo Althöfer wrote:
Rank 2 for MoGo after tiebreak against Leela.
Hello,
the tiebreak is not yet finished! Place 2 and 3 are still undecided.
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
Ingo Althöfer wrote:
Gian-Carlo Pascutto wrote:
I'd have some preference for playing the decisive game
with komi = 6.5, but apparently thats not possible on KGS.
But that should not be a problem, as long as the operators
do not believe in the final verdict of KGS.
But KGS will tell
Don Dailey wrote:
4. I believe Leela, at a higher level and with a correction book
would play perfect or very close to perfect on 6x6. This may
depend on seki issues however, it may not be possible for Leela
(or other Go programs) to play perfectly without some minor
David Fotland wrote:
Mogo and Many Faces played round 3 early, on
KGS. One game was scored by both programs as a win for Many Faces, but the
board has a seki, so the correct score is Mogo wins. I think the monthly
KGS tournaments would give this win to Many Faces since both programs agreed
Don Dailey wrote:
The only thing I know to check is to see if I am sending the proper komi
to the programs.The only other possible glitch is that the version
of leela I am using is ignoring the komi I send - but I don't think this
is the case.
The problem was that Leela reset the komi
Ian Osgood wrote:
I no longer see CrazyStone nor GoLois in the list of participants for
19x19. I do hope Chen Zhixing decides to enter HandTalk.
It's surprising CrazyStone is gone, as Remi's talk is still listed. What
happened? It should have been a podium candidate.
By the way, there is a
Disputes that beginners get into are another class of disputes that
these rules cannot easily resolve without the beginner feeling as if
they were being handled.You pretty much have to rely on his good
nature to eventually just accept the result without questioning it. At
some point you
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?
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
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
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
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
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
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
Á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
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).
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
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
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
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
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:
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
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:
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
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
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
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
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
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
101 - 200 of 244 matches
Mail list logo
