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
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 it gives me enough time to broadcast
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 Pons i
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 familar
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
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
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 add up to
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
if that is important.) In other words, if you do 10,000
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 the
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 player.
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
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 compiler did not understand
neither did I, and I could
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,
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).
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 space than
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/brockington96taxonomy.html
___
computer
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
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 to
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 allocations.
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 memory
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 make the performance of
free
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 boost.)
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
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 order to
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, you can generalize
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
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 that if a
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 Probability Search.
Oh, thanks! I knew it was too natural
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 types
Thanks for the file! This should be very helpful when I try to reproduce
results.
It looks like you are not taking advantage of symmetries. For instance,
88|0|17.033168
88|1|12.263955
and
164|0|17.388714
164|1|25.862695
Are identical except for swapping the roles of white and black (88 ==
Oh, I see you have applied the symmetries, but not the swapping of roles.
Still, this should probably be done and cut the number of gamma values in
half.
Álvaro.
On Dec 6, 2007 7:13 AM, Álvaro Begué [EMAIL PROTECTED] wrote:
Thanks for the file! This should be very helpful when I try
On Dec 10, 2007 10:07 AM, Don Dailey [EMAIL PROTECTED] wrote:
I forgot mention why FEN is flawed. It's because it fails to capture
the complete state of the game. It records en-passant information and
color to move, but it's does not capture position history so you
cannot detect draws
On Dec 10, 2007 11:05 AM, Erik van der Werf [EMAIL PROTECTED]
wrote:
On Dec 10, 2007 4:35 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
In GO, this is probably a more serious problem.
Yes, there is no such thing as an irreversible move in go.
Well there is the opening move... (unless suicide
On Dec 10, 2007 11:48 AM, Don Dailey [EMAIL PROTECTED] wrote:
Of course if only simple KO is used, then repetition is not an issue -
you only have to store the simple ko state fen style.
But none of this is any good for a general solution (a simple text based
position notation.)
We could
On Dec 10, 2007 11:56 AM, Nick Wedd [EMAIL PROTECTED] wrote:
In message
[EMAIL PROTECTED], Álvaro
Begué [EMAIL PROTECTED] writes
It is not my intention to sound confrontational. I really don't know
how other rule sets deal with tricky situations.
For long-cycle repetitions:
Japanese
Why does anybody care about how human-like our go programs' playing style
is? When we design airplanes we don't care about how bird-like their flying
style is; we care about objective measures like speed, acceleration, energy
efficiency... The merits of go programs should be based basically on
On Dec 12, 2007 2:32 PM, Stefan Nobis [EMAIL PROTECTED] wrote:
[...] and sometime it's even possible to outperform C code.
I just don't believe this. I propose a simple experiment to see who is
right. You pick a simple algorithm which you claim Lisp can run faster, you
propose the fastest Lisp
On Dec 12, 2007 3:05 PM, Jason House [EMAIL PROTECTED] wrote:
On Dec 12, 2007 2:59 PM, Rémi Coulom [EMAIL PROTECTED] wrote:
Do you mean a plot of the prediction rate with only the
gamma of interest varying?
No the prediction rate, but the probability of the training data. More
On Dec 12, 2007 3:31 PM, Jason House [EMAIL PROTECTED] wrote:
On Dec 12, 2007 3:09 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
On Dec 12, 2007 3:05 PM, Jason House [EMAIL PROTECTED]
wrote:
On Dec 12, 2007 2:59 PM, Rémi Coulom [EMAIL PROTECTED]
wrote:
Do you mean
On Dec 12, 2007 7:44 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
Maybe I did something wrong, but dimwit aces this one:
10k 100k1M
dimwit-0.48r 1.000 1.000 1.000
This is the output at the end of those searches:
score=1 thr=5 moves
On Dec 13, 2007 2:28 PM, Forrest Curo [EMAIL PROTECTED] wrote:
It's the approach I believe to be more human-like. Not necessarily the
playing style.
Human beings chunk.
What all this fuss suggests to me is a meta-mc program... You
include routines that work out good sequences, as a
At the end of a playout there is probably some code that says samoething
like
reward = (score komi) ? 1.0 : 0.0;
You can just replace it with
reward = 1 / (1 + exp(- K * (score - komi)));
A huge value of K will reproduce the old behaviour, a tiny value will result
in a program that tries to
On Dec 18, 2007 3:12 PM, Don Dailey [EMAIL PROTECTED] wrote:
Harald Korneliussen wrote:
Some thinking out loud here on the topic of languages and efficiency:
I'd like to know how well MoGo would have played if you let it think
for a week for every move. Only it seems to me that is not
On Dec 18, 2007 4:21 PM, Don Dailey [EMAIL PROTECTED] wrote:
Chris Fant wrote:
I suspect that for very long time controls we would be better off
turning UCT (with, say 10K playouts) into an evaluation function and
then using alpha-beta on top of it.
Álvaro.
This is very
On Dec 19, 2007 3:08 AM, Ben Lambrechts [EMAIL PROTECTED]
wrote:
Hi all,
I am planning a fuseki database.
Now I got the following problem: how to rotate/mirror the board for a
unique representation.
$$c
$$ +---+
$$ | . . . . . . . . . . . . . . . . . .
Say you represent the content of each point with 0 for empty, 1 for black
and 2 for white. Start by creating a table of 19x19x3 random 64-bit numbers.
unsigned long long zobrist_table[19][19][3];
...
unsigned long long zobrist_key=0;
for(int row=0;row19;++row){
for(int col=0;col19;++col){
Yes, you can set all the values in the table that correspond to empty points
to 0 or, equivalently, only have 2 numbers per point. Actually, that's what
our code does too. But that's a very minor optimization, and I think the
concept is easier to understand without it.
On Dec 19, 2007 9:33 AM,
On Dec 20, 2007 10:19 AM, Jason House [EMAIL PROTECTED] wrote:
On Dec 20, 2007 10:15 AM, Arthur Cater [EMAIL PROTECTED] wrote:
With 8 hashes per position, the chance of two different boards
producing a different set of hashes but
the same canonical hash is greater than 1/2^64, because
On Dec 20, 2007 11:23 AM, Arthur W Cater [EMAIL PROTECTED] wrote:
I think that would be worse. There are lots of sets of 8 numbers that sum
the same,
far more than there are sets of 8 with the same minimum element.
Arthur
- Original Message -
From: Álvaro Begué [EMAIL PROTECTED
I was trying to come up with my own algorithm to maximize likelihood and I
am having a hard time getting it all in my mind. I managed to write a
working algorithm for the case of logistic regression, but it was kind of
brittle and I didn't know how to extend it to the softmax case, which is
what I
On Dec 20, 2007 10:36 PM, Jason House [EMAIL PROTECTED] wrote:
On Dec 20, 2007 5:39 PM, Álvaro Begué [EMAIL PROTECTED] wrote:
Over lunch I thought of another way of doing it that would be very
general and easy to implement. Basically, I can compute the log-likelihood
for a particular
On Dec 21, 2007 8:53 AM, Rémi Coulom [EMAIL PROTECTED] wrote:
Hi,
Minorization-maximization is a simple optimization method, and I agree
that it is likely that more efficient algorithms can be applied.
Newton's method implies estimating the inverse of the Hessian matrix.
Really computing
English is weird. http://www.answers.com/topic/night says among other
definitions:
1. a. The period between sunset and sunrise, especially the hours of
darkness.
3. a. The period between evening and bedtime.
It seems to me that in the U.S.A. entry 3.a. is the most common meaning,
while I
On Jan 31, 2008 2:59 PM, [EMAIL PROTECTED] wrote:
I'm going to call this the procrastination effect. MY claim is that,
when MC-UCT encounters a critical life and death board situation that its
playout policy consistently gets wrong, the search will naturally tend to
skew the tree so that
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 introduce
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 do the same as Jason.
I did consider
],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:
What others do is the right
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:08, Jason House wrote:
The range of the random number is reduced by one
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 piqued my
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_candidates = num_empties;
int picked;
while(1
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 pass,and
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 enough to
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. For
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:
[...]
I don't own a computer with Windows on it, and that adds significant
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
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:
Rybka 3 has Monte-Carlo evaluation:
http://www.chessbase.com/newsdetail.asp?newsid
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 proximity
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:
I'm starting heavy plyouts, with variable move selection weights. The
proximity
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 being captured
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 if
-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 me an updated configuration file
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 new problem
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 node X if
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 board.
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 that best approximates
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 (
stronger.
In my programs, I don't maintain a key or do PSK in the playouts. I
have 2 versions of everything involving move generation. One make()
function tests for superko and builds a key, 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 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 meaningless.
I
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
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
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
On Tue, Apr 28, 2009 at 10:50 AM, Rémi Coulom
remi.cou...@univ-lille3.fr 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
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
On Fri, May 22, 2009 at 5:47 PM, Dave Dyer dd...@real-me.net 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
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,
On Mon, Jun 1, 2009 at 9:38 AM, Isaac Deutsch i...@gmx.ch 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
On Mon, Jun 1, 2009 at 10:10 AM, Isaac Deutsch i...@gmx.ch 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
On Sat, Jun 6, 2009 at 3:18 AM, Heikki Levantohei...@lsd.dk 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
On Thu, Jun 18, 2009 at 6:43 PM, Michael
Williamsmichaelwilliam...@gmail.com 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
On Fri, Jun 19, 2009 at 1:58 PM, Michael
Williamsmichaelwilliam...@gmail.com 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
2009/6/19 terry mcintyre terrymcint...@yahoo.com:
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
2009/6/23 Olivier Teytaud teyt...@lri.fr:
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
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 Housejason.james.ho...@gmail.com wrote:
Is it possible to explicitly use a monospace font? I can't read your board
positions.
I haven't heard of any
1 - 100 of 208 matches
Mail list logo
