On 5/30/07, Jacques Basaldúa <[EMAIL PROTECTED]> wrote:
Lukasz Lew wrote:
> Is libego too complicated? Do You have problems with compilation?
> Or You are not comfortable with the GNU license? Any other reason?
I only wanted to compare performance ( and see what good ideas
you had ;-) ) but could not compile libego. Neither with Microsoft
Visual Studio nor with Borland Turbo C++. I am 100% Borland
because of the ease of assembly language implementation. Borland
passes parameters in CPU registers in a documented way and has
an extremely straightforward use of local variables and record
structure from asm source code to write things easily that work
on the first run.
At least for Windows programmers, providing a solution that
compiles with major IDEs would help. I assume what you do is
"standard" in Linux, but the things the compiler did not understand
neither did I, and I could not find the time for "googleing".
"Could not compile libego" is not a very helpful error message. What
exactly did the compiler complain about? My guess is that you don't
have the required boost libraries installed.
Anyway, I think a go board system is way too important to be
universal. I already have a board system in GoKnot that surely
outperforms most of the current programs and my new board
system I call HBS (Hologram Board System) does not copy
a single line from the old one. I call it a hologram because, as
in a hologram, each part contains information about the whole
picture. In my board, each cell contains a mask of its nearest
neighbors. When you place a stone, everything is updated
by automatically written assembly language functions. These
functions do not have variables except CPU registers and the
board, do not have conditional jumps or loops, of course,
no stack frames, of course support multi-threading, etc. The
board is *never* rescanned whatever happens. Placing a
stone on a 31x31 board is not a clockcycle slower than on
a 9x9 board (these are my limits) assuming it "finds" the same
chains. Every bit of info on the board is only updated if it
may have changed and only once.
Funny that. We store 16 bits per point, where the contents of the 8
neighbours is encoded. Actually, in order to get the content of a
particular point, we ask its neighbour on the right :). John came up
with this and other ideas, like a method to detect if a string is in
atari and to find its last liberty in constant time. We don't rescan
the board either. Well, only once per simulation, but that's not in
the critical section. The only thing you are doing that we are not is
using assembly, but I'd rather keep things flexible and portable at
this point.
Oh, I would be curious to see how you remove a captured string with no loops.
With this board I will be able to try things that cannot be tried
with libego, but as Don said, "If you have a hammer, everything
looks like a nail.", for lots of methods not using shapes my board
is way too heavy, (although possibly faster than most in small
pattern modes) so I will write engines with shapes (and Statistics)
for a while.
The reason we don't use libego either is similar. We need a completely
different underlying structure to be able to pick random moves
following the distribution we want. I don't think Lukasz can do
anything to his library so it would satisfy a significant fraction of
programmers, since we all have different needs.
Álvaro.
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
