how fast ? I haven't yet implemented the quick 6* 416-number creation
also looking for quick canonical form
or quick automorphism group
so to filter the 5.5e9 from my 1.16e10
dukuso wrote:how fast ? I haven't yet implemented the quick 6* 416-number creation
also looking for quick canonical form
or quick automorphism group
so to filter the 5.5e9 from my 1.16e10
6*416 ~40000 grid/sec/Ghz
canon+aut ~9000 grid/sec/Ghz
dukuso wrote:too slow to walk through all the 5e9 grids
OK, using Kjell's (where is he ?) program from 2005, I think I need ~10h with 2GHz to generate
the 1.1e10 416-sixtuples and the counts for the 44-threetuples 1.1e10 grids,
presumably all the T-classes are represented, but I'm not sure.
it's running now , please no bug ...
gsf wrote:do you have a url for Kjell's program
dukuso wrote:to summarize:
---------------------------------------
You generate 416 compressed files of total size 5.5GB
and each of these can be expanded to give sudokugrids,
one from each S-class in lexicographically minimal form.
The 416 files represent the S-classes with that 416-gangster
as first band and all other bands or towers have same or larger 416-index
The grids in that file are lexicographically minimal in their S-class
and are sorted lexicographically.
(right ?)
---------------------------------------
1.)
I'd like a list of all (-say- "X-classes"), minimized by size, # of members, such that
every T-class can be obtained from at least one member of the list by permuting
mini-colomns within the bands.
And a bitstream-file that indicates which of the thus (canonically) genearated
mini-column-permutations do create new T-classes.
An estimated ~400000 sudokugrids for the X-classes, and a bitstream
of ~1.5 e10 bits ~ 2e9 bytes = 2GB
This can then be used to generate exactly one sudoku from each T-class, residing
in memory for a moment, in less than an hour with 2GHz, 1e10 grids in total
--------------------------------------------------------------
2.) the same, but for S-classes, the same ~400000 sudokugrids, but another
bitstream, so that only one sudokugrid from each S-class is created
--------------------------------------------------
can this idea be applied to the rookery-based liting of -classes ?
can it be applied to latin squares isotopy classes ?
or n-queen-solutions or pandiagonal latin squares or
magic squares or cubes or Nasik-Cubes or magic knight's tours
or ...
Sure. Each S-class should be picked with probability inversely proportional to the number of automorphisms it exhibits; then grab a representative of that S-class and 'scramble' it (relabel, swap bands etc.) randomly.gsf wrote:Red Ed, assuming we had the list of seed grids for the S-classes, with the
number of grids (up to isomorphism or with dups counted) for each class, could that
be used in an unbiased random grid generator?
Red Ed wrote:Sure. Each S-class should be picked with probability inversely proportional to the number of automorphisms it exhibits; then grab a representative of that S-class and 'scramble' it (relabel, swap bands etc.) randomly.gsf wrote:Red Ed, assuming we had the list of seed grids for the S-classes, with the
number of grids (up to isomorphism or with dups counted) for each class, could that
be used in an unbiased random grid generator?
You can build fast unbiased random generators with much less lookup data than that, though, e.g. my method or (sadly lost in the crash) holdout's.
dukuso wrote:some would be generated twice, some not
Oh, that. Okay. If X-classes generate T-classes then maybe W-classes generate S-classes ... Whatever; it doesn't look like a win because of the overhead of keeping a cumulative version of the anti-dup bitstream that tells you how many new S-classes the given X- (or W- ... I can't keep up) class generates.gsf wrote:I was thinking about the ~400K S-class generators (we don't have them yet)