On Nov 16, 2007 10:44 PM, Imran Hendley <[EMAIL PROTECTED]> wrote: > On Nov 16, 2007 6:38 PM, Chris Fant <[EMAIL PROTECTED]> wrote: > > > > > Neat. Was the 15-bit version for 81 values or 361? At the risk of > > > > > putting my foot in my mouth, I don't think there exist 361 15-bit > > > > > numbers that satisfy minimum requirements (if the floating-point > > > > > average of any four code values is a code value, then the four code > > > > > values are identical). > > > > > > > > It was 361 values. So either you are wrong or I have a bug. I > > > > probably have a bug. Here's the list. If it violates the rules, > > > > please let me know. > > > > > > Yep, I think I had a bug. I just removed an optimization that I > > > thought was valid and now I'm getting smaller lists. So I guess it > > > was not valid. Let me see how small I can get the numbers without > > > that optimization... > > > > > > > Turns out that wasn't the problem. The actual bug was quite > > laughable. I won't get into it. But I should have been more > > thorough. Now that it's fixed, yeah, you can't do much with 15 bits. > > Best I can do now is 30 bits (for 361 values): > > Shouldn't we be taking John's advice and only looking for 19 values? > He said we can have a separate sum for x and y coordinates.
If a better method is available, absolutely. All of this was just a reaction to a particular method previously presented. We can enjoy even if it doesn't lead to the optimal Go entity. _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
