### Re: [computer-go] Zobrist hashing with easy transformation comparison

On 2/10/07, Łukasz Lew [EMAIL PROTECTED] wrote:

On 2/10/07, Antoine de Maricourt [EMAIL PROTECTED] wrote:
If there is strong interest, I can post the scheme.

Since Antoine claims there is only on solution I might as well post mine ;-)

mirroring: [abcdefgh] - [hgfedcba]
rotation: [abcdefgh] - [cdefghab]

This scheme follows trivially from dividing the square in 8 triangular
regions, and assigning each a letter. If you want to include color
symmetry you need to change the operators (xor doesn't work any more)
or increase the number of segments.

Erik
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

### Re: [computer-go] Zobrist hashing with easy transformation comparison

As Antoine de Maricourt says, this weakens the key.
I think it is a serious problem and it is a dangerous answer to a small
question. I compute hashes and patterns for database lookup eight
at a time, which is faster (much more optimizable) than one
after the other. Then I also use the smallest as the canonical
and simply discard the others. Since database lookup is so fast
that's not a problem at all. Other situations where hashes are needed
do not require verifying rotations, so the advantage of Nick's idea
is very small (IMO).

But the question is: Does someone do the opposite, i.e. playing
with the hash values to make then *stronger*? Even with 32 bit
hashes, triple ko can be detected with probability = 1 for any
sequence of alternating BWBW or WBWB of length less than 8.
(Tripe Ko is a sequence of length 6) I don't know if that is published.
In fact, unless you have a computer allowing to store a 2^64 bit
table, strong collision analysis can only be done for 32 bit hashes
(With my hardware where I can manage a 4 gigabit table decently.
Checking that all 4x4x2(colors) squares in a 19x19 array form a
base and replacing the invalid hashes as needed takes about 15
hours on a P4D at 3.4GHz) Of course, once you have a strong
32 bit hash set you can fill the higher 32 bits with random bits
to have a 64 bit set.

Jacques.

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

### Re: [computer-go] Serializing a very large object in Java

Peter Drake wrote (3 times):

. . .  and 91.449 bytes later  . . .
... (ObjectOutputStream.java:1369)

I studied the log file in depth and the problem is  . . .

. . . (you guessed) using Java  ;-)

Jacques.

BTW. I store this list. If you need your log file in the future, contact
me cos I have 3 copies. ;-)

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

### Re: [computer-go] Zobrist hashing with easy transformation comparison

On 2/10/07, Jacques Basaldúa [EMAIL PROTECTED] wrote:
snip

But the question is: Does someone do the opposite, i.e. playing
with the hash values to make then *stronger*?

And then we get another small questions with a dangerous answer...

Just search the archive for BCH construction.

E.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

### Re: [computer-go] Paper presents results on proximity heuristic

This was not tested in any formal way, but including the book does seem
to increase the chance that the program will open with E5 (which I
believe is the correct opening move on 9x9) ...

Just a side note, as I've spent a lot of time studying high-level 9x9
games. I've seen strong players win against other strong players
starting with any of the 6 plausible openings moves: 5,5;  5,4;  4,4;
5,3; 3,4; 3,3. When the pros switched form 5.5 to 6.5pt komi there were
more 4,4 openings played and fewer 5,5 openings. But this does not mean
that 4,4 is better than 5,5.

Anyway, my point was, it would be dangerous to think your program is
playing better because it starts choosing 5,5 more often. However,
choosing one of those six moves more than a first move on the 1st or 2nd
lines could probably be considered an improvement.

Darren

___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/