From: Don Dailey <[EMAIL PROTECTED]>
>
> It's impressive, but I'm always interested in a general purpose
> algorithm that is fast, can be used on any processor, any language
> without pain and agony.
All good things to hope for, but languages vary enough that some things must be
expressed diffe
Don wrote:
> The final step, which I don't personally support because I think it's
> too restrictive but is also possible is to require these programs to be
> deterministic.So you could SPECIFY the exact starting seed for a
> random number generator as well as the specific method (or equivalent
--- Don Dailey <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-10-09 at 15:47 -0700, Isaac Gouy wrote:
> > > Exactly. That is what I propose, not just a contest between
> > > language
> > > implementation but between language advocates. The shootout
> works
> > > that
> > > way anyway, people const
It's impressive, but I'm always interested in a general purpose
algorithm that is fast, can be used on any processor, any language
without pain and agony.
- Don
On Fri, 2008-10-10 at 07:28 +0800, Hideki Kato wrote:
> SIMD version of SFMT is 3 to 7 time faster than MT. See
> http://www.math.sc
On Thu, 2008-10-09 at 15:47 -0700, Isaac Gouy wrote:
> > Exactly. That is what I propose, not just a contest between
> > language
> > implementation but between language advocates. The shootout works
> > that
> > way anyway, people constantly tweaking their language or their
> > implementation.
SIMD version of SFMT is 3 to 7 time faster than MT. See
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/speed.html
for detail.
Hideki
Don Dailey: <[EMAIL PROTECTED]>:
>On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote:
>> Computers + random = can of worms.
>
>Has anyone seen this:
On 9-okt-08, at 17:39, Don Dailey wrote:
On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote:
Computers + random = can of worms.
What if I get a fast benchmark by implementing the fastest, most
awful, random number generator imaginable? What if every one of my
"random" playouts looks t
--- Don Dailey <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-10-09 at 13:04 -0700, Isaac Gouy wrote:
> > --- Don Dailey <[EMAIL PROTECTED]> wrote:
> >
> > -snip-
> > > I think the right way to do John's benchmark is to get each
> language
> > > zealot in competition with each other. Let the C progra
If there is a catch, it might be this:
Although the Diehard test results are a strong indication of
randomness, it remains to be proved that the cellular automaton
has a period of adequate length. Proofs regarding the period and
other characteristics of cellular au
On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote:
> Computers + random = can of worms.
Has anyone seen this:
http://home.southernct.edu/~pasqualonia1/ca/report.html#files
They are claiming impressive speed and high quality for a random number
generator. The code is compact and small
On Thu, 2008-10-09 at 14:01 -0700, terry mcintyre wrote:
> There's a huge difference ( perhaps hard for a monte carlo program to
> grok ) between "Against a skillful oponent, my group is provably dead
> no matter how I try to defend it" and "My group is alive in a
> statistical sense, since there i
> From: Weston Markham <[EMAIL PROTECTED]>
>
> In the context of Monte Carlo, a win or loss by a large margin is
> quite likely (at least in any close game) to be due to large blunders.
> (For example, allowing a large, safe group of stones to be captured.)
> Given this, it does not make sense to
On Thu, 2008-10-09 at 13:04 -0700, Isaac Gouy wrote:
> --- Don Dailey <[EMAIL PROTECTED]> wrote:
>
> -snip-
> > I think the right way to do John's benchmark is to get each language
> > zealot in competition with each other. Let the C programmer prove
> > he can do it much faster. And the Java pro
On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote:
> Computers + random = can of worms.
>
> What if I get a fast benchmark by implementing the fastest, most
> awful, random number generator imaginable? What if every one of my
> "random" playouts looks the disturbingly similar?
>
> As to
--- Don Dailey <[EMAIL PROTECTED]> wrote:
-snip-
> I think the right way to do John's benchmark is to get each language
> zealot in competition with each other. Let the C programmer prove
> he can do it much faster. And the Java programmer can respond if he
> wants to.
At which point we would h
In the context of Monte Carlo, a win or loss by a large margin is
quite likely (at least in any close game) to be due to large blunders.
(For example, allowing a large, safe group of stones to be captured.)
Given this, it does not make sense to weight it more strongly than
any other win or loss.
Computers + random = can of worms.
What if I get a fast benchmark by implementing the fastest, most awful, random
number generator imaginable? What if every one of my "random" playouts looks
the disturbingly similar?
As to the relevance, the time-eaters in my heavy playouts are different from
>> Anything can exist in a random game :-)
> Occur yes, repeat forever requires very special situations.
That makes long repeats unlikely in any individual run, and infinite
runs infinitely unlikely, unless we run into one of those very special
situations. But how special do these actually need to
On Thu, 9 Oct 2008, Denis fidaali wrote:
tCan we degrade performances more with more simulations ? :) How
does 5000AMAF fares
agains 1AMAF, i wonder. Although i'm more interested about the
upscales that the downscales :)
I tried 50k vs 10k and saw no further improvement (no degradation
eit
On Thu, 9 Oct 2008, "Ingo Althöfer" wrote:
I would like to see "all" Go programs to be able to live with
possible draws (or even with any score spectrum).
My program (myCtest) works with draws, but it's fairly weak
at about 1550 ELO (3.2 GHz P4).
Christoph
___
On Thu, 2008-10-09 at 14:44 -0400, Don Dailey wrote:
> I agree that this is far from the best way to implement a program but
> it
> would really be useful as a benchmark for board games. I would trust
> the results of this shootout way beyond the computer language
> shootout.
> This is because it'
On Thu, 2008-10-09 at 14:17 -0400, [EMAIL PROTECTED] wrote:
> >>> The http://shootout.alioth.debian.org/ site, ...
> >>>
> >>> If we, as a community, could come up with a sufficiently detailed
> >>> description of light playouts algorithm (see the current "Light
> >>> simulation : Characteristi
>>> The http://shootout.alioth.debian.org/ site, ...?
>>>?
>>> If we, as a community, could come up with a sufficiently detailed?
>>> description of light playouts algorithm (see the current "Light?
>>> simulation : Characteristic values" thread), there is no reason that?
>>> this algorithm couldn'
Zach Wegner wrote:
On Thu, Oct 9, 2008 at 5:05 AM, Darren Cook <[EMAIL PROTECTED]> wrote:
My concern is that to include all the rules of go, including capture
logic, you need a few hundred lines of code... [snip]
Don't be so sure...
;)
Or use Perl. ;)
On a more serious note, a while back I
On Thu, Oct 9, 2008 at 11:39 AM, Jason House
<[EMAIL PROTECTED]> wrote:
> On Oct 9, 2008, at 11:08 AM, "Eric Boesch" <[EMAIL PROTECTED]> wrote:
> [...]
> Does anyone allow passing at random in their playouts??? A game stopped from
> two premature passes is tough to score, if not completely meaningl
>>What about that claim that "the program could figure out the rule by itself"?
>I made experiments with no-go-knowledge. (no eye knowledge).
Any random player that accurately avoids suicide seems to need an awful lot
of Go knowledge implicitly:
- liberties (or at least pseudo-liberties, since we
On Thu, Oct 9, 2008 at 5:05 AM, Darren Cook <[EMAIL PROTECTED]> wrote:
> My concern is that to include all the rules of go, including capture
> logic, you need a few hundred lines of code... [snip]
Don't be so sure...
;)
___
computer-go mailing list
co
On Oct 9, 2008, at 5:52 AM, Don Dailey wrote:
On Thu, 2008-10-09 at 19:05 +0900, Darren Cook wrote:
The http://shootout.alioth.debian.org/ site, ...
If we, as a community, could come up with a sufficiently detailed
description of light playouts algorithm (see the current "Light
simulation : C
On Oct 9, 2008, at 11:46 AM, "Erik van der Werf" <[EMAIL PROTECTED]
> wrote:
Anything can exist in a random game :-)
Occur yes, repeat forever requires very special situations.
Sent-two-return-one may me the
biggest practical concern
This is naturally resolved in light random playouts si
On 9-okt-08, at 10:15, Don Dailey wrote:
If the play-outs are uniformly random and you have eye rule, it is
guaranteed to terminate as long as you use simple ko.
I don't think this is quite correct. With using just simple ko
there's a chance you end the game in a never-ending triple-ko. Th
Anything can exist in a random game :-) Sent-two-return-one may me the
biggest practical concern, but I would not be surprised if some day a
molasses ko would pop up as well, especially if your playouts are not
too stupid.
Erik
On Thu, Oct 9, 2008 at 5:24 PM, Jason House <[EMAIL PROTECTED]> wro
On Oct 9, 2008, at 11:08 AM, "Eric Boesch" <[EMAIL PROTECTED]> wrote:
On Thu, Oct 9, 2008 at 10:25 AM, Jason House
<[EMAIL PROTECTED]> wrote:
You are incorrect that the following heuristics in random games
lead to
finite game length:
* no eye filling
* no suicide
* no simple ko violations
Co
Which multi stone capture case still exists under random games?
Sent from my iPhone
On Oct 9, 2008, at 11:12 AM, "Erik van der Werf" <[EMAIL PROTECTED]
> wrote:
On Thu, Oct 9, 2008 at 5:03 PM, Jason House <[EMAIL PROTECTED]
> wrote:
On Oct 9, 2008, at 10:41 AM, "Erik van der Werf" <[EMAIL PR
On Thu, Oct 9, 2008 at 5:03 PM, Jason House <[EMAIL PROTECTED]> wrote:
> On Oct 9, 2008, at 10:41 AM, "Erik van der Werf" <[EMAIL PROTECTED]>
> wrote:
>> Sure, some long cycles have multi-stone captures.
>
> Can you provide an example?
http://www.cs.cmu.edu/~wjh/go/rules/bestiary.html
On Thu, Oct 9, 2008 at 10:25 AM, Jason House
<[EMAIL PROTECTED]> wrote:
> You are incorrect that the following heuristics in random games lead to
> finite game length:
> * no eye filling
> * no suicide
> * no simple ko violations
>
> Consider two eyeless chains with 3 ko's connecting them... Two ta
On Oct 9, 2008, at 10:41 AM, "Erik van der Werf" <[EMAIL PROTECTED]
> wrote:
Sure, some long cycles have multi-stone captures.
Can you provide an example? When I've thought about multi-stone
captured before, I was unable to create a scenario that lead to
infinite _random_ games. Many situ
Sure, some long cycles have multi-stone captures.
Erik
On Thu, Oct 9, 2008 at 4:39 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> You might be right. I have a liberal game length limit on my play-outs
> so I didn't notice this.
>
> Another game limiting rule could be something based on counting t
You might be right. I have a liberal game length limit on my play-outs
so I didn't notice this.
Another game limiting rule could be something based on counting the
number of consecutive 1 stone captures and terminating once this goes
beyond some reasonable limit such as 10.Would infinite gam
You are incorrect that the following heuristics in random games lead
to finite game length:
* no eye filling
* no suicide
* no simple ko violations
Consider two eyeless chains with 3 ko's connecting them... Two taken
by black and it's white's move. Filling the one ko it has is suicide.
It m
I wrote a simple Bloom filter and I tried feeding it a sequence of
random numbers (which is what Zobrist keys would look like if there
are no repetitions), to see how many false positives I would get, with
different values for k. I tried using 128 bytes, 256 bytes and 512
bytes. In every case. It l
PS : how can i do so that my response to this mailing-list will be correctly
indented ?
(for example i would have liked to set this one as a response to my previous
post).
I have made some experiments with my AMAF implementation. It is both an
attempt at understanding how the beast scales,
If you use zobrist hashing, it is probably not ridiculously slow to do
this. And if your play-outs are pretty heavy anyway, the cost will be
negligible as you say.
I remember John Stanback, the Zarkov chess programmer used to say that
he could add anything he wanted to the evaluation function b
Álvaro,
I never tried it, but I once considered doing it. It's an intriguing
idea. Since speed is all important here I would probably try just a
single probe version (bloom filter with k = 1 where k is the number of
hash functions.)
You have to clear the filter before each playout of course, b
On Thu, Oct 9, 2008 at 9:26 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
> If you use zobrist hashing, it is probably not ridiculously slow to do
> this. And if your play-outs are pretty heavy anyway, the cost will be
> negligible as you say.
Has anyone tried to use a Bloom filter (
http://en.wiki
On Thu, 2008-10-09 at 09:15 -0400, Michael Williams wrote:
> I stand corrected. Do you know if you were able to measure a strength
> increase?
I think you almost have to have either superko or some limiting device
in a program with heavy play-outs. I don't know what Magnus does, but
Lazarus wi
No, if there was a serious problem it would perhaps only happen for 1
in 1000 games. So it would be pointless trying to measure it. And some
of these problems only happens against extremely weak programs. At
least in my experience.
-Magnus
Quoting Michael Williams <[EMAIL PROTECTED]>:
I
I stand corrected. Do you know if you were able to measure a strength increase?
Magnus Persson wrote:
Valkyria does, because is superheavy anyway! A lot of weird stuff can
happen near the end of the game against programs that play randomly. I
think I implemented it because I had to to make it
Claus,
I think you have summarized things better than I am going to, but here
goes anyway:
If the play-outs are uniformly random and you have eye rule, it is
guaranteed to terminate as long as you use simple ko. It might even be
guaranteed to terminate if you don't, I don't know. Although it's
Valkyria does, because is superheavy anyway! A lot of weird stuff can
happen near the end of the game against programs that play randomly. I
think I implemented it because I had to to make it play correctly in
some positions. But it was a long time so I do not remember the details.
-Magnus
On Thu, 2008-10-09 at 19:05 +0900, Darren Cook wrote:
> > The http://shootout.alioth.debian.org/ site, ...
> >
> > If we, as a community, could come up with a sufficiently detailed
> > description of light playouts algorithm (see the current "Light
> > simulation : Characteristic values" thread),
Claus Reinke wrote:
- the only thing that guarantees termination of random playouts (with or
without dfyoe) is the positional superko rule: no whole-board repetitions
allowed. Waiting for this to kick in without taking other measures is not
an option: it takes too long and the results
I have considered the very same thing and I think it's a great idea!
In fact I implemented the same exact algorithm for a simple go program
in C and D for the exact purpose of evaluating D. I even used the same
data representation and algorithms for doing things so that it was
mostly apples to a
Hi again, with yet another question:-)
Could someone please summarize the state-of-the art wrt the various ways
of limiting random playouts, and the their consequences?
There are several variations on the "don't fill your own eyes" (dfyoe) approach,
but the way this approach is often described te
On Wed, 2008-10-08 at 22:50 -0700, David Fotland wrote:
> Integer komi has a problem for many MCTS implementations, since a playout
> only returns win or loss. This would require playouts to also return drawn.
> My playouts work this way. I know Erik's can return draw. I don’t know
> about mogo
> The http://shootout.alioth.debian.org/ site, ...
>
> If we, as a community, could come up with a sufficiently detailed
> description of light playouts algorithm (see the current "Light
> simulation : Characteristic values" thread), there is no reason that
> this algorithm couldn't join them.
Th
The topic of which programming language to use has been raised
innumerable times in the >5 years I've been on this list and I've been
backward about coming forward with an opinion because the conversation
seems to generate great deals of heat without much light.
The http://shootout.alioth.debian.o
Some of you may want to stone me for this heresy,
but read carfully before.
When you have MCST-/UCT for Go that can work for
real-valued scores (or at least a version that can
work for three-valued scores: winm, draw, loss),
you may look at Go with different scoring systems.
Example:
A win by 0.
57 matches
Mail list logo
