Hi Erik
And what distinguishes database look up from things like transposition
table look up? Why wouldn't one use database look up during tree
search?
The interest in rotation/mirror. In database search, what is good for
a position is good for the mirror/rotation. In tree search, rotation
of the full board does not happen, and if it does (in a very simple
position) its pointless to detect because it is not the same position.
4. The analysis based on uniform distributions are
> fundamentally flawed because the move sequences are not
> random in go, particularly, the BWBWBW sequence can only
> be avoided by pass moves which do not occur in real games
> globally before the end of the game.
So?
Of course. The most important superko that really happens in strong
games is triple ko. Detecting triple ko with probability=1 and a 32
bit hash is not a trivial question. And it requires B keys to have
some difference with W keys. Note that to be _sure_ that a move is
legal, you only have to check 6x32 bit keys. That would be impossible
if the hashes were pure random. You simply cannot control any
combination of 19x19x2=722 hashes of length 6, but you can control
BWBWBW even of length 7. Since the test is faster than any another and
is also, unlike the others, with error probability=0 it is simply the
best. Of course, it does not consider board repetitions of longer
cycles. I have searched for (the possibility of) such cycles in my 50K
games database and did not find any. I would love to see a game where
both players are at least shodan, in which a superko other than triple
ko limits the legal options. If someone has such a game, please post it.
I'm speculating here because I seem to be missing some context, but
AFAICS almost any Go-specific application will have more legal moves
hash keys than bits for the hash.
Of course. That's because full global search is intractable. But local
search with 16 empty cells (which can be either B or W, and therefore
you only have 32 keys) is not. That's what I mean when I say "when it
makes sense". Again, I do use 64 bit hashes.
And my favorite:
if the hash calculation is a major factor in the performance of
your program, you should seriously consider adding some knowledge.
We have seen this when talking about programming language. Each time
someone cares about details and builds programs that are optimized
from the day of their birth, they are:
a. Dirty and hard to maintain. (IMO only patched programs are
hard to maintain and they are patched because important issues
were thought too late.)
b. Caring about "stupid" issues == ignoring Big Algorithmic
Improvements. (IMO If you don't really care about details you
don't really control the "big picture". And more important, you
only have to do it once, if you do it well. That will give you a
lot of time for thinking about algorithms.)
Jacques.
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
