On 29-okt-08, at 00:13, Don Dailey wrote:
The marker idea I call aging. I call the variable age because it
seems
to be more descriptive to me. Each playout has a different age
associated with it. The idea is used in persistent hash tables in
computer chess and I'm sure in other games
David Doshay: [EMAIL PROTECTED]:
This is wonderful news for SlugGo, but unfortunately my wife just
booked a
vacation for us at the same time. I will have to wait until next time
to be
able to attend.
That's unlucky for us.
I will plan to hold this time open next year and hope that you will
Yes. You (or, possibly an agent) will have to play by hand.
This, however, is so common in Computer Olympiad tournaments that I
guess it's not a big problem.
Hideki
terry mcintyre: [EMAIL PROTECTED]:
The protocol used is described as a modified NNGS protocol. The paragraph on
remote
Thanks for the suggestion, Mark. Below I show the exact code used (C#) and the
amount of time each version took.
Original:
for (int mv = 0; mv NNN; mv++)
{
credit[mv] = true; // initial assumption is that credit is awarded
for any move
}
double
I'm not familiar with low-level C# stuff, but I imagine the reason is
increased code size.
And I really doubt that the overflow checking for the playout ID is worth
doing. After 4 billion playouts (assuming unsigned 32 bit int) is there any
chance of an intersection not being hit once?
Well, it shows that it always pays to measure the effect of an
'optimization' instead of trusting on blind-faith. Or logic. Because
it seems very counterintuitive. I would not have been so surprised
if, as Don said, it would have been negligeable. But for it to
actually become noticeably
On Wed, 2008-10-29 at 13:49 -0400, Michael Williams wrote:
I am unable to explain the results.
It's just noise. Any code change can slightly help or hurt for no
easily explainable reason. It could be some effect on caching, the
optimizer, branch prediction, or something else. You do have a
On Wed, 2008-10-29 at 13:08 -0500, Zach Wegner wrote:
I'm not familiar with low-level C# stuff, but I imagine the reason is
increased code size.
And I really doubt that the overflow checking for the playout ID is
worth doing. After 4 billion playouts (assuming unsigned 32 bit int)
is there
Yeah, I guess doing an extra subtraction in the loop (for the comparison) is
slower than having a separate loop for initialization.
Don Dailey wrote:
On Wed, 2008-10-29 at 13:49 -0400, Michael Williams wrote:
I am unable to explain the results.
It's just noise. Any code change can
I want to add that the most efficient thing for modern processors isn't
necessarily the most efficient theoretical algorithm.Years ago for
instance hash tables were more efficient than they are today, but now
perhaps B-Tree's win for similar purposes because they are designed to
be cache
On Wed, 2008-10-29 at 14:24 -0400, Michael Williams wrote:
Yeah, I guess doing an extra subtraction in the loop (for the
comparison) is slower than having a separate loop for initialization.
This might actually be a real slowdown now that I think about it. The
initialization loop should be
I want to add that the most efficient thing for modern processors isn't
necessarily the most efficient theoretical algorithm.Years ago for
instance hash tables were more efficient than they are today, but now
perhaps B-Tree's win for similar purposes because they are designed to
be cache
On 29-okt-08, at 16:24, Don Dailey wrote:
I want to add that the most efficient thing for modern processors
isn't
necessarily the most efficient theoretical algorithm.Years ago for
instance hash tables were more efficient than they are today, but
now
perhaps B-Tree's win for similar
Here's a chance to share an amusing and illustrative anecdote.
I was working on optimizing Goodbot, a program that plays Tantrix,
and because of the nature of the game, the only way to really qualify
an improvement is to run many test games against a standard opponent.
At one point, I was
Here's a chance to share an amusing and illustrative anecdote.
I was working on optimizing Goodbot, a program that plays Tantrix,
and because of the nature of the game, the only way to really qualify
an improvement is to run many test games against a standard opponent.
At one point, I was
On Wed, 29 Oct 2008, Mark Boon wrote:
the implementation with one that clears the array instead of increasing the
marker. And I'll only have to make changes in one place instead of dozens, or
more. Not that I had this in mind when I designed it, it's just the
beneficial side-effect of OO
16 matches
Mail list logo
