>This was typically to pick up my queen, change its colour, and
>> capture my rook with it.
>
>Now there's a feature that would make a tournament interesting...
If this appeals to you, try Martian Chess or Shogi
___
computer-go mailing list
computer-go
On Thu, Aug 14, 2008 at 5:05 AM, Nick Wedd <[EMAIL PROTECTED]> wrote:
>
> When I first came across microcomputers, in 1981, there was a chess program
> that ran on them. It played so badly that even I could beat it; so I looked
> for other challenges, such as to stalemate it. I was surprised by i
Hi Darren,
Darren Cook: <[EMAIL PROTECTED]>:
>Hideki Kato wrote:
>> queue overflows. So, the searcher selects optimal arcs based on the
>> older results of simulations by "delay" times. Especially at
>
>Hi Hideki,
>You have used the word "arc" a few times, and it seems to mean move, but
>I wonde
Hideki Kato wrote:
> queue overflows. So, the searcher selects optimal arcs based on the
> older results of simulations by "delay" times. Especially at
Hi Hideki,
You have used the word "arc" a few times, and it seems to mean move, but
I wondered if there was some nuance intended. (E.g. maybe an
On Thu, Aug 14, 2008 at 12:00 AM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:
> 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
On Wed, Aug 13, 2008 at 5:00 PM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:
> The problem is that the optimal settings for UCT appear to be much stronger
> on the exploitation side than on the exploration side, making it much more
> likely that such work is really wasted.
I'm not sure it's tha
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
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?
From: Jason House <[EMAIL PROTECTED]>
> If this is aimed at clearing up ambiguity, you should state which way the
> handicap was given.
Oops! Now I need to clean off my keyboard!
Mmmm, we already have a hotly-contested estimate that computer programs will
play pros on an even basis in ten yea
If this is aimed at clearing up ambiguity, you should state which way
the handicap was given.
Sent from my iPhone
On Aug 13, 2008, at 2:08 PM, "Chaslot G (MICC)" <[EMAIL PROTECTED]
> wrote:
Dear all,
There were details that were unclear about the victory of MoGo.
Hence I created a website
Dear all,
There were details that were unclear about the victory of MoGo.
Hence I created a website to gather useful information about this game:
http://www.cs.unimaas.nl/g.chaslot/muyungwan-mogo/
Cheers,
Guillaume
Message d'origine
De: [EMAIL PROTECTED] de la part de Sylvai
C++ on linux (with a port on windows using cygwin libraries for the binary
release)
Sylvain
2008/8/13 steve uurtamo <[EMAIL PROTECTED]>
> > 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 i
Magnus Persson: <[EMAIL PROTECTED]>:
>Quoting Hideki Kato <[EMAIL PROTECTED]>:
>
>> Yes, UCT does. From my recent experiments with a delay
>> line (a fixed size FIFO queue) between a UCTsearcher and an MC
>> simulator with RAVE against GNU Go 3.7.11 level 0 on 9x9 (single
>> thread):
>>
>> delay
For the European Go Congress computer Go tournaments, I required
programs to be actually present. This was a debatable decision, but is
not what I propose to discuss now. I did allow people to send in their
programs; I think this was a mistake, and the purpose of this email is
to explain why
steve uurtamo: <[EMAIL PROTECTED]>:
>this is interesting!
>
>perhaps i misunderstand the setup of the experiment -- what
>is the unit of measure for the delay, or how is delay being
>implemented?
>the FIFO queue is doing what, and where is the delay
>being introduced?
The UCT searcher pushes a po
Quoting Hideki Kato <[EMAIL PROTECTED]>:
Yes, UCT does. From my recent experiments with a delay
line (a fixed size FIFO queue) between a UCTsearcher and an MC
simulator with RAVE against GNU Go 3.7.11 level 0 on 9x9 (single
thread):
delay #po winsgames winning rateELO 1 sig
I thought Mogo was written in RPG?
- Don
On Wed, 2008-08-13 at 09:19 -0700, 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 para
this is interesting!
perhaps i misunderstand the setup of the experiment -- what
is the unit of measure for the delay, or how is delay being
implemented?
the FIFO queue is doing what, and where is the delay
being introduced?
thanks,
s.
On Wed, Aug 13, 2008 at 9:20 AM, Hideki Kato <[EMAIL PROTE
Magnus Persson: <[EMAIL PROTECTED]>:
>Quoting Don Dailey <[EMAIL PROTECTED]>:
>
>> Yes, UCT is easier to use with multiple CPU's because with additional
>> processors alpha-beta programs do wasted work, unless you are talking
>> about theoretical programs with perfect move ordering, which you aren'
> 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?
s.
From: Don Dailey <[EMAIL PROTECTED]>
On Wed, 2008-08-13 at 14:38 +0200, Magnus Persson wrote:
>> Here is my take on joseki and fuseki in computer programs.
>> My older program Viking, had a quite nice patternmatching feature
>> which matched the entire board or smaller parts of it towards a
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 out
I don't know the answer, but it wouldn't surprise me if it turned out
that the same theoretical issues exist for most reasonable tree search
schemes. So it is possible that UCT has no superiority over alpha-beta
when it comes to making a parallel program. But I don't really know.
- Don.
On We
Quoting Don Dailey <[EMAIL PROTECTED]>:
Yes, UCT is easier to use with multiple CPU's because with additional
processors alpha-beta programs do wasted work, unless you are talking
about theoretical programs with perfect move ordering, which you aren't.
Nice that all is clear about alpha-beta p
On Wed, 2008-08-13 at 14:38 +0200, Magnus Persson wrote:
> Here is my take on joseki and fuseki in computer programs.
>
> My older program Viking, had a quite nice patternmatching feature
> which matched the entire board or smaller parts of it towards a
> database of 50k games or so. It makes
I want to correct my statement in view of a private discussion with
Gian-Carlo. It turns out that in theory, with a perfectly ordered
search tree, Gian-Carlo is correct that a parallel alpha beta searcher
would search the same number of nodes as a serial searcher.
It's not what David Fotlan
Here is my take on joseki and fuseki in computer programs.
My older program Viking, had a quite nice patternmatching feature
which matched the entire board or smaller parts of it towards a
database of 50k games or so. It makes it play nice but as far as I
could tell it had no impact on the
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 evidence
28 matches
Mail list logo
