## Su-Doku's maths

Everything about Sudoku that doesn't fit in one of the other sections
The kjell b(n,m) estimate and the related patmax b(k) estimates apply to rectangular nxm (row x cols) or square kxk blocks. Application to a 1x1 block is only valid for a 1x1 grid (latin or sudoku), which, as recently stated, is 'as accurate as it is useless' (nice words )

A latin square is a 'degenerate' form of sudoku with 1xc or rx1 block dimensions and blocks coincident with the rows or columns. Applying the b(n,m) estimates yields
kjellfp wrote: For nxn latin squares, the estimate is

N(n,1) = b(n,1)^1 * b(1,n)^n / n!^n.

Now, b(1,n) is n! and b(n,1) is the number of nxn latin squares.

{--Ignore: wrong usage.. edit 12/13/05
I don't follow the 'b(n,1) = number of latin squares logic'. From the original b(n,m) description
{--
This is how: Let X be the space of (nm)x(nm)-grids built by legal sudoku bands, but with no attention put on wether the columns follow the rules of Sudoku. The size of X is b(n,m)^m. Let also Y be the set of grids built by legal stacks with no attention put on the rows, #Y is then b(m,n)^n.
so the first b(n,m) argument (n) is the row size, and the second (m) is the column size, which are associated with the number of (^n) stacks and (^m) bands respectively.

AFAI can see, applying these description to a latin square gives:
b(n,1) is the number of permutations for a stack or column
b(1,n) the number for a band or row
b(1,n) = b(n,1) = n!, yielding an estimate
N (latin nxn) = n!^1 * n!^n / n!^n = n!
which is obviously bad.

I believe the error % is related to the deviation from the symmetry of a square block which has r=c = N(bands) = N(stacks). As the shape of the block diverges from square, N(bands) diverges from N(stacks) which degrades the cross product of the band and stack estimates. The failure for latin squares is the extreme example for the divergence of the exponential (^n, ^m) factors. An increase in grid size (nxm) probably magnifies the error.
end ignore --}

Using:
Let b(r,c) be the number of ways to create the bands of rxc boxes (that is r rows, c columns in each box, r boxes in a band of size rx(c*r).
Yields for a latin square
b(1,n) the number of permutations for a band = row = n!
b(n,1) has 'band' size = nx1*n = nxn, to be filled with boxes=cols, consistent with the latin square constraints, i.e. b(n,1)= N-latin-square :: NLS(n)
Giving
N (latin nxn) = NLS(n)^1 * n!^n / n!^n = NLS(n)
(as kjell stated..)
Last edited by LarryLACa on Tue Dec 13, 2005 7:59 pm, edited 1 time in total.
LarryLACa

Posts: 32
Joined: 24 August 2005

LarryLACa wrote:b(n,1) is the number of permutations for a stack or column
b(1,n) the number for a band or row

You're right about b(1,n), but not on b(n,1) which is the number of ways to place nx1-blocks on a band such that the elements on each column (=block) and each row are different. In other words, the number of nxn latin squares.
kjellfp

Posts: 140
Joined: 04 October 2005

OK, finally got it. I (wrongly) thought for rx1 and cx1 boxes, the band (or chute or stack) degenerates to the box. Wrong! Let me paraphase the original Kjell definition (substituting r,c for n,m and citing the band size) to confirm the usage:
Let b(r,c) be the number of ways to create the bands of rxc boxes (that is r rows, c columns in each box, r boxes in a band of size rx(c*r).

From which follows for latin squares
b(r,1) be the number of ways to create the bands of rx1 boxes (that is n rows, 1 columns in each box, r boxes in a band of size rxr).
i.e. = N(latin square) restated

I don't think this is the usage applied by tinfoil (Kevin) originally for estimating the total N from the stack estimates, but this definitely works better. Progress!

I think my equivalence transform for mapping PatMax b(k) to KJell b(n,m) still holds. I'll edit my last two posts accordingly.
Last edited by LarryLACa on Tue Dec 13, 2005 8:02 pm, edited 1 time in total.
LarryLACa

Posts: 32
Joined: 24 August 2005

### Re: estimate for 4x4

kjellfp, responding to PatmaxDaddy, wrote:Btw. you should be credited for the number of legal bands in 4x4-sudoku in the Wikipedia M.o.S-page, though you didn't spell it out. It's just 16!*b(4) = 973038982740573238251518542982676480000
I've confirmed this number.

Further calculation easily (but pointlessly, lacking analogues for stacks) gives:
• 4x5 bands: 20! * 5!^12 * 879491145024
• 4x6 bands: 24! * 6!^12 * 677542845061056
• 4x7 bands: 28! * 7!^12 * 563690747238465024
I've added these to Wikipedia's M.o.S. page, along with kjellfp's generic 3xC formula.
Red Ed

Posts: 633
Joined: 06 June 2005

In thinking about the 4x3 counting problem I realized that I was doing some unnecessary work in my 3x3 program, so I fixed it and the new times are
Code: Select all
`Band Counter   2.9Permutations   5.3Band 1         0.5Gangsters      4.0Gang lists     0.4Gang counts   10.2Band counts    2.2Grid count    24.6Overhead       0.1Total         50.2`
I apologize if everyone is now bored with all these timing results.

Posts: 63
Joined: 18 October 2005

LarryLACa wrote:I think my equivalence transform for mapping PatMax b(k) to KJell b(n,m) still holds.

Indeed. My formula was meant to be a generalization of PatmaxDaddy's.
kjellfp

Posts: 140
Joined: 04 October 2005

### Preserve for posterity

kjellfp wrote:Indeed. My formula was meant to be a generalization of PatmaxDaddy's.
Of course. You said as much in you're original post, and the conection was 'intuitively obvious' (for some). Just my penchant for overstating the obvious, and an attempt to preserve for posterity how we got from A to B when we look back at these posts 6 months from now.
LarryLACa

Posts: 32
Joined: 24 August 2005

### Observations on estimating

Observations to drawn from the b(n,m) and b(k) based estimates

1) It is ‘simpler’ to estimate square sudoku than rectangular sudoku, since you only need a single band enumeration. (for rectangular b(n,m) estimates we need both band and stack enumerations)

2) the estimate %error is (probably, still unconfirmed) better for square sudoku than rectangular sudoku.

In terms of pushing the estimating envelope, it may be expedient to start thinking about the 5x5 and 6x6 cases.

3) The challenge in band estimating is in the non-terminal (aka middle) blocks. The first and last blocks are simple, the work is in the ‘middle’. Kjell's Nx3 form is an elegant expression of this principle. For the 3xC case, there is only 1 non-terminal block, whose N can be expressed using an M = n choose x derivation see M.o.S Band Enums

