ronk wrote:gsf, excellent job. However, I think there's still a clerical error. Your third puzzle is equivalent to Red Ed's puzzle
here.
- Code: Select all
.2.45..........1.3.9.......2....3.........9....5....4............7..16...4..2..5. #gsf
.1.2...3.4.....5.....6.....7...4.....2......6....5....5...73....8....4..........7 #Red Ed
I'm glad I'm not paying for the proof reading ...
original post corrected
thanks
ronk wrote:While it's useful to compare puzzles in canonical form, I certainly hope they aren't catalogued that way. Which begs the question ... what is the catalog form of the 36,628?
gfroyle wrote:They are stored in lex order according to the canonical labelling that comes out of a program, and so the old ones will be interleaved with the new ones, thus any references to "Number #21020" and so on will change. When I get round to it, I will put them in a proper database with a permanent ID number.
and I believe that program is
nauty -- a graph/digraph (lines and edges) automorphism/isomorphism workhorse by Brendan McKay
so the original catalog posted by gordon is in a canonical order
ronk wrote:I would argue that the catalog form should be a maximally-symmetric, however that might be defined. Does anyone already have software to do that?
for computations involving equivalence a canonical representation is most efficient
I work off a 1 puzzle per line file with 7 fields
< canonical-puzzle canonical-grid original-puzzle original-ordinal tour-class contributer date >
http://www.research.att.com/~gsf/sudoku/data/sudoku17-2007-01-22.can.gzsort, uniq, cut, join on that file produce all of the data in the posts
the (numerous) clerical errors were due to entry errors in the catalog
the posted catalog should have it right
I don't think anyone has posted a "symmetrizer"