Probability of no adjacent tiles on a square grid
me13013
This question is inspired by the board game Acquire, but you don't
need to understand the game to understand this problem.
The game is played on a 9x12 grid of squares, and each player
initially "owns" 6 of those squares, assigned at random (uniform
distribution over the 108 squares). It is advantageous to own two (or
more) squares that are adjacent (horizontally or vertically, but not
diagonally).
My question is, what is the probability that none of a player's tiles
are adjacent? An answer from simulation would be OK (I'll probably do
that myself), but I'm wondering if an exact answer is feasible,
probably by making use of Burnsides lemma.
Bob H
The Qurqirish Dragon
on a 9x12 grid, there are 99 "lengthwise" adjacent pairs and 96
"widthwise" pairs, for 195 possible adjacent pairs. There are
108*107 / 2 = 5778 possible ways to choose 2 spaces, so when selecting
only two locations, there is about a 3.3% chance of having an
adjacency (or about 96.7% of not having one). Obviously, with 6
choices and only looking for 2 together, this is a much harder
problem, but for a ballpark estimate, I'd consider taking 3 pairs,
which would have about 1 - .967^3 chance, or about 10%
To find an exact value, I think it would require taking a case-by-case
listing, getting progressively harder as you add in each new location.
For example:
if the first 2 are not adjacent, they can be in one of 15
configurations:
a) both in corners: 2 ways
b) one in a corner, one on an edge, with exactly one square between
them: 8 ways
c) one in a corner, one on an edge more than one square away: 136 ways
d) both on an edge, separated by a corner: 4 ways
e) both on an edge, separated by one square: 26 ways
f) both on an edge, more than one square apart: 643 ways
g) one in a corner, one on the interior, adjacent at a corner: 4 ways
h) one in a corner, one on the interior, non-adjacent: 276 ways
i) one on an edge, one on the interior, corner-adjacent: 60 ways
j) one on an edge, one interior, one square between in a line: 38 ways
k) one on an edge adjacent to a corner, one interior more than one
away: 536 ways
l) one on an edge non-adjacent to a corner, one interior more than one
away:1716 ways
m) two interior, corner-adjacent: 108 ways
n) two interior, separated by one square in a line: 106 ways
o) two interior, separated by more than 1 square: 2078 ways
by adding these up, I seem to have double-counted about 170 pairs, but
I can't seem to find which ones they are.
Anyway, the point is that in each of these cases, you need to check
how many choices remain for the 3rd pick to be non-adjacent:
a) there are 6 prohibited spaces (the pieces, and the 4 adjacent
spaces to them): 102 choices
b) also 102 choices
c) 101 choices
d) 102
e) 101
f) 100
g) 102
h) 100
i) 101
j) 100
k) 99
l) 99
m) 100
n) 99
o) 98
I separated all the cases with like values because you'd need to have
some way of counting them. Anyway, once you add all these up (multiply
each case by the possibilities), you need to remember that you've
triple-counted every group (depending on which of the three you chose
last; the order of the first two was taken care of in the setup of the
cases.) This number, divided by 108_C_3 will get the chance of getting
3 non-adjacent squares. The cases get much more when adding the 4th,
5th and eventually 6th pieces.
I don't know of a faster algorithm, and since there are only 108C6 ~ 2
billion ways to choose the positions, I would probably say to have a
computer check them. Number the grid 1..108, using integer division
and modulus to check adjacencies, and simply run through the 6 nested
loops for the choices of positions. It shouldn't take too long on a
computer.
me13013
time. But I have nothing to compare this to. I could easily have
messed up the simulation. In the hope that someone else here knows
python and is interested, here's my simulation source code. Even if
you don't know python, you might be able to see if I've messed it up
(probably the key point is that "used" and "neighbors" are collect
(row,col) positions). I've intentionally left out any comments to
avoid them being wrong.
#!/usr/bin/env python
import sys,random
rows = 9
cols = 12
tiles = 6
numTrials = 10000
successes = 0
for trial in range(numTrials):
used = {}
neighbors = {}
isSuccess = True
for t in range(tiles):
while (True):
r = random.randint(1,rows)
c = random.randint(1,cols)
if ((r,c) not in used): break
if ((r,c) in neighbors):
isSuccess = False
break
used[(r,c)] = True
if (r > 1): neighbors[(r-1,c)] = True
if (r < rows): neighbors[(r+1,c)] = True
if (c > 1): neighbors[(r,c-1)] = True
if (c < cols): neighbors[(r,c+1)] = True
if (isSuccess): successes += 1
print "%d trials, %d successes, %.2f%%" \
% (numTrials,successes,(100.0*successes)/numTrials)
me13013
can eliminate at most four previously acceptable tiles. So it looks
like a *lower* bound (on the chance of having none adjacent) is
(108/108) * (104/107) * (100/106) * (96/105) * (92/104) * (88/103) =
63.3%
Since this lower bound is higher than what my simulation gives, I've
made a mistake in one of them (or both).
Bob H
James Dow Allen
> The game is played on a 9x12 grid of squares, and each player
>
> My question is, what is the probability that none of a player's tiles
> are adjacent?
For two tiles, it is easy to see that
the probability of a "Hit" is
p = 195 / 5778 = .03374870197300103842159916926272...
Since there are 15 pairs in a set of 6,
1 - (1-p)^15 = .402481501448745198611752774507427...
might seem a good estimate for the chance
of one or more hits in 6, but a better estimate
found in simulation
.41324
is 2.7% higher. This is because of a bias: Hits become
more likely after misses. (With 54 no-hitting tiles the
55th tile *must* hit.)
Often it's easier to calculate (or estimate) the
*expected number* of hits. The crude estimate of this
expectation for 6 tiles
15 * p = .50623052959501557632398753894...
agrees well with the result found in simulation.
> I'm wondering if an exact answer is feasible,
> probably by making use of Burnsides lemma.
IMHO, an *exact* formula will be *extremely* complicated.
I wouldn't expect Burnside's Lemma to simplify this
much if at all. (Burnside's Lemma is, I think, what I always
called Polya's counting formula but from Wikipedia
now I see the result is apparently due to Cauchy.)
James Dow Allen
The Qurqirish Dragon
Each tile actually removes at most *five* spaces - you forget that the
space the tile itself takes is not possible either. This gives you a
lower bound of:
(108/108) * (103/107) * (98/106) * (93/105) * (88/104) * (83/103) =
53.7%
and so an upper bound on having a pair is 46.3%
I also rethought my ballpark estimate and think this is probably
better:
there are 6C2 = 15 possible pairs, at about 3.3% per pair gives about
a 50% chance. This multiple counts triples, quads, &c. For triples,
there is about a 6/106 ~ 6% chance of a third appearing next to the
first two (a pair is most likely in the middle somewhere, so 6
adjacent spaces is most likely) so about a 0.18% chance overall. with
6C3=20 possibilities of 3 tiles, this is about 3.6%. a fourth tile has
at most an 8/105 , which gives about a .01% chance, and so even with
scaling for combinatorial possibilities, it is insignificant (since
this is a rough calculation anyway, anything under a whole percent is
lost in my approximations!), so there is about a 46% chance of at
least one pair.This is a lot more in line with your simulation result
(of 42%), and lies within the upper-bound calculation.
Chip Eastham
> On Oct 28, 8:20 am, me13013 <me13...@gmail.com> wrote:
[snip w apologies]
> > I'm wondering if an exact answer is feasible,
> > probably by making use of Burnsides lemma.
>
> IMHO, an *exact* formula will be *extremely* complicated.
> I wouldn't expect Burnside's Lemma to simplify this
> much if at all. (Burnside's Lemma is, I think, what I always
> called Polya's counting formula but from Wikipedia
> now I see the result is apparently due to Cauchy.)
>
> James Dow Allen
I think if we consider symmetries, etc., then
an exact count is tractable.
Consider that there are 6 tiles and 12 columns,
so at least half the columns will be empty. An
empty column insulates the left portion of the
table (if any) from the right (if any). So the
problem can be reduced to considerations of a
fewer number of adjacent nonempty columns.
The eleven unordered partitions of 6 are these:
6, 5+1, 4+2, 4+1+1, 3+3, 3+2+1, 3+1+1+1,
2+2+2, 2+2+1+1, 2+1+1+1+1, 1+1+1+1+1+1
Treating these summands as column tile counts,
we see that the first two cases do not allow
avoiding adjacent tiles (since a column only
holds nine). Each remaining case gives rise
to a certain number of subcases as the counts
are mapped to specific columns, among which
there are a number of equivalences according
to the adjacency symmetries of the results.
EX. (4+2) Subcase (a): two nonempty columns
are adjacent, which occurs 11*2 = 22 ways (if
we account for which column has more tiles).
Among the fifteen ways that 4 tiles can be
nonadjacent in the column with more tiles,
one way has five single-tile gaps, eight ways
have three single-tile gaps and one double gap,
three ways have two single-tile gaps and one
triple gap, and three ways have one single-tile
gap and two double gaps. Accordingly the ways
to place two nonadjacent tiles in other column
will be respectively 10, 9, 8, and 8, giving a
combined count of: 22 * (10 + 8*9 + 3*8 + 3*8)
or 2860. Subcase (b) the two nonempty columns
are not adjacent, which occurs (C(12,2) - 11)*2
= 110 ways (again accounting for which column
has more tiles). Since the columns aren't
adjacent, for each possibility we multiply the
ways of arranging four nonadjacent tiles in one
column times the arrangments of two nonadjacent
tiles in the other column, or 15 * (C(9,2) - 8)
which is 15 * 28 = 420. Accordingly the count
overall for this subcase is 110 * 420 = 46200.
TOTAL (4+2) COUNT: 2860 + 46200 = 49060.
regards, chip
me13013
>> Walking through the choices as each tile is "chosen", each new tile
>> can eliminate at most four previously acceptable tiles. So it looks
>> like a *lower* bound (on the chance of having none adjacent) is
>> (108/108) * (104/107) * (100/106) * (96/105) * (92/104) * (88/103) =
>> 63.3%
>
>> Since this lower bound is higher than what my simulation gives, I've
>> made a mistake in one of them (or both).
and The Qurqirish Dragon replied:
> Each tile actually removes at most *five* spaces - you forget that the
> space the tile itself takes is not possible either. This gives you a
> lower bound of:
> (108/108) * (103/107) * (98/106) * (93/105) * (88/104) * (83/103) =
> 53.7%
> and so an upper bound on having a pair is 46.3%
Thanks!
me13013
> The game is played on a 9x12 grid of squares, and each player
> distribution over the 108 squares). It is advantageous to own two (or
> more) squares that are adjacent (horizontally or vertically, but not
> diagonally).
>
> are adjacent?
I had one of those aha! moments we hear about as I was driving to work
this morning. The relatively simple program (in python) I've appended
computes this in less than a second. I'm failry confident that the
number of ways to put down 6 non-adjacent tiles is 1,122,815,994, or
58.7%.
The key insight is that I can consider each vertical slice (a single
column) of the board in succession. There are only 89 different
configurations of 9-row slices that avoid adjacent tiles (that could
be reduced to 51 by symmetry but the program is so fast I didn't
bother). When I consider the second column, I only need to consider
valid slices that do not have any tiles in common with the first
slice. Representing a slice as bits in an integer, the "in common"
operation is a simple bitwise logical and.
So it just becomes a fairly simple counting recurrence (simple from a
computational viewpoint), tracking all the viable states, where a
state is the number of tiles that have been placed and the slice for
the most recent column. A further improvement only tracks those
states that use no more than 6 tiles. After reaching the final column
we can just sum over the states that have exactly 6 tiles.
The program also gives the same answer if I flip the board to 9
columns and 12 rows, though it is a little slower.
Bob H
#!/usr/bin/env python
import sys
R = 9 # number of rows
C = 12 # number of columns
T = 6 # number of tiles
def binary_string(v):
return "".join([str((v >> i) & 1) for i in range(R-1,-1,-1)])
assert (len(sys.argv) == 1)
# create a list of possible slices that are without adjacent tiles
# slices are bits packed in an integer (a 1 means a tile occupies
that
# .. position)
# okSlices maps a valid slice to number of tiles in that slice
okSlices = {0:0, 1:1} # okSlices maps a valid slice to number of
tiles in that slice
sliceLimit = 2
for row in range(2,R+1):
shortSllices = [s for s in okSlices]
for shorterSlice in shortSllices:
if (shorterSlice & (sliceLimit>>1) != 0):
continue # (the new tile would create vertical
adjacency)
if (okSlices[shorterSlice] == T):
continue # (can't use any more tiles)
slice = sliceLimit + shorterSlice
okSlices[slice] = 1 + okSlices[shorterSlice]
sliceLimit *= 2
#for s in okSlices:
# print "okSlices[%s] = %d" % (binary_string(s),okSlices[s])
# 'compute' the possible states for the first column (these just the
valid
# slices)
# states and newStates map reachable (s,t) states to the number of
ways of
# .. acheiving that state; s is a slice and t is the number of
tiles used
# .. including all previous columns
states = {}
for s in okSlices:
states[(s,okSlices[s])] = 1
# advance across the columns, counting the number of ways to achieve
each state
for c in range(2,C+1):
newStates = {}
for (s,t) in states:
w = states[(s,t)]
for v in okSlices:
if (s&v != 0):
continue # (one of the tiles creates horizontal
adjacency)
newT = t + okSlices[v]
if (newT > T):
continue # (would use too many tiles)
if ((v,newT) not in newStates): newStates[(v,newT)] = w
else: newStates[(v,newT)] += w
states = newStates
#for (s,t) in states:
# w = states[(s,t)]
# print "%d columns, %s using %d tiles: %d ways" %
(c,binary_string(s),t,w)
#print
ways = sum([states[(s,t)] for (s,t) in states if (t == T)])
print "%d" % ways
The Qurqirish Dragon
The 5-1 case can be done, even if the columns are adjacent. Note that
in a column of 9, placing a tile in the odd-numbered positions will
get you 5 tiles successfully placed.
This is a much better tactic than I had done (considering the whole
board and adding one tile at a time) I think there will be many fewer
cases. Combining this with the "build from one side" tactic that
me13013 put in his reply might speed this even more.
Old Earl
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
I ran a quick simulation three times in succession, and counted the
number of times
I found 0, 1 ,2,... hits in a give test. The results were:
0,587000
1,329346
2,74985
3,8012
4,618
5,39
0,586904
1,329222
2,75301
3,7925
4,603
5,43
6,2
0,586644
1,329266
2,75418
3,8019
4,610
5,41
6,2
Chip Eastham
> The 5-1 case can be done, even if the columns
> are adjacent. Note that in a column of 9,
> placing a tile in the odd-numbered positions will
> get you 5 tiles successfully placed.
Thanks, Q-Dragon. I've incorporated that case
into my summary of partial results below.
The cases (unordered partitions of 6) are shown
as sums whose terms are nonzero column sums.
Subcases refine these by specifying adjacencies
among these column sums, indicated by commas (,)
for adjacent and semicolons (;) for nonadjacent
columns. A component of adjacent column sums is
called a "block".
When all entries are filled in, the total number
of ways to place six tiles on the 9x12 grid with
no two tiles adjacent will be the sum over the
products of the "horizontal" (_H_) and "vertical"
(_V_) numbers of each subcase.
There's a helpful "check" on horizontal counts
of subcases corresponding to a case, which must
add up to the number of ways that prescribed
column sums can be assigned to the 12 columns
(a simple multinomial combination). Vertical
counts are generally easy (products of counts
for blocks), but could use an independent eye
in checking. E.g. I may have put numbers on
the wrong line in the table!
The 22 solutions of a (4,2) block were counted
earlier. Modulo some easy observations, counts
are still needed only for these blocks:
(3,3), (3,2), (2,2), (2,2,2), (3,1,2), (2,1,2),
(2,1,2,1), and (2,1,1,2).
I'll post separately the formulas/tricks that
underlie the summarized results. All but four
cases are complete:
(3+3), (3+2+1), (2+2+2), (2+2+1+1)
Best viewed in fixed-width font...
regards, chip
Case/Subcase _H_ _V_
(5+1): 132 (2 subcases)
(5;1) 110 9
(5,1) 22 4
(4+2): 132 (2 subcases)
(4;2) 110 420
(4,2) 22 130
(4+1+1): 660 (5 subcases)
(4;1;1) 360 1215
(4;1,1) 90 1080
(4,1;1) 180 675
(4,1,1) 20 600
(1,4,1) 10 375
(3+3): 66 (2 subcases)
(3;3) 55 1225
(3,3) 11 ?
(3+2+1): 1320 (7 subcases)
(3;2;1) 720 8820
(3;2,1) 180 6860
(3,2;1) 180 ?
(3,1;2) 180 5880
(3,2,1) 20 ?
(3,1,2) 20 ?
(2,3,1) 20 ?
(3+1+1+1): 1980 (9 subcases)
(3;1;1;1) 504 25515
(3;1,1;1) 504 22680
(3;1,1,1) 72 20160
(3,1;1;1) 504 17010
(3,1;1,1) 144 15120
(3,1,1;1) 144 15120
(1,3,1;1) 72 11340
(3,1,1,1) 18 13440
(1,3,1,1) 18 10080
(2+2+2): 220 (3 subcases)
(2;2;2) 120 21952
(2,2;2) 90 ?
(2,2,2) 10 ?
(2+2+1+1): 2970 (14 subcases)
(2;2;1;1) 756 63504
(2;2;1,1) 252 56448
(2,1;2;1) 1008 49392
(2,1;2,1) 144 38416
(2,2;1;1) 252 ?
(2,2;1,1) 72 ?
(2,1,1;2) 144 43904
(1,2,1;2) 72 38416
(2,2,1;1) 144 ?
(2,1,2;1) 72 ?
(2,2,1,1) 18 ?
(2,1,2,1) 18 ?
(2,1,1,2) 9 ?
(1,2,2,1) 9 ?
(2+1+1+1+1): 3960 (17 subcases)
(2;1;1;1;1) 280 183708
(2;1,1;1;1) 840 163296
(2;1,1,1;1) 336 145152
(2;1,1;1,1) 168 145152
(2;1,1,1,1) 56 129024
(2,1;1;1;1) 560 142884
(2,1;1,1;1) 672 127008
(2,1;1,1,1) 112 112896
(2,1,1;1;1) 336 127008
(2,1,1;1,1) 112 112896
(1,2,1;1;1) 168 111132
(1,2,1;1,1) 56 98784
(2,1,1,1;1) 112 112896
(1,2,1,1;1) 112 98784
(2,1,1,1,1) 16 100352
(1,2,1,1,1) 16 87808
(1,1,2,1,1) 8 87808
(1+1+1+1+1+1): 924 (11 subcases)
(1;1;1;1;1;1) 7 531441
(1,1;1;1;1;1) 105 472392
(1,1;1,1;1;1) 210 419904
(1,1;1,1;1,1) 35 373248
(1,1,1;1;1;1) 140 419904
(1,1,1;1,1;1) 210 373248
(1,1,1;1,1,1) 21 331776
(1,1,1,1;1;1) 105 373248
(1,1,1,1;1,1) 42 331776
(1,1,1,1,1;1) 42 331776
(1,1,1,1,1,1) 7 294912
me13013
> Modulo some easy observations, counts
> are still needed only for these blocks:
>
> (3,3), (3,2), (2,2), (2,2,2), (3,1,2), (2,1,2),
> (2,1,2,1), and (2,1,1,2).
Filling in values (using a modification of the program I posted
earlier). I've indicated the new values with angle brackets. I have
also included other counts that I've verified.
Bob H
(4,2) 22 130
(3,3) 11 <340>
(3,2;1) 180 <425*9 = 3825>
(3,2,1) 20 <2975>
(3,1,2) 20 <4580>
(2,3,1) 20 <2550>
(2;2;2) 120 21952
(2,2;2) 90 <462*28 = 12936>
(2,2,2) 10 <7632>
(1,1;1,1;1,1) 35 373248
(2,2;1;1) 252 <462*9*9 = 37422>
(2,2;1,1) 72 <462*72 = 33264>
(2,1,1;2) 144 43904
(2,2,1;1) 144 <3234*9 = 29106>
(2,1,2;1) 72 <4270*9 = 38430>
(2,2,1,1) 18 <25872>
(2,1,2,1) 18 <29890>
(2,1,1,2) 9 <34146>
(1,2,2,1) 9 <22638>
me13013
sum of H*V matches the answer I got earlier, 1,122,815,994. I'm now
even more confident that is the correct answer.
Bob H
Case/Subcase_________H________V__________H*V__
(5+1)_______________132 (2_subcases)__________
___(5;1)____________110________9_________990__
___(5,1)_____________22________4__________88__
(4+2)_____________ _132 (2_subcases)__________
___(4;2)____________110______420_______46200__
___(4,2)_____________22______130________2860__
(4+1+1)___________ _660_(5_subcases)__________
___(4;1;1)__________360_____1215______437400__
___(4;1,1)___________90_____1080_______97200__
___(4,1;1)__________180______675______121500__
___(4,1,1)___________20______600_______12000__
___(1,4,1)___________10______375________3750__
(3+3)_____________ _ 66_(2_subcases)__________
___(3;3)_____________55_____1225_______67375__
___(3,3)_____________11______340________3740__
(3+2+1)___________ 1320_(7_subcases)__________
___(3;2;1)__________720_____8820_____6350400__
___(3;2,1)__________180_____6860_____1234800__
___(3,2;1)__________180_____3825______688500__
___(3,1;2)__________180_____5880_____1058400__
___(3,2,1)___________20_____2975_______59500__
___(3,1,2)___________20_____4580_______91600__
___(2,3,1)___________20_____2550_______51000__
(3+1+1+1)_________ 1980_(9_subcases)__________
___(3;1;1;1)________504____25515____12859560__
___(3;1,1;1)________504____22680____11430720__
___(3;1,1,1)_________72____20160_____1451520__
___(3,1;1;1)________504____17010_____8573040__
___(3,1;1,1)________144____15120_____2177280__
___(3,1,1;1)________144____15120_____2177280__
___(1,3,1;1)_________72____11340______816480__
___(3,1,1,1)_________18____13440______241920__
___(1,3,1,1)_________18____10080______181440__
(2+2+2)___________ _220 (3_subcases)__________
___(2;2;2)__________120____21952_____2634240__
___(2,2;2)___________90____12936_____1164240__
___(2,2,2)___________10_____7632_______76320__
(2+2+1+1)_________ 2970_(14_subcases)_________
___(2;2;1;1)________756____63504____48009024__
___(2;2;1,1)________252____56448____14224896__
___(2,1;2;1)_______1008____49392____49787136__
___(2,1;2,1)________144____38416_____5531904__
___(2,2;1;1)________252____37422_____9430344__
___(2,2;1,1)_________72____33264_____2395008__
___(2,1,1;2)________144____43904_____6322176__
___(1,2,1;2)_________72____38416_____2765952__
___(2,2,1;1)________144____29106_____4191264__
___(2,1,2;1)_________72____38430_____2766960__
___(2,2,1,1)_________18____25872______465696__
___(2,1,2,1)_________18____29890______538020__
___(2,1,1,2)__________9____34146______307314__
___(1,2,2,1)__________9____22638______203742__
(2+1+1+1+1)________3960_(17_subcases)_________
___(2;1;1;1;1)______280___183708____51438240__
___(2;1,1;1;1)______840___163296___137168640__
___(2;1,1,1;1)______336___145152____48771072__
___(2;1,1;1,1)______168___145152____24385536__
___(2;1,1,1,1)_______56___129024_____7225344__
___(2,1;1;1;1)______560___142884____80015040__
___(2,1;1,1;1)______672___127008____85349376__
___(2,1;1,1,1)______112___112896____12644352__
___(2,1,1;1;1)______336___127008____42674688__
___(2,1,1;1,1)______112___112896____12644352__
___(1,2,1;1;1)______168___111132____18670176__
___(1,2,1;1,1)_______56____98784_____5531904__
___(2,1,1,1;1)______112___112896____12644352__
___(1,2,1,1;1)______112____98784____11063808__
___(2,1,1,1,1)_______16___100352_____1605632__
___(1,2,1,1,1)_______16____87808_____1404928__
___(1,1,2,1,1)________8____87808______702464__
(1+1+1+1+1+1)_____ _924_(11_subcases)_________
___(1;1;1;1;1;1)______7___531441_____3720087__
___(1,1;1;1;1;1)____105___472392____49601160__
___(1,1;1,1;1;1)____210___419904____88179840__
___(1,1;1,1;1,1)_____35___373248____13063680__
___(1,1,1;1;1;1)____140___419904____58786560__
___(1,1,1;1,1;1)____210___373248____78382080__
___(1,1,1;1,1,1)_____21___331776_____6967296__
___(1,1,1,1;1;1)____105___373248____39191040__
___(1,1,1,1;1,1)_____42___331776____13934592__
___(1,1,1,1,1;1)_____42___331776____13934592__
___(1,1,1,1,1,1)______7___294912_____2064384__
Chip Eastham
Nice work, Bob! I get the same counts by pencil
and paper calculations. The (2,2,2) subcase was
by far the most involved, requiring sub-subcases.
regards, chip
me13013
> Nice work, Bob! I get the same counts by pencil
> and paper calculations. The (2,2,2) subcase was
> by far the most involved, requiring sub-subcases.
You did the work. I just used my program to fill in a couple values.
Bob H