Hi, here is an explanation along with the code:
First, my eyechecking is very fast:
bool is_eyelike (color::t color, v::t v) {
int diag_color_cnt[color::cnt];
assertc (board_ac, is_ready ());
if (((nbr_player_cnt[v] >> (color * 4)) & 0xf) != 4) {
assertc (board_ac && slow_ac, sl
Lukasz,
I have an implementation of your circular list in place, but I'm having
a difficult time dealing with the single point eyes which my program
does not allow as well as suicide which I don't allow either.
I built a little circular list and I put captured points back into the
circular
list
I never finished this email.
I'm wondering how you handle the eye thing. I don't allow the program
to move to a single point eye but you said nothing about this. But if
you skip over that point now it might become legal later.
Those eyes must be put back into the pool. To get truly rando
Łukasz Lew,
I'm trying to implement this now. I think I see why our average moves
per game do not match.
First of all, suicide is illegal in my program, I do not allow it.
On Thu, 2006-12-07 at 16:05 +0100, Łukasz Lew wrote:
> I really do randomize a whole vector of empty intersections befor
On 12/7/06, Don Dailey <[EMAIL PROTECTED]> wrote:
Probably one of these would suffice:
http://www.lns.cornell.edu/spr/1999-01/msg0014148.html
- Don
Wow, very cool page on fast RNGs. Thanks.
___
computer-go mailing list
computer-go@computer-
Yes, there are fast little generators that would probably serve our
purposes, however I don't want to have to spend too much time checking
them out so I found one that was known to be quite fast, the Mersenne
Twister.
But what you say is now a consideration based on what I've learned about
the spe
> 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 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 te
I will test it with a table derived mask and see what happens. I would
like the table to be large enough to encompass 19x19 GO too, but I'll
test it with a small table first.
- Don
On Fri, 2006-12-08 at 00:39 +0100, Antoine de Maricourt wrote:
> Last time I checked MT was under 20cc per call (I
Last time I checked MT was under 20cc per call (I assume it's inlined).
On a P4, the shift operator is supposed to have a 4 cc latency. The
dependency chain to get the mask yields to 25 cc latency before the mask
can be used (4 per shift + 1 for OR) * 5. So it's quite possible that
this sequenc
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()
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 >>=
In fact, I just wrapped this up into my Mersenne twister code - randInt
is now built in to the library and I eliminated the function call
overhead of calling rand() (or the mersenne equivalent.) Probably won't
make a noticeable difference, but since I'm porting it to D anyway, I
might as well fix
On Thu, 2006-12-07 at 16:05 +0100, Łukasz Lew wrote:
> ii = pm::rand () % empty_v_cnt; // TODO improve speed "%"
Try this, I think it could be faster, not sure, but has the advantage
that it's slightly more correct.
// returns an integer between 0 and n-1 inclusive
//
unsigned lon
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.
- D
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 = pm::
On Mon, 2006-12-04 at 18:32 +0100, Łukasz Lew wrote:
> I deal with eyes by randomizing list of empty intersections before the
> playout, and while searching non-eye I go through them in circular
> manner.
What do you mean by circular and what does this have to do with eyes?
I'm looking to speed m
On 12/4/06, Peter Drake <[EMAIL PROTECTED]> wrote:
It's not clear whether this is faster. Determining that a move is
illegal because the point is occupied is very fast; determining that
a move IS legal (i.e., not a suicide or ko violation) is the slow
part, and I avoid that by taking the first le
It's not clear whether this is faster. Determining that a move is
illegal because the point is occupied is very fast; determining that
a move IS legal (i.e., not a suicide or ko violation) is the slow
part, and I avoid that by taking the first legal move I find. (Of
course, once all moves h
In the Orego paper the problem of selecting a move when the board is filled
with stones is mentioned. Orego uses a sort of double-hashing scheme.
But isn't it trivial to keep a list of empty intersections?
Before the MC-run is started, one builds up this list. If a stone is placed
now on the boa
20 matches
Mail list logo
