Check max Hamming weight in the other direction.

Once we've already got a solution, we can further winnow the set of
possible adjacency matrices, by ensuring the same bit is not set in
too many entries of adjmatrix (since if it were, some length-n stick
would have to be divided into enough pieces to make one at most the
already-known best result). This adds complexity to each step of the
recursion over possible matrices, but by early pruning it seems to cut
down the number of steps by rather more; I estimate a factor of four
speedup in pursuit of (n,m)=(10,7).

Prune by symmetry: constrain 1st adj row to all 1s at low end.

Separate stdout from stderr.

Output the actual dissection, as a matrix.

commentary

assert our arguments

do not leak prob when retrying

search in order by max hamming weight

Revert "loop in reverse order - this is a better search path"

This reverts commit 35e60acecf2f2657a3fd53f89053de9e57a0d7fe.

Doesn't actually seem to help that much.

loop in reverse order - this is a better search path

Revert "mix up the order" and "mix up the order"

This is not correct; I think it doesn't in fact search all relevant
bit patterns.

mix up the order, print better

mix up the order

error fixes; tried interior but doesn't work (EINSTAB) and docs say cannot cope with dense columns of which our X_minimum is one

print best solution

improve maxminsize thing

fix printing more

less printing, optimise

output improvements

wip lp seems to work so far...

wip lp, results, compiles

wip lp, problem setup compiles

wip lp

wip lp notes before condense

wip, builds, before glpk

wip