4) Guenter, Ed, Kjell, Bill: When you compute the permutations for the 4x middle boxes are you using an (optimized) recursive descent algorithm, T-Classes, or a partitioning expression (like Bell numbers)?. (Obviously I’m still struggling with my homework here ;-) ) Has anyone tried to develop a partitioning expression for sudoku bands?
LarryLACa

Posts: 32
Joined: 24 August 2005

### Re: estimate for 4x4

Red Ed wrote:Further calculation easily (but pointlessly, lacking analogues for stacks) gives:
• 4x5 bands: 20! * 5!^12 * 879491145024
• 4x6 bands: 24! * 6!^12 * 677542845061056
• 4x7 bands: 28! * 7!^12 * 563690747238465024

I can confirm all this, and several of the next numbers can be found from a general summation formula:

The number of 4xN bands is (4N)! * N!^12 * R(N) where

Code: Select all
`               /               |               |   N!^2R(N) =   Sum   | --------  *       (a,b,c) | a!*b!*c!               |               \                                                                         \  ^2        /             ( a )   ( b )   ( c )   ( c )   ( b )   ( a ) \    |        |     Sum     (   ) * (   ) * (   ) * (   ) * (   ) * (   ) |    |        |  (k12,k13,  (k12)   (k13)   (k14)   (k23)   (k24)   (k34) |    |        |   k14,k23,                                                |    |        \   k24,k34)                                                /    |                                                                         /      (a)where ( ) is the binomial expression, where the outer summand is taken over      (b)all a,b,c such that 0<=a,b,c and a+b+c=2N, and where the inner summand is takenover all k12,k13,k14,k23,k24,k34>=0 such thatk12,k34 <= a  andk13,k24 <= b  andk14,k23 <= c  andk12+k13+k14 = a-k12+k23+k24 = b-k13+c-k23+k34 = c-k14+b-k24+a-k34 = N`

NB!! Notice that the entire outer sum is squared.

The expression within the outer summand is symmetric in a,b,c, so it's sufficient to do the counting for 0<=a<=b<=c and multiply with 6, 3 or 1 depending on whether a=b and b=c. It's not obvious from the expression (at least I can't see it) that R(N) becomes an integer, but nevertheless, this happens...
kjellfp

Posts: 140
Joined: 04 October 2005

### Re: estimate for 4x4

Nice. Go on then, let's have the 5xC case ... Red Ed

Posts: 633
Joined: 06 June 2005

### tip: ascii art equations - use alt viewer

I couldn't decipher the last ascii art equation from the BB display: my browser (IE) wraps the display because of the width. I did a copy/paste unformatted into my editor and chose a fixed width to make it readable. This is much less cryptic, though I'm still knawing on the partitioning constraints.
BTW: the inverse operation works for creating the same.

--edit--
A TeX version of the formula is now available at M.o.S - Bands
with the entire outer sum squared (as later updated!).
LarryLACa

Posts: 32
Joined: 24 August 2005

### yet faster

Kjellfp pointed out that my band solution counter was rather inefficient. I rewrote it to use his method and got these times for the 3x3 counting:
Code: Select all
`Band Counter   0.4Permutations   4.8Band 1         0.3Gangsters      3.6Gang lists     0.4Gang counts    0.2Band counts    2.2Grid count    24.2Overhead       0.1Total         36.1`
Having the right method beats clever programming every time.

Posts: 63
Joined: 18 October 2005

### Re: estimate for 4x4

Red Ed wrote:Nice. Go on then, let's have the 5xC case ... I think I have the RxC case now. Must be proofread and tested. Will put it out later today.
kjellfp

Posts: 140
Joined: 04 October 2005

### Re: yet faster

PatmaxDaddy wrote:Having the right method beats clever programming every time.

Having the right method and clever programming beats only having the right method.
kjellfp

Posts: 140
Joined: 04 October 2005

I have created a new thread

http://forum.enjoysudoku.com/viewtopic.php?t=2532

Please can we try to condense this threa into a few pages of relevant information for people who don't want to read 37 pages of posts.

Ideally the results of the many enquiries that go on here.
Pi

Posts: 389
Joined: 27 May 2005

PreviousNext 