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
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
>c
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 we
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 sl
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 t
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 slightl
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 frie
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 r
Go81 by Tapani Raiko used decaying move weight values as part of AMAF. He
published his source code, and a paper in 2004. Both are?well worth reading.
- Dave Hillis
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mai
> 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
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 mak
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 mak
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 design
16 matches
Mail list logo
