Hi,
On the topic of markers, attached is what I did when a year back when
I was still interested in Go
I am not at all saying that this is the best way to do it (there is a
bit of overhead), but it is a cute trick that should bring a smile or
two.
Joel
On Thu, Oct 30, 2008 at 9:40 PM, Mark
On 30-okt-08, at 00:20, Christoph Birk wrote:
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 i
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
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
> 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 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
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
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
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
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
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
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?
___
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
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 too
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 too.
However, I seriously doubt this particular en
Some interesting ideas Michael, keep them coming.
With regards to the code-snippet you posted, this kind of
'mark-to-prevent-double-work' type of construction is very common in
computer-Go. Looping over the complete array to set the initial value
is very expensive and totally avoidable.
The same
The idea this time is to make use of your opponent's moves (as the proverb says). I tried a few different weights for the opponent move and 0.1 was the best of
the ones I tried. The win rates for the version with opponent moves versus the version without opponent moves are as follows (both versi
17 matches
Mail list logo
