Author: Andrew Dados
Date: 14:27:24 02/25/99
Go up one level in this thread
On February 25, 1999 at 15:16:45, Don Dailey wrote:
>Ok, I took a few minutes to look at the problem and it was in
>my hamming distance function. I was counting the number of
>bits in common, so really my distance function was a closeness
>function! So the bug was in my code. It was also the very
>first thing I looked at, since I had a hunch.
>
>I ran your code with my random number generator and it now
>we completely match if I turn off your optimization of taking
>the compliment of good numbers. That optimization is pretty
>effective and makes it find numbers much more quickly.
>
>It looks like 32 bits is pretty tough to achieve, probably
>not even feasible. Any idea how to compute the maximum distance
>possible in a given size table of 64 bit numbers?
>
>- Don
>
>
I ran some testing for hamming distance of 25 with a very fast function
generating required numbers: first 20 bits random (starting at random location,
'next' is then next mod 64), then each next bit was choosen to increase minimal
distance for all previous numbers in table...If number did not fit I then
flipped each of initial 20 bits and tried that one. I was able to generate 410
numbers in 2 minutes, 420 in 5 and 440 in 30... I strongly suspect there is a
limit of some 512 in a case of hamming distance 25 for 64 bits. Anyone can come
up with formula for that? (It took 30 sec to get 768 numbers with distance of
24 on amd K6 233 with that algorithm).
-Andrew-
[snip]
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.