> In your (or Sylvain's?) recent paper, you wrote less than one second
> interval was useless. I've observed similar. I'm now evaluating the
> performance with 0.2, 0.4, 1 and 4 second intervals for 5 second per
> move setting on 19x19 board on 32 nodes of HA8000 cluster.
>
Yes, one second is fi
Olivier Teytaud: :
>> In your (or Sylvain's?) recent paper, you wrote less than one second
>> interval was useless. I've observed similar. I'm now evaluating the
>> performance with 0.2, 0.4, 1 and 4 second intervals for 5 second per
>> move setting on 19x19 board on 32 nodes of HA8000 cluster.
>
> Even if the sum-up is done in a logarithmic time (with binary tree
> style), the collecting time of all infomation from all nodes is
> proportional to the number of nodes if the master node has few
> communication ports, isn't it?
>
No (unless I misunderstood what you mean, sorry in that case!)
In message
<95be1d3b0911242338u1b6bedcasf91d53bd80f69...@mail.gmail.com>, Vlad
Dumitrescu writes
On Tue, Nov 24, 2009 at 23:58, Nick Wedd wrote:
Vlad Dumitrescu writes
Please try to explain why the "hahn calculation" isn't working in a
normal game so as to ensure a win. I'm talking about st
Hi.
I hope to have a student for the next month or two who can look into some
computer Go before starting his Masters degree. He is interested in using CUDA
for his Masters, so I thought it would be nice for him to investigate
applicability of CUDA for computer Go.
I know there was quite a deba
Steve,
I was one of the people who posted in the debate - I implemented light
playouts on CUDA for testing purposes, with one thread per playout
(rather than one per intersection).
I think one of the main things that I am curious about, and I don't
think I am the only one, is whether texture
On Wed, Nov 25, 2009 at 12:04, Nick Wedd wrote:
> A program to play Hahn Go has no
> reason to calculate probabilities, it should just make the biggest move it
> can.
Ah, okay, now I understand your point of view. Thanks for explaining.
Making the largest move available is just one possible stra
Le 25/11/2009 à 12:39, Vlad Dumitrescu a écrit :
>
> On Wed, Nov 25, 2009 at 12:04, Nick Wedd wrote:
> > A program to play Hahn Go has no
> > reason to calculate probabilities, it should just make the biggest move it
> > can.
>
> Ah, okay, now I understand your point of view. Thanks for explaini
On Wed, Nov 25, 2009 at 12:51, Alain Baeckeroot
wrote:
> Le 25/11/2009 à 12:39, Vlad Dumitrescu a écrit :
>> Making the largest move available is just one possible strategy to
>> attain the goal of ending the game with the most points scored. A more
>> general strategy is to weigh the moves' size
In message
<95be1d3b0911250448r79a5b7ddu61a42c0b42410...@mail.gmail.com>, Vlad
Dumitrescu writes
On Wed, Nov 25, 2009 at 12:51, Alain Baeckeroot
wrote:
Le 25/11/2009 à 12:39, Vlad Dumitrescu a écrit :
Making the largest move available is just one possible strategy to
attain the goal of endin
A few months ago there was a post in the computer chess forums about
optimizing combinations of features. It was called orthogonal
multi-testing.
Did I mention that on this forum already? If not, here is a brief on how
it works:
Suppose you have 1 feature you want to test - you might normal
On Wed, Nov 25, 2009 at 14:18, Nick Wedd wrote:
>>> If playing one move lead 10% of time to +10, and 90% to -20,
>>> the resulting value is -17
>>> (of course with the bot evaluation/playout)
>>
>> Reducing the value to -17 is losing a lot of information. Another move
>> might have 20% chances of
the way to do all of this exactly is with experimental design.
to design experiments correctly that handle inter-term interactions of
moderate degree, this tool is quite useful:
http://www2.research.att.com/~njas/gosset/index.html
s.
___
computer-go ma
I know there are heuristics for trying to understand the interactions and
without looking too hard I assume this package is just a more comprehensive
version of this.
On Wed, Nov 25, 2009 at 9:11 AM, steve uurtamo wrote:
> the way to do all of this exactly is with experimental design.
>
> to de
Le 25/11/2009 à 15:11, Vlad Dumitrescu a écrit :
> What I am considering is a way to analyze a list of moves, each having
> in turn a value that is a list of expected outcomes and their
> respective estimated probabilities, and to sort the moves by the
> expected outcome in the context of a given r
Olivier Teytaud: :
>> Even if the sum-up is done in a logarithmic time (with binary tree
>> style), the collecting time of all infomation from all nodes is
>> proportional to the number of nodes if the master node has few
>> communication ports, isn't it?
>>
>
>No (unless I misunderstood what you m
On Wed, Nov 25, 2009 at 15:49, Alain Baeckeroot
wrote:
>> If using a more generic approach,
>> the strategy can be parametrized and optimized (both offline and
>> online), hopefully resulting in a better gameplay.
> I don't understand how anything could be better than the expectation,
> exept if
>
>
> Interesting, surely the order is almost logarithmic. But how long it
> takes a packet to pass through a layer. I'm afraid the actual delay
> time may increase.
>
With gigabit ethernet my humble opinion is that you should have no problem.
But, testing what happens if you "artificially" canc
Robert Jasiek wrote:
>>
Types of Basic Kos
http://home.snafu.de/jasiek/ko_types.pdf
<<
Version 6 is available.
--
robert jasiek
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Wed, Nov 25, 2009 at 09:01:22AM -0500, Don Dailey wrote:
> You could of course just play games where you choose each player randomly.
> If you have 256 feature you have a ridiculous number of combinations, more
> than you could possibly test but before each test game you just pick a
> combinatio
On Wed, Nov 25, 2009 at 10:44 AM, Heikki Levanto wrote:
> On Wed, Nov 25, 2009 at 09:01:22AM -0500, Don Dailey wrote:
> > You could of course just play games where you choose each player
> randomly.
> > If you have 256 feature you have a ridiculous number of combinations,
> more
> > than you coul
Has anyone read this book?
http://www.amazon.com/gp/aw/d.html/ref=redir_mdp_mobile/176-9930046-0953944?a=1568810326
What do you think of the contents?
--Aldric
'What is the nature of conflict?'
Sent via BlackBerry by AT&T
___
computer-go mailing list
com
In message
<461903611-1259167977-cardhu_decombobulator_blackberry.rim.net-816036941-
@bda761.bisx.prod.on.blackberry>, Aldric Giacomoni
writes
Has anyone read this book?
http://www.amazon.com/gp/aw/d.html/ref=redir_mdp_mobile/176-9930046-0953
944?a=1568810326
What do you think of the contents?
I read it many years ago. At the time I had never heard of
combinatorial game theory, and it's a bit hard to grasp the theory by
reading this book. Perhaps you should read "Winning Ways" first:
http://www.amazon.com/gp/aw/d.html/?a=1568811306
The whole theory is fascinating, but in the case of go
Aldric Giacomoni wrote:
What do you think of the contents?
The mathematical part is very good and even more mathematical. I.e.,
useful for fans of theory of applied mathematics to go and who want to
read something of the caliber of an "introduction" into linear algebra
as you might find in y
On Wed, Nov 25, 2009 at 11:13 AM, Álvaro Begué wrote:
[... Read "Winning Ways" first...]
> On Wed, Nov 25, 2009 at 11:53 AM, Aldric Giacomoni wrote:
>> Has anyone read this book?
>> http://www.amazon.com/gp/aw/d.html/ref=redir_mdp_mobile/176-9930046-0953944?a=1568810326
>>
>> What do you think o
Berlekamp came to MIT and gave a talk for us, and after that we talked
about Go and Chess and other things and took him out to eat.
I can vouch for the fact that he is a truly humble and modest person and is
a real joy to talk to. It was all thoroughly enjoyable.
- Don
On Wed, Nov 25, 2009 a
steve uurtamo wrote:
> the way to do all of this exactly is with experimental design.
>
> to design experiments correctly that handle inter-term interactions of
> moderate degree, this tool is quite useful:
>
> http://www2.research.att.com/~njas/gosset/index.html
That doesn't seem to directly supp
On Wed, Nov 25, 2009 at 2:00 PM, Matthew Woodcraft
wrote:
> steve uurtamo wrote:
> > the way to do all of this exactly is with experimental design.
> >
> > to design experiments correctly that handle inter-term interactions of
> > moderate degree, this tool is quite useful:
> >
> > http://www2.res
I would enter a bot in a KGS Hahn tournament, of Nick's type (2) if it were
held. (If KGS permits round-robin scheduling, I think that would be preferable,
but not essential.) I think it would be a lot of fun. Which is not to suggest
that the regular KGS tournaments need changing.
The early MC
Don Dailey wrote:
> Matthew Woodcraft wrote:
>> That doesn't seem to directly support deriving information from
>> random trials. For computer go tuning, would you play multiple games
>> with each parameter set in order to get a meaningful figure? That
>> seems likely to be less efficient than tre
On Wed, Nov 25, 2009 at 5:01 PM, Matthew Woodcraft
wrote:
> Don Dailey wrote:
> > Matthew Woodcraft wrote:
>
> >> That doesn't seem to directly support deriving information from
> >> random trials. For computer go tuning, would you play multiple games
> >> with each parameter set in order to get a
>> This is taken onto account in the tree.
>> If playing one move lead 10% of time to +10, and 90% to -20,
>> the resulting value is -17
>> (of course with the bot evaluation/playout)
>
> Reducing the value to -17 is losing a lot of information. Another move
> might have 20% chances of +10 and 80%
33 matches
Mail list logo
