Thanks for the input. It is a very interesting idea. Since I don't have a
transposition table but only a stupid tree, I can't apply the same mechanic.
I can image that with a transposition table, nodes are very equally distri-
buted, so pruning one of the 16 moves almost always is a good choice.
B
>Why do you keep nodes from previous searches?
All of the descendants of the move you choose are relevant to
future searches. Plus whatever nodes can be reached by transposition.
(In Go, there are a lot of transpositions.)
>By search, do you mean a "genmove"?
Move generation and pondering.
>
> Pebbles prunes least recently used nodes. This eliminates nodes
> from previous searches first, and then nodes from the current search.
Why do you keep nodes from previous searches? By search, do you mean a
"genmove"? How do you store which nodes are oldest (queue, heap)?
--
GRATIS für alle GM
Pebbles prunes least recently used nodes. This eliminates nodes
from previous searches first, and then nodes from the current search.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Nice to hear that :)
2009/6/5 Michael Williams :
> Łukasz Lew wrote:
>>
>> On Wed, Jun 3, 2009 at 00:56, Michael Williams
>> wrote:
>>>
>>> Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate
>>> and InvSqrtVisits and keeping them updated.
>>> So my UCT formula went from
>>>
Łukasz Lew wrote:
On Wed, Jun 3, 2009 at 00:56, Michael Williams
wrote:
Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate
and InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits / Visits)
to
WinRate + s
Jason House wrote:
On Jun 2, 2009, at 6:56 PM, Michael Williams
wrote:
Two things: Firstly, I'm storing (only in RAM) the precalculated
Winrate and InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits / Visits)
to
WinRate + sqrtLnP
On Jun 2, 2009, at 6:56 PM, Michael Williams > wrote:
Two things: Firstly, I'm storing (only in RAM) the precalculated
Winrate and InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits / Visits)
to
WinRate + sqrtLnParentVisits * InvSq
On Wed, Jun 3, 2009 at 00:56, Michael Williams
wrote:
> Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate
> and InvSqrtVisits and keeping them updated.
> So my UCT formula went from
>
> Wins / Visits + sqrt(lnParentVisits / Visits)
>
> to
>
> WinRate + sqrtLnP
Two things: Firstly, I'm storing (only in RAM) the precalculated Winrate and
InvSqrtVisits and keeping them updated.
So my UCT formula went from
Wins / Visits + sqrt(lnParentVisits / Visits)
to
WinRate + sqrtLnParentVisits * InvSqrtVisits;
This has a memory cost, but I don't
That sounds like a good optimization. What did you do?
Sent from my iPhone
On Jun 2, 2009, at 3:16 PM, Michael Williams > wrote:
Update: After concentrating on tightening the UCT loop, I've
optimized myself back into needing the SDD :/
But now I should be able to get to 20B nodes in just
I mean "SSD".
Michael Williams wrote:
Update: After concentrating on tightening the UCT loop, I've optimized
myself back into needing the SDD :/
But now I should be able to get to 20B nodes in just one day.
(still only doing 7x7 Go)
Michael Williams wrote:
Yes, when memory is full, I save
Update: After concentrating on tightening the UCT loop, I've optimized myself
back into needing the SDD :/
But now I should be able to get to 20B nodes in just one day.
(still only doing 7x7 Go)
Michael Williams wrote:
Yes, when memory is full, I save and free all leaf nodes (which is the
Yes, when memory is full, I save and free all leaf nodes (which is the vast
majority). Nodes are loaded as needed.
Don Dailey wrote:
On Mon, Jun 1, 2009 at 4:57 PM, Michael Williams
mailto:michaelwilliam...@gmail.com>> wrote:
I've optimized my disk access to the point where I'm mostly
On Mon, Jun 1, 2009 at 4:57 PM, Michael Williams <
michaelwilliam...@gmail.com> wrote:
> I've optimized my disk access to the point where I'm mostly CPU limited
> now, even when using a standard hard disk instead of an SSD. I can now
> create trees of up to about 30 billion nodes, which would tak
I've optimized my disk access to the point where I'm mostly CPU limited now, even when using a standard hard disk instead of an SSD. I can now create trees of
up to about 30 billion nodes, which would take about a week. The simulation rate is continuously going down because so much time is spent
mputer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of Isaac Deutsch
> Sent: Monday, June 01, 2009 9:23 AM
> To: computer-go
> Subject: Re: [computer-go] UCT tree pruning
>
>
> > But is it better? I think it's not so obvious without thorough
testing.
c Deutsch
> Sent: Monday, June 01, 2009 1:55 AM
> To: computer-go
> Subject: [computer-go] UCT tree pruning
>
> Hi.
>
> I've been thinking about pondering, and the way the tree has to be built
to
> support pondering. Because with pondering, the thinking time for a move
ca
> But is it better? I think it's not so obvious without thorough testing.
> - Don
OK. It seems difficult to find a good rule to prune moves/nodes.
I just had an additional idea. You could make the treshold for expanding a
node a function of the tree size AND the depth the node is at in the t
On Mon, Jun 1, 2009 at 11:22 AM, Isaac Deutsch wrote:
>
> > Well, I'll take that over crashing with an out-of-memory error. :)
>
> Still, pruning seems better to me and has the same effect. ;p
But is it better? I think it's not so obvious without thorough testing.
Pruning throw away informat
Valkyria simply do not expand the tree when it runs out of unused nodes.
That would be the most simple thing to prevent crashing.
Then one could consider pruning the tree in order to be able to expand
the tree even deeper.
-Magnus
Quoting Isaac Deutsch :
Well, I'll take that over crashin
> Well, I'll take that over crashing with an out-of-memory error. :)
Still, pruning seems better to me and has the same effect. ;p
--
Nur bis 31.05.: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und
Telefonanschluss nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
On Mon, Jun 1, 2009 at 10:10 AM, Isaac Deutsch wrote:
>
>> No. We use a threshold that is a function of how large the tree
>> already is. It starts at 5 and then we increase it as the tree grows
>> larger. I think the exact formula scaled with something like the
>> log(tree_size)^2, but I would ha
> No. We use a threshold that is a function of how large the tree
> already is. It starts at 5 and then we increase it as the tree grows
> larger. I think the exact formula scaled with something like the
> log(tree_size)^2, but I would have to check when I get home.
>
> Álvaro.
Ah, now I underst
On Mon, Jun 1, 2009 at 9:38 AM, Isaac Deutsch wrote:
>
>
>> In dimwit we simply increase the number of visits to a node before it
>> is added to the UCT tree, to slow down its growth. I wasn't too happy
>> about how selective the tree got with a long time to think, but it's
>> unclear if this part
> In dimwit we simply increase the number of visits to a node before it
> is added to the UCT tree, to slow down its growth. I wasn't too happy
> about how selective the tree got with a long time to think, but it's
> unclear if this particular hack had anything to do with that.
>
> Álvaro.
I al
In dimwit we simply increase the number of visits to a node before it
is added to the UCT tree, to slow down its growth. I wasn't too happy
about how selective the tree got with a long time to think, but it's
unclear if this particular hack had anything to do with that.
Álvaro.
On Mon, Jun 1, 20
Hi.
I've been thinking about pondering, and the way the tree has to be built to
support pondering. Because with pondering, the thinking time for a move can
be very big theoretically, I would like to handle automatic pruning of the
tree to avoid running out of memory. Right now I have a fixed size
no. just don't prune the tree. or allow unpruning.
compgo...@aol.com wrote:
Following is a description of the nature and process of the UCT-MC method.
For a given Go board position P, let Np denote the total number of all
possble end of game positions. Let Ei denote each of the end of game
Following is a description of the nature and process of the UCT-MC method.
For a given Go board position P, let Np denote the total number of all possble
end of game positions. Let Ei denote each of the end of game position
(i=1,...,Np).
Let Mip denote all possible move sequences that starts f
Hi,
While recently implementing UCT, I've come across two cases where one may want
to increase the number of visits to a node by something greater than 1.
A) Leaf nodes - Artifically set the number of visits to some very high number.
The rationale for this is to accelerate propagation of the
"Just the opposite. The noise in the win rate is 1/sqrt(n). The reason for
doing few simulations is
that they're relatively expensive. UCT and MCTS do extra tree walking because
that's less expensive
than over simulating bad moves. "
- thanks jason, thats unequivocal
Beyond Hotmail - see wh
On Jan 26, 2009, at 6:26 PM, matt harman
wrote:
> That the missunderstanding right there.
> 1 child will be chosen and 1 simlation will be run.
Thanks for the quick answer, so 1 simulation is run because too many
will give lots of noise to the result?
Just the opposite. The noise in the w
On Mon, 26 Jan 2009, matt harman wrote:
Thanks for the quick answer, so 1 simulation is run because too many
will give lots of noise to the result? if only 1 is run then the 4 children can
either win or lose
the single simulation 0 or 1. This would be non-deterministic so how would you
decide wh
> That the missunderstanding right there.
> 1 child will be chosen and 1 simlation will be run.
Thanks for the quick answer, so 1 simulation is run because too many
will give lots of noise to the result? if only 1 is run then the 4 children can
either win or lose
the single simulation 0 or 1. T
On Mon, 26 Jan 2009, matt harman wrote:
With an empty board, assuming I am using proximity heuristic of 1 Manhattan
distance,
from the root I will have 4 possible positions which will make up 4 children of
the root.
Each child will be simulated (eg) 1000 times and a winrate is calcuated.
If ch
Hi,
After reading the pseudo code of UCT for valkyria (sept 2006)
and a paper by Sylvain gelly i was hoping someone could clear up a
few concepts. (Another newbie post im afraid) I have searched the
archives but havent found a clear answer.
Allow me to present an useless example:
With an empty
I have done a bit more testing and some things start to become a
little more clear to me. But I still have some open questions.
What I did was to rewrite my search such that I can set a constant
that determines after how many simulations the tree gets expanded.
And I have a switch to turn A
Quoting Mark Boon <[EMAIL PROTECTED]>:
OK, things start to fall in place for me. I was wondering all this time
what would happen with the information of the simulations that happen
before expansion. So the answer is: nothing. But at least the result of
the playout gets percolated up the tree, s
On 20-nov-08, at 15:20, Magnus Persson wrote:
Quoting Mark Boon <[EMAIL PROTECTED]>:
What is not exactly clear to me is what you mean by 'postponing
expansion'. Let me write it in my own words to see if that's what you
mean. When you have selected a best node based on the UCT + wins/
visits
Quoting Mark Boon <[EMAIL PROTECTED]>:
What is not exactly clear to me is what you mean by 'postponing
expansion'. Let me write it in my own words to see if that's what you
mean. When you have selected a best node based on the UCT + wins/visits
value which has no children yet, you first simply do
On 20-nov-08, at 14:51, Magnus Persson wrote:
and had to add a lot of kludges to avoid problems with older
kludges and so on...
Hey, that sounds strangely familiar :)
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.o
On 20-nov-08, at 14:42, Magnus Persson wrote:
I think you understand the basic principle of RAVE correctly. The
hard part is how to weight together the AMAF value (which I call
*virtual win-visit* ratio) with the actual win-visit ratio. And I
have to admit that my implementation of RAVE i
About allowing early passes.
I think my problem is that RAVE/AMAF really say nothing about the
value of pass moves, which makes it problematic when selective search
do not search bad moves such as pass. So how are we supposed to know
when to search pass and not?
Thus, everytime I had some
On 20-nov-08, at 14:03, Michael Williams wrote:
You could simply allow the pass all the time. Early in the game,
it will be a significantly inferior move and not often explored
in the tree. That may not be optimal, but it's certainly not
convoluted and you are guaranteed to never fail to
Quoting Mark Boon <[EMAIL PROTECTED]>:
Thanks for the comments Magnus.
On 20-nov-08, at 13:00, Magnus Persson wrote:
The way I understood the article, after a playout it updates all the
nodes at the current level of all the moves played during the playout
(if it's a win for the player) with a
On 20-nov-08, at 14:03, Michael Williams wrote:
You could simply allow the pass all the time. Early in the game,
it will be a significantly inferior move and not often explored
in the tree. That may not be optimal, but it's certainly not
convoluted and you are guaranteed to never fail to
You could simply allow the pass all the time. Early in the game, it
will be a significantly inferior move and not often explored in the
tree. That may not be optimal, but it's certainly not convoluted and
you are guaranteed to never fail to generate the pass move when you
needed it.
I rem
On 20-nov-08, at 13:22, Michael Williams wrote:
Mark Boon wrote:
The treatment of pass feels a bit convoluted. The idea behind it
is that I don't want to allow pass-moves in the tree early in the
game. But towards the very end of the game I want to allow pass to
avoid being forced to make
Thanks for the comments Magnus.
On 20-nov-08, at 13:00, Magnus Persson wrote:
I'd also like to hear opinions on what would be a good N for a
reference bot. If I set N to 2,000, just like the reference-bots on
CGOS, it plays rather poorly. Much worse than the ref-bot. I haven't
tested it a lot
Mark Boon wrote:
The treatment of pass feels a bit convoluted. The idea behind it is that
I don't want to allow pass-moves in the tree early in the game. But
towards the very end of the game I want to allow pass to avoid being
forced to make a bad move or not being able to make a move at all.
I could find anything problematic with your specification so I just
make some comments.
Quoting Mark Boon <[EMAIL PROTECTED]>:
- When it reaches N simulations, the child of the root-node with the
best wins-visits ratio is played. I've also seen that simply the child
with the highest number of
After getting some strange results with my experiments I realised
that doing these tests on the reference-bot is probably not
appropriate. The MC+AMAF combination is a completely different beast
than MC+UCT-search.
So I need to do the testing on a reference implementation for MC+UCT-
searc
Wow, just wow. What an amazing video. It's so organic in the way that
it grows. The way it rotates around, and how transpositions pull and
stretch the tree around, and the way that deleted nodes "explode"
away... just awesome.
Also, thanks for turning me on to this General Game Playing stuff.
Soun
I don't understand this, but it's fascinating.
http://www.hvergi.net/2008/06/visualizing-gameplaying-algorithms/
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
David Fotland wrote:
Since you hijacked my thread, I'm changing the title and injecting some data
:)
I tried to be very clear that I didn't want that thread to become another
scalability flame fest.
Here is a high level mogo game, level 15 vs level 16, that hinges on a life
and death problem th
Since you hijacked my thread, I'm changing the title and injecting some data
:)
I tried to be very clear that I didn't want that thread to become another
scalability flame fest.
Here is a high level mogo game, level 15 vs level 16, that hinges on a life
and death problem that mogo gets wrong over
From discussion, it seems that there are two important tests of
unbiasedness that we can make for an improvement to playouts:
1: For any position, we should equally study what happens when either
black or white moves there. This is captured in the proverb "your
opponent's good move is your good
Brian Slesinsky wrote:
And this would mean that a position where black is in trouble
would look stronger than in a random playout (due to black
playing well only for this kind of situation) which would make
it harder to tell which positions are actually good.
Or in general, an improvement i
On 7/11/07, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
I will try to explain it better: E.g. The game is in a position where black
is in danger. That position is the root node. All stones in the root node
are inherited in any node below, except when they are captured. Your trick
pretends to fav
Brian Slesinsky wrote :
> When you favor defense (or attack) you may think: "This is unbiased
> since some times it favors black and other times it favors white" But
> the fact is when black is in danger at the root of the tree, it is in
> danger in most of the tree, therefore the trick gets the
On Tue, 2007-07-10 at 10:04 -0700, Brian Slesinsky wrote:
> On 7/10/07, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
>
> > When you favor defense (or attack) you may think: "This is unbiased
> > since some times it favors black and other times it favors white" But
> > the fact is when black is in d
On 7/10/07, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
When you favor defense (or attack) you may think: "This is unbiased
since some times it favors black and other times it favors white" But
the fact is when black is in danger at the root of the tree, it is in
danger in most of the tree, ther
>. And wrong after a long random playout means _very wrong_.
Oh! nice phrase!
It made me laughing 15 seconds,
Thanks.^^
igo
---
Jacques Basald\xE5 蜚 海\xE1 \xE1 碎棱粤鬧 鼈阨趙 矼 迴鱚
\xBE 冗逅闥懲銓 抅瘤 蜊頏阮蜴\xE7 抅\xE5 痰蛹蜚\xF9 捃 肅鈔 瘤 癆懲站\xAE 膚 抅纈\xE5 癇\xE5
\
Brian Slesinsky wrote:
Since the players in the playouts are so weak, it seems like the
improving the ability to defend a strong position from a
not-very-clever move (and not lose it via a blunder) should be more
important than improving the ability to find an attack. If there are
two equally b
In case anyone else was interested, yes, the AAAI general game-playing
competition has just started. You can find instructions to join the mailing
list on the "resources" page at the site (games.stanford.edu) and evidently
the games from the competition are being broadcast "live" online. If it's
Darren Cook wrote:
Does anyone know of UCT being used in games other than go, or outside
games altogether, such as travelling salesman problem, or some
business-related scheduling/optimizing/searching problem domain?
I have used it in a connect4 engine.
http://www.roland-illig.de/viergewinnt.h
On 04/06/07, Darren Cook <[EMAIL PROTECTED]> wrote:
Does anyone know of UCT being used in games other than go, or outside
games altogether, such as travelling salesman problem, or some
business-related scheduling/optimizing/searching problem domain?
I am trying to use UCT for the game trax. I
0279B
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren Cook
Sent: Monday, 4 June 2007 8:14 AM
To: computer-go
Subject: [computer-go] UCT outside of go?
Does anyone know of UCT being used in games other than go, or outside
games altogether, such as trave
I don't have specific information, but I worked on GGP with that group for
the last two years, and I think I can probably get in touch with them. I'll
see what they're up to and get back to you.
-Nick
On 6/3/07, Peter Drake <[EMAIL PROTECTED]> wrote:
I don't know, but I'd like to try it on the
Darren Cook wrote:
Does anyone know of UCT being used in games other than go, or outside
games altogether, such as travelling salesman problem, or some
business-related scheduling/optimizing/searching problem domain?
Thanks,
Darren
Guillaume has one paper titled "Monte-Carlo Tree Search in
My company is building a specialized web crawler that shares some things
in common with UCT. I can't go into specifics but the basic goal is to
focus a web crawl along a deliberate path of links that optimizes the
probability of finding certain types of content. It has more in common
with Go prog
I don't know, but I'd like to try it on the AAAI's general game-
playing competition. Does anyone know if it's still running? The only
site I could find gives a past date as Real Soon Now:
http://games.stanford.edu/competition.html
I didn't get any reply from the address listed. Does anyone e
Does anyone know of UCT being used in games other than go, or outside
games altogether, such as travelling salesman problem, or some
business-related scheduling/optimizing/searching problem domain?
Thanks,
Darren
--
Darren Cook
http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dicti
I found the detailed results page tough to read. Here's a quick key on
how to read it. Maybe it's overkill.
For those trying to read the results... Taking the last line from test 1,
"explore_rate = 1 - ego_base wins 62.7 + 3.8 % games (158 ames)"
The first part "explore_rate = 1 - ego_base" is
My student - Filip Gruszczynski, made extensive testing of alternative
formulas for UCT.
Over 30 000 games; ~10 different algorithms with various constants
(including BAST).
http://students.mimuw.edu.pl/~fg219435/Go/
From the article:
"It seems, that the more simple approach we take, the bette
I just realized that the UCT describes perfectly the case of trading stocks.
AOL now offers free email to everyone. Find out more about what's free from
AOL at AOL.com.
___
co
UCT-MC performed better on CGOS is also due to the fact that the depth of the
game and the branch factor is much larger.
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Mon, 19 Mar 2007 9:00 AM
Subject: [computer-go] UCT performance
I'm readin
I'm reading the paper by Kocsis and Szepesvari. From Figure 2 the significant
imporvement of UCT over alpha-beta happens when the error tolerance is about
10%, where the improvement is a factor of 100. From the results of CGOS UCT-MC
performed seemly better than this. It's propabaly due to the r
UCT, alpha-beta, Monte-Carlo, and many others (not related to game playing) are
all methods of optimization. In college we all did it countless times to find
the maximum or minimum of a function. It's the simplest form of optimization.
In an optimization two things are usually required: the accu
Thanks to someone pointing out the info source for UCT method. I did some
reading.
UCT is a width first search algorithm. Some of the MoGo's plays are not bad.
Especially its cohesion and emphasizing the center are good, which are the
common weaknesses of most Go programs.
To my understandin
I would like to mention that Mogo with 10K play-outs on CGOS
is rated slightly higher than Lazarus ( 2100 vs 2130 ) so
the quality of the play-outs, not speed, is what I'm currently
focused on improving. Lazarus is doing roughly 10 - 20 X
more play-outs per move than Mogo 10K and still rated s
Hi John,
The impressive numbers reported by Lukasz Lew is based on designing
the fastest possible randomly distributed play-out you can manage.
But when using "heavy" play-outs, things become more complicated
because the play-outs become far more expensive. Lazarus does
some of the sames things
Many people here have reported on their MC playout speed,
with numbers approaching a most impressive 100K playouts/sec.
I would like to know what impact adding UCT has on this speed.
In the playout you need only spend a small constant amount of
work per move, but choosing a single child node in UC
Some of the initial confusion I personally have about MC and UCT
stemmed from the fact that I did not see the separation between the
tree search and the leaf evaluation. UCT provides direction for the
tree search and MC provides an increasingly accurate evaluation of the
leaves. Because of that
Hi,
I just made a page for the general UCT algorithm in Wikipedia. If you
know more about UCT than I do, please improve this stub article.
Thanks,
Peter
http://en.wikipedia.org/wiki/Upper_Confidence_Bounds_Applied_to_Trees_%28UCT%29
___
computer-go m
> What do you mean? You mean you can't access the page, or the content is
> not informative, non relevant, not interesting?
This is the text:
(...)
>> find out more
But, when I click on the "find out more" link, it takes me to <
http://cgos.boardspace.net/> !!
Surely that is not what you inte
Sylvain Gelly wrote:
Thank you all for your precise answers!
Sylvain
p.s. the "find out more" link at the bottom of your page
http://www.inria.fr/futurs/ressources-1/computer-culture/mogo-champion-program-for-go-games
is pointing to the wrong place, isn't it?
What do you mean?
imulations of the node is "< threshold" rather than ending
on a unseen node.
Sylvain
-Original Message-
From: Don Dailey <[EMAIL PROTECTED]>
To: Dmitry Kamenetsky <[EMAIL PROTECTED]>, computer-go
Date: Wed, 21 Feb 2007 12:54:43 -0500
Subject: Re: Re[2]: [computer
?
-Original Message-
From: Don Dailey <[EMAIL PROTECTED]>
To: Dmitry Kamenetsky <[EMAIL PROTECTED]>, computer-go
Date: Wed, 21 Feb 2007 12:54:43 -0500
Subject: Re: Re[2]: [computer-go] UCT vs MC
>
> On Wed, 2007-02-21 at 16:56 +0300, Dmitry Kamenetsky wrote:
> > Thank you for
Thank you all for your precise answers!
Sylvain
p.s. the "find out more" link at the bottom of your page
http://www.inria.fr/futurs/ressources-1/computer-culture/mogo-champion-program-for-go-games
is pointing to the wrong place, isn't it?
What do you mean? You mean you can't access the pag
There is also the expression, "He isn't playing with all his marbles!"
I don't think the author did this by accident, instead I think he liked
the sound of it. It's common for writers to take liberties like this to
jazz up an article.
- Don
On Wed, 2007-02-21 at 14:01 -0800, Thomas Johnson wr
Sylvain Gelly wrote:
my favorite line:
"In Go all marbles are identical..."
My English prevent me to understand the subtlety here.
Is there any relation to "the type of stone" meaning of marble?
No, not really.
Here the meaning of "marbles" is that of children's toys, small
spheric
It's funny to English-speakers because when we think of marbles, we're
thinking of something like this
http://www.atoygarden.com/images/products/Marbles300.jpg
Some games are played with marbles, but since in English the go pieces are
called "stones" the concept of playing Go with marbles evokes
Marbles are always spherical. Playing Go with marbles is comical.
On 2/21/07, Sylvain Gelly <[EMAIL PROTECTED]> wrote:
> my favorite line:
>
> "In Go all marbles are identical..."
>
My English prevent me to understand the subtlety here.
Is there any relation to "the type of stone" meaning of
my favorite line:
"In Go all marbles are identical..."
My English prevent me to understand the subtlety here.
Is there any relation to "the type of stone" meaning of marble?
Sylvain
___
computer-go mailing list
computer-go@computer-go.org
http://www
my favorite line:
"In Go all marbles are identical..."
s.
- Original Message
From: David Doshay <[EMAIL PROTECTED]>
To: computer-go ; Chris Garlock <[EMAIL
PROTECTED]>; Charlie Mc Dowell <[EMAIL PROTECTED]>
Sent: Wednesday, February 21, 2007 3:45:19 P
This is much better than the article in zdnet.com.
They shortened the quote to be, "We are not far
from reaching the level of a professional Go player".
At least Yahoo didn't butcher the quote and give
an entirely incorrect impression.
http://news.zdnet.com/2100-3513_22-6161042.html
--- David Dos
A gross simplification, but most news articles are ...
http://news.yahoo.com/s/nm/20070221/tc_nm/science_go_dc_2
Cheers,
David
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Wed, 2007-02-21 at 16:56 +0300, Dmitry Kamenetsky wrote:
> Thank you for your answer. However, I am even more confused now. I
> understand that "-" is for negamax, but I don't understand why it
> became "1-". I am trying to implement your algorithm and I just want
> to know what lines 7, 16 and
1 - 100 of 133 matches
Mail list logo
