Re: Sharing Secrets (was: [computer-go] Computer Go hardware)

["Nicol N. Schraudolph" <compgo@xxxxxxxxxxxxxxx>]

> I was specifically targeting (look at the title of my post) "competitors", 
> meaning people who make many tens of thousands of USD per year with their Go 
> software, like David Fotland and Michael Reiss do.
> 
> I do not think that those guys regard their trade secrets and intellectual 
> property as "kindergarten stuff". I have heard that Mick Reiss has lived off 
> his Go software for the better part of a decade. Meaning perhaps one million 
> USD income, considering the fact that he holds a dual PHD and still prefers 
> to do his own stuff.

I meant no disrespect to pros.  The appropriate forum to share "A++"
secrets for people whose livelihood depends on them, however, is a
business meeting with a lawyer on each side.  This mailing list is for
the informal sharing of ideas and info, and the best we can hope for
here is interesting and stimulating discussions.  If a pro occasionally
weighs in, that makes it all the more interesting.  Which I think is
exactly what's happening here, so I for one appreciate even the resulting
clashes of opinion.

My 2c regarding the improvement of random Zobrist keys:

1) Not all pseudo-random number generators are trustworthy for hash key
generation.  If you want to be on the safe side, use true random numbers.
On my linux box, getting them is as easy as saying "cat /dev/random".

2) True random keys are, on the average, very very good.  The probability
that two given 64-bit random values have a Hamming distance outside your
"optimal range" of 32 +/- 10 bits is (using the Gaussian approximation
to the binomial) less than 1.25%.  However:

3) Random keys, being random, have a terrible worst-case performance.
For instance, there is a very small but still non-zero probability that
you happen to generate the exact same key twice.  Therefore:

4) Checking your random key table is absolutely necessary as an insurance.
Aggressively optimizing some distance measure, on the other hand, defeats
the purpose since you're then squeezing yourself into a smaller subspace
(e.g., a set of keys with Hamming distance close to 32).  Thus:

5) If your key checking algorithm regenerates more than a few percent of
the random keys, you are bound to be reducing collisions for whatever
subset of positions you are checking (e.g., pairs of nearby stones) at
the cost of increasing them in the average case.  Depending on what you
want to use the hash for, this may or may not be appropriate - just be
aware that this is what you're doing.

Best,

- nic

-- 
    Dr. Nicol Schraudolph                      work: +61-2-612-51552
	National ICT Australia                      fax:          -58645
    RSISE, bldg. 115, room B148                home:          -51115
    Australian National University
    Canberra, ACT 0200, Australia          http://n.schraudolph.org/

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