1) If we're sorting bitmaps into categories (for deciding on the next
move), the sorting will be most efficient when we can ask questions with
probability of 1/2 of "true" or "false," as in playing a sort of "Twenty
Questions."
....[
These bitmaps wouldn't be necessarily maps of stones on the board,
although those would be the basic ones: They would include maps where a
1-bit indicates a complex structure built up from simpler maps by shifts &
bitwise logic. Left edge detection (applied to map 'a'), for example,
would be:
a & (a XOR (a >>))
The idea is to design a recognition test based on the board before us on
some turn... We mask out some bits of one of the bitmaps generated from
it, planning to compare future patterns to that. [A masked 'XOR' is one
way, with 'zero' indicating a perfect match of the unmasked bits.]
I was saying that in a very unbalanced bitmap, say with mostly all 0's,
any of the 1's would be more significant than a typical 0-bit. My starting
guess was that the probability of wanting to mask something out might be:
1 - r (where 'r' is the ratio of similar bits in the map)
for example with 1 bit out of 32 set we might want to mask that one out
abt 1/32 of the time, while we'd mask out any of the others roughly 31/32
of the time.]
2) But consideration '1)' says we'd like to recognize any odd map abt 1/2
the time at any one step.
So if the program is designing a rule for deciding which maps & rules to
consider next, we'd like to be testing, so much as possible, one single
bit at each step...
3) If we have 'n' bits of the same parity, there's no one probability we
can assign to all individual bits that will guarantee that only one of
them is unmasked; the probability of that happening won't go over 1/2 (for
any n > 1). But we can maximize it by making the individual probability
1/n--and not do too badly in the cases where one or more others are also
considered; indeed part of the time we definitely will want to look at
more than one bit at once (later, after we've eliminated some of the cases
in which a many-bit match would be too unlikely.)
4) So here's what I come up with: Divide the map into two sets-- x 1-bits
vs y 0-bits. Consider masking out each bit, giving this a probability of
1/x for the 1-bits and 1/y for the 0-bits.
If this gives us a map with all bits masked, repeat until we have at least
one bit for future patterns to tested-against.
Trouble is, this makes masks which test for multiple bits significantly
more likely than those which test for single bits, while I'd prefer the
opposite outcome.
Suggestions?
-----------------------------------------
This email was sent using AIS WebMail.
http://www.americanis.net/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
