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

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.


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.)


computer-go mailing list

Reply via email to