Serg wrote:Do you have full list of maximal invalid patterns for "5 free boxes" case (B3, B1, S2) and "6 free boxes" case (S1, S3)?
For the "5 free boxes" (4 boxes filled) case ... possibly, but I don't have all of them in one place.
This weekend, I'll look at some old projects, etc., to see what I can put together.
JPF wrote:To
Blue:
I'm 99.99% sure...
What are the missing 0.01%?
For these 5 patterns, it's mainly the outside possiblity that after hours of my "patterns game" code running on them, some puzzle exists, but was never found.
For patterns in general, there's a possibility of a bugs in the code that "proves" that they really don't have puzzles.
For me, each pattern requires specially tailored code, and alot of it is "copy/paste/edit" code, and sometimes I make mistakes.
There's also a possiblity of logical errors in implemeting the big picture, for a given pattern. Some details below.
If you want to try your hand at writing "proving" code for some patterns ...
First, sorry if I'm about to tell you things you already know ...
The main plan of attack ... if you want things to complete in a reasonable time ... is to
- Produce every ED way of filling the empty cells of the pattern, that as a puzzle, is a puzzle with at least one solution.
- For each of those, take one of its solutions, and clear out the empty cells in the pattern, and check whether the result is a puzzle with multiple solutions.
If it is that, then the "(ED) fill" for the empty cells of the pattern, contains an unavoidable set ... which is what we hope.
If every ED fill (that has an extension to a complete grid), contains an unavoidable set, then the pattern has no valid (single solution) puzzles.
If, in step (2) above, the (2nd) puzzle has a single solution ... then that puzzle is a counterexample to the proposition that the pattern has no valid puzzles.
On the "ED" fills bit: working in the other direction ... suppose the pattern had a valid puzzle, with a unique solution. Then starting with that (hypothetical) (puzzle,solution) pair, you could transform it in ways that preserve the "empty cells" shape, and bring what's in the solution grid in those cells, to a canonical form of your choosing. What's in those cells, in the end, would be one of the "ED fills" (for the empty cells), that would come under consideration in step 1.
This is detail that I don't want to go into, but if you actually had a (puzzle,solution) pair, and did what was outlined here, and took the "canonical empty cells fill" into step 2 ... you would
definitly get a "counterexample puzzle", but it likely wouldn't match "puzzle" part of the transformed (puzzle, solution) pair that you started with.
Step 2 above, is basic and too simple to screw up.
Step 1 is where problems can arise.
Usually producing *every* fill for the empty cells, checking whether (as puzzles)they have one or more solutions, and taking the results (as they come) into step 2 ... produces way too many puzzles, given "reasonable" as a time constraint.
You can save time, by only producing puzzles that would be "minlex" with respect to relabelling (only) transformations, but you can still get a lot of puzzles that way.
You could do that, though, and pass the results to a standard "pseudo-puzzle" canonicalizer, check the canonical form against a list that you acculate, and only handle the cases that aren't already in the list.
Issues with that: 1) "pseudo-puzzle" canonicalizing can sometimes take as long as solving and 2) the accumulating list, might not fit in memory.
Ways around that: 1) build up ED fills "in stages", 2) produce ED fill lists for different parts of the empty cells pattern, and piece them together to make complete fills, 3) some combination.
For the "build in stages" bit: for an example, using one of the shapes above, you might start by producing all of the ED fills for the band 1 part of the shape, and then extend those to fills for the full shape. That would be a place where the kind of "logical error" that I mentioned, could creep in. A "canonicalizer" for the band 1 part, would usually look at the possibility of swapping stacks (boxes in this case) 1 & 2. But, the part of the pattern in bands 2&3 under box 1, doesn't match what's under box 2, and you couldn't make it match, by say swapping bands 2&3 and permuting rows in the bands. That's a problem. There are two options, it seems: 1) use a canonicalizer with the stacks 1&2 swap disabled, or 2) use a standard canonicalizer, and for each ED result, try the bands 2&3 fill using the original ED band 1 fill, and same fill with boxes 1&2 swapped.
For the separate ED lists for different parts of the pattern bit: It's tricky, and highly prone to logical errors. It's probably only a last resort when the "memory issue" comes into play. You can use overlapping "parts" (e.g. overlapping in a full box), or isolated parts where cells in one part, see cells in another. It generally means that you forgoe the idea that you will test only an ED list of complete fills, and settle for knowing that for each truly ED fill, at least once, you'll test some version of it.
I'm cutting this short, because it can get really deep, and it isn't easy to explain (I'm finding out).
"Should you choose to accept this mission" ... think carefully and good luck.
Cheers.