by JPF » Fri Feb 02, 2007 10:50 pm
coloin wrote:The approx upper limit of 7@r2c3 [416codes] is now 385+ [385*385] /2 X 2500 = 186243750 [maybe much less]
coloin wrote:Can we say there is no duplicates in 7@r2c3 min lex grids ?
by gsf » Sat Feb 03, 2007 5:52 pm
JPF wrote:gsf wrote:I burned some background cycles overnight to generate the min and max min-lex grids for each of the 416 bands
gsf,
Am I missing something, or should your index list start with 001,002,... ?
by JPF » Sat Feb 03, 2007 6:54 pm
gsf wrote:I edited the post – thanks
gsf wrote:here are some preliminary band population results (to be verified when all bands are done)
- Code: Select all
001 1007170
by gsf » Sat Feb 03, 2007 10:23 pm
JPF wrote:gsf wrote:I edited the post – thanks
for some reason the list stops at 373.
JPF wrote:gsf wrote:here are some preliminary band population results (to be verified when all bands are done)
- Code: Select all
001 1007170
Doest it mean that the band #1 is (at least once) in 1007170 min-lex grids ?
123456789457893612986217354274538196531964827698721435342685971715349268869172543by gsf » Sat Feb 03, 2007 10:25 pm
by coloin » Tue Feb 06, 2007 9:12 pm
by Red Ed » Tue Feb 06, 2007 9:48 pm
No, there are a heck of a lot more than that. "Essentially" same/different is a term we've always used to describe ismorphism classes: so there are "essentially" only 416 arrangements of B123 and essentially (don't know, but lots) arrangements of B12347. The 2865 number, on the other hand, is a "gangster" count, like the 44 number: it sees minirows (in B4/7) and minicolumns (in B2/3) as unordered triples, not ordered triples, which makes it a lot easier to put two arrangements in the same class.coloin wrote:there are only 2865 essentially different B1B2B3B4B7 combinations
by gsf » Tue Feb 06, 2007 11:35 pm
by Red Ed » Wed Feb 07, 2007 2:32 pm
by gsf » Wed Feb 07, 2007 2:43 pm
Red Ed wrote:Very nice! I've not seen the catalogue constructed directly before. That'll put you in a good position the next time a "what's the most number of X in any grid?" question comes along.
Red Ed wrote:Surprised to see mebibytes and gibibytes in your message. I hope you've not been involved in any lawsuits !
by udosuk » Wed Feb 07, 2007 3:14 pm
gsf wrote:when its done it would be nice to find a host for the 46Gi
It'd be much nicer to pack the whole catalogue in less than 700MB or 4.7GB so it can be burnt into a single CD/DVD...by gsf » Wed Feb 07, 2007 6:55 pm
udosuk wrote:gsf wrote:when its done it would be nice to find a host for the 46Gi
A few months ago I initiated a discussion about minimalization/compression of solution grids in this thread... I wonder if those schemes from RW etc would be helpful to trim this huge size of 46Gi down to xxx Mi's?
by gsf » Fri Feb 09, 2007 4:48 pm
udosuk wrote:gsf wrote:back of the envelope: 5472730538 into 4.7Gi is < 1 byte per puzzle -- none of the discussions ever got that close
Thanks gsf... Very thoughtful calculation...
bands grids sudz sudz+bw
006 96229042 1.66 0.74
100 27849953 1.92 1.21
150 11577852 2.17 1.44
300-416 2097068 3.51 2.78
by Mauricio » Mon Feb 12, 2007 9:02 pm
daj95376 wrote:I favor this (extended) Canonical Form that (I believe) was proposed by JPF somewhere in this forum. I (sometimes) use it to generate puzzles.
- Code: Select all
123|4..|...
456|...|...
789|...|4..
---+---+---
.4.|...|...
...|...|.4.
...|..4|...
---+---+---
..4|...|...
...|.4.|...
...|...|..4
123|...|...
456|12.|...
789|...|1..
---+---+---
.1.|...|...
...|.1.|...
...|...|.1.
---+---+---
..1|...|...
...|..1|...
...|...|..1
