John wrote:
which confirm yours. we also found a general formula n^2 -
floor((n^2+4n-16)/5)
The formula can also be written floor(4n(n-1)/5+4) for a slightly more
compact expression.
here's a nice symmetric 19x19 position with 277 strings:
X O . O . O X O . O . O X O . O . O X
. X O X O
Hi
I did some clean up in http://senseis.xmp.net/?KGSBugs
most visible one is moving old KGS2/Cgoban2 bugs to
a separate page
btw, it would nice to have reading access to Bugs Tacking System
to add a link, and possibly add comment on senseis page.
Alain.
Le mercredi 6 décembre 2006 23:01, Robert Jasiek a écrit :
House, Jason J. wrote:
Can anyone honestly say that they're still working on the restrucring?
When trying to read parts of it a few days ago, I have found it useful
to restructure the related contents (topics: rules, ratings). IMO,
I really do randomize a whole vector of empty intersections before the playout.
When I get new empty intersection I just pick random place in vector,
move it to the end,
and use the place for new intersection.
Here is the code:
void add_rnd (v::t v) {
int ii;
empty_v_cnt++;
ii =
Yes, it's clear how you do it. I suspect this is better than what I
do. My list of intersections include ALL the intersections not just the
empty ones and use a fixed or static array. But this is all easy to
change.
I will give this a try at some point and let you know if it's faster.
-
I test on IGS, and I also see a lot of cheating against the computer.
Many Faces does its own scoring and transmits dead stone status. This
prevents people from not indicating their dead stones. Many Faces keeps
track of people who escape without finishing a game and won't accept matches
from
I just made a wonderful discovery!
The D version is in fact only 7 percent slower than C.
Earlier I mentioned the ONLY difference was the random number generator
- well it turns out the random number generator was a big deal.
The Mersenne twister is apparently far faster than the D
Let me propose the following rules for comment:
1) The vast majority of your time is spent making RANDOM moves
(beyond the leaves of your tree).
2) Almost none of your nodes have more than one child.
These, along with the KISS principle, seem to point to a lot of
optimizations in both
On Thu, 2006-12-07 at 10:24 -0800, Peter Drake wrote:
Got it -- now I'm getting just under 10,000 games per second! Whee!
Hold on, I thought the non-threaded version was doing 5,000? What
exactly did you change? Or are you just using 2 processors more
efficiently to get 10,000 games?
- Don
What about having each MC thread queue up it's results and have another
thread read the queue and update the tree... This is assuming that a the
time to update the tree is long and the time to enqueue is very short.
Jeffrey Greenberg
http://www.inventivity.com
http://www.jeffrey-greenberg.com
If this randint routine is critical, you can save some calls to rand()
when you know that n is always below some value (see my previous post
about bitmap go).
For instance if n 128 (probably true for 9x9 go), you could try:
while (true) {
r = rand();
if ((r v) n) return (r v);
r = 7;
On Dec 7, 2006, at 11:08 AM, Don Dailey wrote:
On Thu, 2006-12-07 at 09:17 -0800, Peter Drake wrote:
I do have the undo ability, but I think it's done in (I think) a
very
efficient way. For example, when I want to undo a bunch of move at
once (e.g., after a MC run) I just reduce a stack
On 7, Dec 2006, at 2:09 PM, Peter Drake wrote:
Are you one of those who advocates ignoring the ko rule during MC
searches?
SlugGo is not monte carlo, but we launch parallel lookahead
sequences, so its not really different than your threads. We ignore
the ko info in the lookaheads and
(This is all within the context of Monte Carlo.)
Is anyone storing a search DAG (as opposed to a tree) and using the
firstChild/nextSibling representation? I'm having trouble seeing how
this would work, since when you traverse children (e.g., in UCT) you
have to know which move is
DAG's have a problem with graph history, especially with super ko
considerations. Do you need the parent play for more than ko
considerations?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Drake
Sent: Thursday, December 07, 2006 5:47 PM
To:
I can avoid the ko problem by storing the depth of each node and
never creating a link from a node at depth d except to a node at
depth d+1. This prevents any cycles, at the (minimal, in my opinion)
cost of omitting transpositions of different lengths.
I need the move for two reasons:
1)
I'm pretty sure the time of this function is dominated by the call to
rand(), but it never occurred to do a table lookup for the mask,
interesting idea.
- Don
On Thu, 2006-12-07 at 22:36 +0100, Antoine de Maricourt wrote:
If this randint routine is critical, you can save some calls to rand()
By the way,
I'm amazed that the code for playing random games is fast enough that
getting random numbers is actually a bottleneck and it's worthy of a
discussion on optimization.
One of the fastest chess programs a few years ago in terms of nodes per
second was Fritz. It heavily used a common
So it's
quite possible that
this sequence dominates the call to rand().
on another note, if the only reason that you
need random numbers is to choose a number from
a list (82, or 362), and the depth is being
constrained to something reasonable, then what
you need is not a super-duper random
19 matches
Mail list logo
