On Sun, Feb 24, 2008 at 4:22 PM, Raymond Wold <[EMAIL PROTECTED]>
wrote:
> Don Dailey wrote:
> > No. cgos does not use GTP protocol for communicating with server.
> > Also, I have eventual plans to extend what is communicated to the
> > client and this is not compatible with the current GTP set
Get ubuntu (http://www.ubuntu.com/). You can ask them to send you a
free CD. And you should consider getting a decent Internet connection.
Álvaro.
On Wed, Apr 9, 2008 at 10:54 AM, <[EMAIL PROTECTED]> wrote:
> I got excited about the free software sometime ago and bought a copy of
> Susie Linux
On Tue, May 13, 2008 at 1:04 PM, Jason House
<[EMAIL PROTECTED]> wrote:
> [,,,]
> I have a list of empty points. I pick one at random and then scan until I
> find a legal one. Others reduce the list size (swap to end?) and repick.
What others do is the right thing to do. Your method will introduc
On Tue, May 13, 2008 at 1:51 PM, Mark Boon <[EMAIL PROTECTED]> wrote:
>
> On 13-mei-08, at 14:10, Álvaro Begué wrote:
>
>
> What others do is the right thing to do. Your method will introduce
>
> some biases.
> Could you elaborate what bias it could lead to? I also
],empties[num_candidates]);
}
else
break;
}
return picked;
}
On Tue, May 13, 2008 at 1:57 PM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> On Tue, May 13, 2008 at 1:51 PM, Mark Boon <[EMAIL PROTECTED]> wrote:
> >
> > On 13-mei-08, at 14:10, Álvaro Begué wrote:
&g
On Tue, May 13, 2008 at 2:28 PM, Mark Boon <[EMAIL PROTECTED]> wrote:
>
> On 13-mei-08, at 15:08, Jason House wrote:
>
> The range of the random number is reduced by one after each failed lookup.
> Shuffled data has no impact on future use of the array of empty points.
>
> OK, I understand now why
On Tue, May 13, 2008 at 3:08 PM, Mark Boon <[EMAIL PROTECTED]> wrote:
>
> On 13-mei-08, at 15:44, Álvaro Begué wrote:
>
>
> > On Tue, May 13, 2008 at 2:28 PM, Mark Boon <[EMAIL PROTECTED]>
> wrote:
> >
> > >
> > > On 13-mei-08, at 15:0
On Tue, May 13, 2008 at 4:22 PM, Carter Cheng <[EMAIL PROTECTED]> wrote:
> 2) When generating random variables for the case where the "values" of
> placing a stone on different points on the board are different. Are there
> good ways to throw and determine which point has been selected for the n
On Tue, May 13, 2008 at 8:10 PM, Weston Markham
<[EMAIL PROTECTED]> wrote:
> On Tue, May 13, 2008 at 7:08 PM, Gunnar Farnebäck <[EMAIL PROTECTED]> wrote:
> > And I agree, don't even think of doing this with floating point
> > numbers.
>
> This is a bit tangential to computer go. But you have
On Tue, May 13, 2008 at 11:57 PM, Hideki Kato <[EMAIL PROTECTED]> wrote:
>
> Álvaro Begué: <[EMAIL PROTECTED]>:
> >Ooops! I hit sent before I finished writing the pseudo code. Sorry.
> >
> >int pick(Move *empties, int num_empties) {
> > int num
On Wed, May 14, 2008 at 10:12 AM, Heikki Levanto <[EMAIL PROTECTED]> wrote:
> On Wed, May 14, 2008 at 03:47:55PM +0200, Norbert Gábor Papp wrote:
>> I want to remove dead-stones which means :
>> [...]
>> I'm interested in the function dead(), which is true when a stone is dead
>> after both player
On Fri, Jun 13, 2008 at 12:59 AM, Peter Drake <[EMAIL PROTECTED]> wrote:
> So far we've had two entries, both with caveats.
> Could others please sound off on whether you're coming, and if not, why not?
> 1) Can't afford the time
> 2) Can't afford the money
> 3) Don't feel my program is strong enou
On Thu, Jul 17, 2008 at 12:55 PM, Jason House
<[EMAIL PROTECTED]> wrote:
> [...]
> I don't own a computer with Windows on it, and that adds significant
> headache. It's hard to convince friends/work to install cygwin for this kind
> of purpose. Portability between Linux flavors is not guaranteed. F
On Thu, Jul 17, 2008 at 1:25 PM, Jason House
<[EMAIL PROTECTED]> wrote:
> On Jul 17, 2008, at 1:12 PM, "Álvaro Begué" <[EMAIL PROTECTED]> wrote:
>
>> On Thu, Jul 17, 2008 at 12:55 PM, Jason House
>> <[EMAIL PROTECTED]> wrote:
>>>
>>&g
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 analyzing a position and
g
On Sun, Jul 20, 2008 at 10:10 AM, Jason House
<[EMAIL PROTECTED]> wrote:
> On Jul 20, 2008, at 9:10 AM, "Álvaro Begué" <[EMAIL PROTECTED]> wrote:
>
>> On Sun, Jul 20, 2008 at 3:40 AM, Rémi Coulom <[EMAIL PROTECTED]>
>> wrote:
>>>
>>>
On Mon, Jul 21, 2008 at 7:32 PM, Jason House
<[EMAIL PROTECTED]> wrote:
> I'm starting heavy plyouts, with variable move selection weights. The
> proximity heuristic seems like a performance killer since most weights would
> require an update with each move.
>
> How do others handle this? Is proxim
On Mon, Jul 21, 2008 at 10:41 PM, Jason House
<[EMAIL PROTECTED]> wrote:
> On Jul 21, 2008, at 10:26 PM, "Álvaro Begué" <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Jul 21, 2008 at 7:32 PM, Jason House
>> <[EMAIL PROTECTED]> wrote:
>>>
>&
On Sat, Aug 2, 2008 at 9:43 AM, Jason House <[EMAIL PROTECTED]> wrote:
> On Aug 2, 2008, at 4:31 AM, Gunnar Farnebäck <[EMAIL PROTECTED]> wrote:
>
>> It's often a good idea to bias capturing moves in the playouts,
>> regardless whether it's a ladder or not. This would result in those
>> stones bein
I'm running the *-a2 anchors with the settings that Don gave me. I'll
stop them now.
Don, please send me an updated configuration file.
Álvaro.
On Tue, Aug 12, 2008 at 10:31 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-08-12 at 08:09 -0600, Markus Enzenberger wrote:
> I don't know i
-rules --min-level 10 --max-level 10 --positional-superko
└─pstree,7791 -ap alvaro
On Tue, Aug 12, 2008 at 12:08 PM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> I'm running the *-a2 anchors with the settings that Don gave me. I'll
> stop them now.
>
> Don, please send
On Mon, Aug 25, 2008 at 7:06 AM, Magnus Persson <[EMAIL PROTECTED]> wrote:
> Quoting Jacques Basaldúa <[EMAIL PROTECTED]>:
>
>> When you detect self atari in the playouts (something I haven't tried
>> yet, but
>> from recent posts in this group I am convinced that it is an important
>> issue)
>> a
On Mon, Sep 8, 2008 at 11:45 AM, Olivier Teytaud <[EMAIL PROTECTED]> wrote:
>>
>> By my recent experiments, 8~9 * (threads - 1) ELO is lost. This
>> matches my earlier result well.
>
>
> Do you have tricks for avoiding redundancies between simulations ?
> I suggest simple tricks like "do not go to
On Fri, Sep 19, 2008 at 1:29 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> Would go on a torus be interesting? There are not corners or edges, the
> sides of the board simply wrap around.
>
> - Don
Yes, it's probably similar in spirit to regular go, except everything
feels like the center of the bo
On Fri, Sep 26, 2008 at 9:29 AM, Jason House
<[EMAIL PROTECTED]> wrote:
>
>
> Sent from my iPhone
>
> On Sep 24, 2008, at 5:16 PM, Jason House <[EMAIL PROTECTED]>
> wrote:
>
>> On Sep 24, 2008, at 2:40 PM, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
>>>
>>
>>> Therefore, the variance of the normal
On Mon, Sep 29, 2008 at 5:11 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> You are right, I didn't notice that.
>
> I am doing the 8 transformations of move SEQUENCES, which is not quite
> the same as transforming and adjusting the positions themselves which
> would be a more powerful way to do this.
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
ey, the other tries to be fast
> and cheats.
>
> - Don
>
>
>
> On Thu, 2008-10-09 at 09:36 -0400, Álvaro Begué wrote:
>> On Thu, Oct 9, 2008 at 9:26 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
>> > If you use zobrist hashing, it is probably not ridiculously
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
You won't get any playouts whose outcome is even, so 3.5 and 4.5 are
effectively the same komi in this experiment (it would be different if
seki were possible, but naive playouts don't result in seki).
Your results seem very plausible to me.
Álvaro.
On Thu, Jan 8, 2009 at 1:59 PM, Isaac Deutsc
I've thought about this a bit, although I haven't implemented
anything. I think one has to try for (i), but given the huge penalties
you pay for branching if not all processors in a group follow the same
path, I can't see how to make it work. (ii) would be a lot easier, and
one can then do quite a
When John Tromp and I were thinking about these things in 2007 we
decided to switch to counting real liberties instead of
pseudo-liberties. Someone (Rémi?) told us that in the end the
performance difference wasn't very large, and we verified this.
Álvaro.
On Wed, Apr 1, 2009 at 2:08 PM, Isaac De
I haven't implemented this successfully, so I probably shouldn't be
giving advice to anyone, but what I was trying to do when we stopped
developing dimwit was the following:
* When a thread enters a node of the UCT tree, increment the number
of losses (This will discourage other threads from enter
This conversation is rather futile. The CGOS website contains rules
that clearly state that positional superko is used. There is no bug.
Nothing to see here.
If you like other rules better, you can implement them in your own server.
Álvaro.
On Tue, Apr 14, 2009 at 1:21 PM, Richard Brown wrote:
On Tue, Apr 28, 2009 at 10:50 AM, Rémi Coulom
wrote:
> Don Dailey wrote:
>>
>> I don't quite understand this. If I try move m0, which we will assume is
>> the only winning move, but on the first simulation it turns out to lose,
>> then from what you seem to be saying I would never try it again?
You have the most control with option 1. You can implement this fast
by keeping the sum of the weights for each row and for the total
board. You then "roll" a number between 0 and total_weight, and
advance through the rows subtracting the probability of each row until
you would cross 0, then go alo
On Fri, May 22, 2009 at 5:47 PM, Dave Dyer wrote:
>
> Some lines of play involving large captures will effectively never
> terminate, even with superko rules in effect.
>
> I doubt it is possible to eliminate all these non-terminating
> lines of play in any way that is provably correct.
>
> .. So
2009/5/24 Don Dailey :
>
>> Believe it or not, I had to do special coding to handle CGOS. my bot tried
>> to adapt to network lag. Because the average lag for CGOS is negative,
>> subtracting future network lag before allocating time is incorrect. The time
>> allocation math would plan to have no t
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
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
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
On Sat, Jun 6, 2009 at 3:18 AM, Heikki Levanto wrote:
> On Fri, Jun 05, 2009 at 03:49:11PM -0400, Don Dailey wrote:
>> Handicap games opens a can of worms.
>
> Of course, any program is free to give its opponent any handicap it wants,
> by passing in the opening (if the opponent didn't pass last).
On Thu, Jun 18, 2009 at 6:43 PM, Michael
Williams wrote:
> Section 3.2 describes a pair of tests that took about 4.2 minutes each (if
> my calculations are correct). Why not play more games and have each game
> contain more simulations? Writing the code and the paper is the hard part,
> waiting f
I thought about this a long time ago, but I thought it would only make
a difference when the number of simulations is very small, which
should probably be covered by heuristics, so I don't think the
refinement for the standard deviation will matter much in the end.
Even though the article is about
On Fri, Jun 19, 2009 at 1:58 PM, Michael
Williams wrote:
> Is it pronounced few-go or fway-go?
It's a Spanish word (it means "fire"), so I always thought it was
pronounced that way. I don't know how you would transliterate that for
English speakers. I am guessing your second option is a bit closer
2009/6/19 terry mcintyre :
> From merriam webster entry for "terra del fuego", it can be "foo-ay-go" or
> "fway-go"
>
> It's a Spanish word -- have to ask some Spanish speakers their opinions.
>
> http://forvo.com/word/fuego/ -- to my ear, it sounds like "foo eh go" --
> three distinct syllables.
2009/6/23 Olivier Teytaud :
> By the way, the conditions for consistency in Astar, which is quite related
> to Monte-Carlo Tree Search in my humble opinion, imply optimism in the sense
> that the value must be overestimated. UCT/MCTS is really similar to Astar
> without so-called "close set".
Can
Jason,
Gmail has an option "show in fixed width font" that is perfect for
these situations.
Álvaro.
On Tue, Jun 30, 2009 at 1:25 PM, Jason House wrote:
> Is it possible to explicitly use a monospace font? I can't read your board
> positions.
>
> I haven't heard of any handling of seki in playou
You can also test against weaker programs with compensating handicap.
It might not be quite as interesting, but it's easier to test.
2009/7/8 terry mcintyre :
> To properly test any method of playing with a handicap, today's programs
> will need to play against much stronger opponents. Self-play,
On Thu, Aug 20, 2009 at 9:06 AM, Jason House wrote:
> I changed my search from one tree per search thread to a shared (lock-free)
> tree among all threads. Back with dedicated trees, I would set a visited
> flag as I walked the tree. With a shared tree are there any clever ways to
> detect cycles /
Are you not going to tell us what this new job is about?
I don't have a use for a pattern matcher right now, but I really liked
your idea. I can see myself using it in the future.
Thanks!
Álvaro.
2009/10/10 Mark Boon :
> I have been meaning to write this for a long time now. A new job in a new
We should let go of this idea that artificial neural networks have
anything to do with the brain. ANNs are just a family of parametric
functions (often with too many parameters for their own good) and
associated tuning algorithms ("learning" is a bit pretentious).
Perhaps they took vague inspiratio
2009/10/31 :
> Present day MC Go programs are neural networks. The playout is the trainng
> process.
What?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Sun, Nov 1, 2009 at 7:50 PM, Aldric Giacomoni wrote:
> Álvaro Begué wrote:
>> 2009/10/31 :
>>> Present day MC Go programs are neural networks. The playout is the trainng
>>> process.
>>
>> What?
>> _
> [...]
> 1) Baduk -- used in another sense only as a stative verb in
> Basque [extremely few web pages in Basque!], and seen
> extremely rarely as the transliteration of a Farsi word
> (thus a film name)
Ah, Basque is a crazy language. In case anyone is curious, it seems
that "baduk" means
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
Hi, everyone. This is my first post to the list.
Beginning chess programmers have something called "perft" at their
disposal, which is just a count node of a search tree of fixed depth,
with no prunning whatsoever and no extensions. It's easy to detect
errors in your move generation or do/undo fu
Don,
Will you make a perl script available? I don't have tcl installed on
my machines, and the perl script for the old server seems to work
well.
Thanks,
Álvaro.
On 3/26/07, Don Dailey <[EMAIL PROTECTED]> wrote:
I have a prototype of the new CGOS server up and running.
Please help me test it
Either 5 or 10 minutes per side is fine by me, with a mild preference
toward 10 minutes for two reasons: hysteresis (if it ain't broke,
don't fix it) and it gives me enough time to broadcast the moves by
hand to John Tromp so he can comment on the game; I couldn't do this
twice as fast. :) I also
On 3/27/07, Don Dailey <[EMAIL PROTECTED]> wrote:
On Tue, 2007-03-27 at 20:49 -0400, Álvaro Begué wrote:
> Either 5 or 10 minutes per side is fine by me, with a mild preference
> toward 10 minutes for two reasons: hysteresis (if it ain't broke,
> don't fix it) and i
On 3/28/07, Nick Wedd <[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>, "Angel
\"Java\" Lopez" <[EMAIL PROTECTED]> writes
>- Any developer from Argentina (or Spanish-spoken) working in Computer
>Go? We have a Yahoo Groupsin Spanish at:
>http://ar.groups.yahoo.com/group/computergo
Joan
On 4/11/07, Sylvain Gelly <[EMAIL PROTECTED]> wrote:
2007/4/11, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
>
> I watched MoGo playing with different rank of players. Usually 5d players
has no problem winning. Starting from 4d begin to lose games. However, part
of it is due to most players are not f
I am a big fan of UCI, and it would be great if we could use a similar
interface for go.
The only part I would probably not try to reproduce for go is the
pondering scheme. In chess assuming the opponent had moved the
predicted move was the most popular choice by far, so it was ok to
have it ingr
This is something that I have been wondering about. It seems to me that
since UCT is exploring moves by choosing the move with the most
optimistic score (estimate plus confidence bound) that it would be very
natural to play the move with the highest conservative score (estimate
minus confidence bo
As part of our testing of dimwit I have set up simple life-and-death
problems by filling out most of the board with stones of the color on
the outside of the problem and by setting the komi so that the result
of the game is effectively whether the group in the problem lives or
not. This has worked
On 5/1/07, Chris Fant <[EMAIL PROTECTED]> wrote:
> You can:
>
> a) Guess your opponents next response, and assume they will make this
> move. Fire off a search from the resultant position. If you guess
> correctly, then you save X seconds. But if you only guess correctly p
> % of the time, you ex
On 5/1/07, Darren Cook <[EMAIL PROTECTED]> wrote:
> smaller for larger boards. The only part of our program that is not
> strictly ANSI C++ compliant is is_there_input(), ...
> ...
> return select(1,&read,&write,&except,&timeout);
> ...
> If you are interested on a Windows equivalent, I might be
We are using a compromise between the two options that Don described.
We have a tree using indices to a big vector (which is about the same
thing as pointers), and we have a separate structure that maps zobrist
keys to indices in the vector, using a hash. This map is only queried
when we add a pos
On 5/11/07, Jason House <[EMAIL PROTECTED]> wrote:
On 5/11/07, Brian Slesinsky <[EMAIL PROTECTED]> wrote:
> > Going along with this, the numbers won't add up (although I don't know
> > if that is important.) In other words, if you do 10,000 simulations at
> > the root, all grandchildren will
On 5/11/07, Álvaro Begué <[EMAIL PROTECTED]> wrote:
On 5/11/07, Jason House <[EMAIL PROTECTED]> wrote:
>
>
> On 5/11/07, Brian Slesinsky <[EMAIL PROTECTED]> wrote:
> > > Going along with this, the numbers won't add up (although I don't know
> &g
On 5/12/07, Chris Fant <[EMAIL PROTECTED]> wrote:
> John corrected me. It turns out we do add the playouts from the
> possible moves (we didn't used to in my original implementation, but
> he changed that). The difference with what Jason described is that we
> do not use the playout count from th
Rémi:
John and I are planning a similar usage of patterns and features in
the MC simulations, although we were thinking of a very different
method to update "strengths". Although we derived our formulas from an
extension of the logistic regression instead of Bradley-Terry models,
we arrived at ve
On 5/18/07, Rémi Coulom <[EMAIL PROTECTED]> wrote:
David Silver wrote:
> Very interesting paper!
>
> I have one question. The assumption in your paper is that increasing
> the performance of the simulation player will increase the performance
> of Monte-Carlo methods that use that simulation play
On 5/30/07, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
Lukasz Lew wrote:
> Is libego too complicated? Do You have problems with compilation?
> Or You are not comfortable with the GNU license? Any other reason?
I only wanted to compare performance ( and see what good ideas
you had ;-) ) but c
On 5/30/07, Berk Ozbozkurt <[EMAIL PROTECTED]> wrote:
Álvaro Begué wrote:
>>
>> At least for Windows programmers, providing a solution that
>> compiles with major IDEs would help. I assume what you do is
>> "standard" in Linux, but the things the comp
On 6/6/07, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
For the problem in which moves have probability in {0, 1/n} of
being selected (n = number of legal moves or empty points
depending on the approach), what Don does, i.e.:
Keeping a vector of selectable/not selectable points with a moving
limi
On 6/6/07, Rémi Coulom <[EMAIL PROTECTED]> wrote:
Álvaro Begué wrote:
>
> Actually, John had a better idea to do this. In two words: binary
> tree. The root represents the whole board, and it contains the sum of
> the probabilities of all the points (you don't need to f
I am not a Java expert, so some of what I say here might be
wrong/outdated. I don't think JIT can make Java as fast as C/C++.
There are still things Java does in ways that cannot be fast. For
instance, you can't construct objects on the stack, so you need to use
the heap for everything. Also, pass
What part of a go program written in C or C++ are you guys having
portability problems with? In dimwit there might be some assumptions,
like ints being at least 32 bits, that are not portable, and we use a
64-bit type, which is not described in the C++ standard (the C99
standard does have one). Ot
On 6/21/07, igo <[EMAIL PROTECTED]> wrote:
[...]
The writer's conclusion is "Keep it Simple!",
but the Fischer timing's action is not simple to understand.
Can someone explain me why a player receives times after played a move
even when he doesn't lack of time ?
It really is simple. You start w
On 7/19/07, Chris Fant <[EMAIL PROTECTED]> wrote:
On 7/19/07, steve uurtamo <[EMAIL PROTECTED]> wrote:
> my guess is that you are in fact missing something --
> it seems unlikely that they enumerated _on disk_ all
> possible games and their correct response moves.
>
> anything taking up less spac
On 8/25/07, Phil G <[EMAIL PROTECTED]> wrote:
>
> Can someone recommend a good paper on distributed alpha-beta searching? Not
> necessarily for Go; I'm just interested in reading up on the subject.
>
> Thanks,
>
> - Phil
>
Some of the most popular algorithms are YBWC (Young Brothers Wait
Concept) a
On 8/25/07, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> [...]
> I remember seen a lengthy article comparing different methods in the
> ICGA journal, but I can't find it.
Found it. It's here: http://citeseer.ist.psu.edu/b
Remi keeps a number that is the sum of all the probabilities (I'll
call them that, although they are not normalized so they add up to 1)
and also one number per row that is the sum of the probabilities of
the points in that row. Now you pick from the distribution of rows,
and inside the row from th
On 11/7/07, Don Dailey <[EMAIL PROTECTED]> wrote:
>
> [...]
> To go beyond 5x5, say 7x7 would require an endgame table with 3**49
> entries or 239299329230617529590083 entries. This can be reduced by
> about 8x if you remove symmetrically equivalent positions.This is
> pretty intractable, won
On 11/7/07, Joshua Shriver <[EMAIL PROTECTED]> wrote:
>
> You could go the route chess does with egtbs.
That won't work for go. First of all, chess and checkers are games where the
position on the board becomes simpler at the end of the game, so many games
will end up converging on positions for
On Nov 13, 2007 3:36 PM, Stefan Nobis <[EMAIL PROTECTED]> wrote:
> You miss the point: Using languages with GC is not about programmers
> who can't avoid memory leaks. It's not about ability, it's about
> productivity. If the only reason you don't use assembler is that with
> C your code is easier
On Nov 14, 2007 10:54 AM, steve uurtamo <[EMAIL PROTECTED]> wrote:
> > I just wanted to point out that free() is not a system call. The heap is
> handled by the
> > C library, and the OS is mostly not involved in it.
>
>
>
> my bad. thanks. :)
>
> in that case, i'm impressed that i can do 2GB al
On Nov 14, 2007 10:25 AM, steve uurtamo <[EMAIL PROTECTED]> wrote:
> > And it's not fast either. Free() has a reputation of being
> > slow, and that's not surprising if you look at the way it is
> > almost always implemented: scanning a list of addresses in
> > order to amalgamate the newly freed
On Nov 14, 2007 4:58 PM, William Harold Newman <[EMAIL PROTECTED]>
wrote:
> On Wed, Nov 14, 2007 at 10:40:15AM -0500, Álvaro Begué wrote:
> > Anyway, go programmers should probably not be using a whole lot of
> dynamic
> > memory allocation, and certainly not enough to
On Nov 16, 2007 10:54 AM, A van Kessel <[EMAIL PROTECTED]> wrote:
> > Yep, I think I had a bug. I just removed an optimization that I
> I just checked your array, and found that {14 56 383 3047} --> 3500 --> 875,
> which is also in the array. Back to the old drawing board.
>
> BTW I don't get this
On Nov 21, 2007 1:41 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> > (gcc also supports -fprofile-generate and -fprofile-use, which is pretty
> > cool too - gcc will re-optimize the binary based on profiling
> > information gathered from a test run of the program. It can be quite a
> > non-trivial bo
The solution that John Tromp found, for 9x9 is this:
Keep an extended pseudo-liberty count that looks like this:
lower 8 bits: Standard pseudo-liberty count
next 12 bits: Encoding of x-coordinate information
next 12 bits: Encoding of y-coordinate information
For each block of 12 bits we need to f
On Dec 4, 2007 1:42 AM, Petri Pitkanen <[EMAIL PROTECTED]> wrote:
> > There is something that the latest Monte Carlo programs have in common
> > with the best chess programs - and seems to be the right way to
> > structure a game tree search.Your selectivity should be
> > progressive. In o
On Dec 4, 2007 3:57 PM, Zach Wegner <[EMAIL PROTECTED]> wrote:
> On Nov 13, 2007 2:44 PM, Jason House <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Nov 13, 2007 3:32 PM, John Tromp <[EMAIL PROTECTED]> wrote:
> >
> > > > Is there any known way to get the best of the both worlds? :-)
> > >
> > > Yes,
A long time ago I thought of how to organize what to prune The Right Way
(tm). I initially thought about it in the context of computer chess, but I
think it is even more relevant for computer go. Instead of doing global
search where you say "a node will be considered a leaf if it is n moves away
fr
On Dec 5, 2007 9:33 AM, Erik van der Werf <[EMAIL PROTECTED]> wrote:
>
> Look for Realization Probability Search.
>
>
Oh, thanks! I knew it was too natural to be original. Well, I actually
thought about it around 1998, so it might have been new back then.
This is very close to what I was saying:
On Dec 5, 2007 1:35 PM, Don Dailey <[EMAIL PROTECTED]> wrote:
> Yes, I think there is a lot to this.Searching by depth is rather
> arbitrary.
>
> I think this basic idea is called "realization probabilities" and I
> thought of doing it with the Bradley Terry model.
>
> It also occurred to me
On Dec 5, 2007 11:33 AM, Erik van der Werf <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007 5:01 PM, Álvaro Begué <[EMAIL PROTECTED]> wrote:
> > On Dec 5, 2007 9:33 AM, Erik van der Werf <[EMAIL PROTECTED]>
> wrote:
> > >
> > > Look for Realization Proba
On Dec 5, 2007 9:39 AM, Dave Dyer <[EMAIL PROTECTED]> wrote:
>
> The problem with this is that below a few ply, the probabilities are
> all effectively zero. All you're really doing is enshrining the
> prior probabilities used to sort the first few levels.
Why would they be zero? floating-point
1 - 100 of 242 matches
Mail list logo
