-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 11, 2006, at 19:22 , Łukasz Lew wrote:
Soon I will publish the code on my web page.
But I don't have a web page yet. :)
The second issue is a licence.
Can I use my Go Board implementation in commercial program if I
publish it on Gnu?
If no,
I could pack all of the information into a single array. Here is one
possible scheme which fits in 32 bits and accommodates all board sizes:
3 bits to identify white/black/empty/off-board
9 bits for the hash key (the reference stone)
9 bits for pseudo liberty count
9 bits for stone count
Thank you for responding to my question, everyone.
>Nijhuis
Great! Thank you for your advice.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On 12/15/06, Don Dailey <[EMAIL PROTECTED]> wrote:
> At the time of Your post I've had it already implemented and regarded
> it like "my sweet secret" :)
I don't know how sweet this secret is, but it does help. I just
implemented it in Lazarus and I get about a 20% speedup. That's not
bad, but
On 12/15/06, Luke Gustafson <[EMAIL PROTECTED]> wrote:
Are you using the union-find algorithm with path compression for joining
strings? It's very simple and very fast.
http://en.wikipedia.org/wiki/Disjoint-set_data_structure#Disjoint-set_forests
The other main thing to consider is reducing bra
Thanks :)
I will stick to GPL and use Bazar model (The Cathedral and the Bazaar).
I will provide tarball and darcs repository :)
Best regards,
Lukasz Lew
On 12/15/06, Urban Hafner <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 11, 2006, at 19:22 , Łukasz Lew w
> I confirm branches are most costly.
> Removing 1 not needed "if" gave me speedup of 5%.
do you mean that the 'if' was never evaluated,
or that it always evaluated the same way, or
that it was handled elsewhere? i'm stunned
that a single 'if' was 5% of the execution time
of your code. it might
if (is_player (color_at[v]))
chain_at[v].find_root ()->inc_lib_cnt ();
I removed the if
chain_at[v].find_root ()->inc_lib_cnt ();
And added some code elsewhere to make it correct.
this code is executed for every neighbour intersection (v) of
intersection that just turned into empty (was captu
We are working hard to be ready on short notice, and are shooting
in the dark about how to use the extra time. So far we are not able
to bring up a SlugGo that would take advantage of that much time.
But we will keep trying and, as you said:
You can regard it as a test slow tournament.
Cheer
> if (is_player (color_at[v]))
> chain_at[v].find_root ()->inc_lib_cnt ();
>
> I removed the if
>
> chain_at[v].find_root ()->inc_lib_cnt ();
>
> And added some code elsewhere to make it correct.
so it wasn't the "is_player"?
s.
__
Do You Yaho
On 12/15/06, steve uurtamo <[EMAIL PROTECTED]> wrote:
> if (is_player (color_at[v]))
> chain_at[v].find_root ()->inc_lib_cnt ();
>
> I removed the if
>
> chain_at[v].find_root ()->inc_lib_cnt ();
>
> And added some code elsewhere to make it correct.
so it wasn't the "is_player"?
Oh, sorry I
> Oh, sorry I forgot.
>
> static bool is_player (t color) { return (color &
> (~1)) == 0; }
>
> This is 1 CC so I don't think so. :)
:)
i guess that since the entries of color_at
had to be looked up for each v (presumably),
the pred_br_eq (or whatever the x86 version
is called) instruction coul
Another report on D programming. It appears that D programs are about
1.5X slower in general - at least for what I'm doing.
At one point I reported about 7% slower, but that was a mistake on my
part.
The difference in programming effort and just plain clean code is quite
large - D was well desi
> I should be able to get close to
> 25,000 games per
> second if
> I get the 1.5 X improvement going to C. This is
> only about 3K of code
> that will
> have to be written in C, where much of the code is
> identical to C
> anyway.
is this that much easier than just starting and
finishing in C?
On 12/16/06, Don Dailey <[EMAIL PROTECTED]> wrote:
Another report on D programming. It appears that D programs are about
1.5X slower in general - at least for what I'm doing.
At one point I reported about 7% slower, but that was a mistake on my
part.
The difference in programming effort and j
On Sat, 2006-12-16 at 01:47 +0100, Łukasz Lew wrote:
> On 12/16/06, Don Dailey <[EMAIL PROTECTED]> wrote:
> > Another report on D programming. It appears that D programs are about
> > 1.5X slower in general - at least for what I'm doing.
> >
> > At one point I reported about 7% slower, but that w
On Fri, 2006-12-15 at 16:28 -0800, steve uurtamo wrote:
> > I should be able to get close to
> > 25,000 games per
> > second if
> > I get the 1.5 X improvement going to C. This is
> > only about 3K of code
> > that will
> > have to be written in C, where much of the code is
> > identical to C
>
17 matches
Mail list logo
