> 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 tha
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 endg
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 yo
> Please remember this delta is added to or subtracted from
> komi on _each_ play.
Ok, this explains it. Thanks.
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
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 sup
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 financial
> 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
>
>
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 won
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 probab
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 dimin
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 d
[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
http://www.
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 o
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" evaluati
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
ev
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 p
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 min
> 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
http://www.computer-go.org/mailman/listinfo
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 n
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 fo
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 heuris
Jeff Nowakowski wrote:
On Mon, 2008-05-12 at 21:14 +0200, Gian-Carlo Pascutto wrote:
But I still categorically object to the stance that it's the bots or the
programmers fault that it forfeits on time. As log as lag is not
compensated there is no way to avoid time losses, even if th
David Fotland wrote:
Thanks! I just registered. Who else is going?
I will be there.
--
GCP
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
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 th
A van Kessel wrote:
01010101010101010101010101010101
IMHO they are exactly the same and should be as such.
At the start of every simulation (before a 0 or 1 is reported)
, the situation is (should be) exactly the same.
So there i
Rémi Coulom wrote:
Hi,
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-compute
Edward de Grijs wrote:
GCP wrote:
> Given how well the support for Beijing is (essentially refunding the
> plane tickets, you get more for participating in Beijing than winning in
> Taiwan!), I would be really surprised if many strong programs show up
> for this. Calling the Taiwan tourname
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
computer-go@c
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 Hu
> 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).
> U
Jason House wrote:
I wouldn't want to overload volunteer operators. I can bow out to make
room for other bots.
Nah, you were here first :)
But if the sponsor machines come with Java preinstalled, "operating"
Leela wouldn't consist of more than copying the program off an USB stick
and starti
Á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 analy
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 a
> 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 eac
> 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
> It seems the professional had never played go on a computer before,
> at least not on KGS, so yes, we should probably have used longer time-
> settings, and explained that the robot would play plenty of
> unnecessary moves after filling dame.
She was also a bit "unlucky" in the sense that Leela
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
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 to
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.
Yo
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 disc
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,
including
> 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 n
> 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 archite
> 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
_
> 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 p
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
"advantag
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 th
> 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
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
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 L&D situations, but really, I expect
almost nothing to happen to the bots ratin
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 fi
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 p
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 w
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
Christoph Birk wrote:
> On Tue, 9 Sep 2008, Olivier Teytaud wrote:
>> In 19x19, it's much better, but the MPI parallelization of 9x9 Go is
>> challenging.
>
> The bright side here is that 9x9 is not really important but just
> a test bed. If it works for 19x19, that's good.
The same problems wil
> 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 poi
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
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 k
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 agre
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
>
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
http://www.computer-go.org/mailman/listin
Darren Cook wrote:
>> Congratulations!
>
> Yes, well done David. I see Many Faces won even without getting the loss
> to Mogo reversed.
There was an investigation after my complaint, and the conclusion was this:
Mogo did score the game correctly, and Many Faces did not. The server
did not go to
Ingo Althöfer wrote:
> What is done differently in Beijing?
In the players meeting the following was agreed instead:
2 games 30 minutes
if still draw
2 games 30 minutes
if still draw
toss for color, then
1 game 15 minutes
(If I remember correctly)
The idea is to avoid a medal being decide
Zach Wegner wrote:
> On Wed, Oct 1, 2008 at 10:47 AM, Ian Osgood <[EMAIL PROTECTED]> wrote:
>> Congratulations! Both for the gold, and for defeating Mogo. I never
>> thought I'd see the day that the Go tournaments would bring heavier hardware
>> than the chess championship!
>
> You realize, of c
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
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 tim
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=180&round=10
>
> or is it (more likely in my eyes) from
> http:
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 I
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 th
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
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 f
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 discour
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
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 ca
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 frien
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.
>
>
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".
--
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. Ther
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 playo
On Thursday 11 June 2009 13:16:42 Magnus Persson wrote:
> Would this be a simple way of using many cores effectively?
I don't see what it has to do with multiprocessing.
> Otherwise I cannot see how recursive UCT would be anything else than
> an ineffective implementation of UCT. Unless it provid
On Thursday 11 June 2009 14:50:14 Magnus Persson wrote:
> > Basically, you would run UCT as normal at the top level, and in the
> > playouts, use UCT with a small node limit.
>
> ...but this just cannot work it means a lot of search in order to
> update the tree once..
The results from the UCT-i
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
___
compute
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
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
1 - 100 of 277 matches
Mail list logo
