.
TEMPLATES AS PATTERNS
The purpose of this thread is to consider the old templates technique as being a pattern-based one, where the patterns are templates[n].
Seeing templates as patterns has a clear practical advantage: once the abstract patterns are written, SudoRules and the CLIPS inference engine can automatically do all the associated pattern-matching work. It will also lead to intrinsic definitions (independent of any implementation, provided that it is correct).
Templates are an old solving technique, generally associated with T&E, DFS and other techniques considered as last resort ones (i.e. to be used only when nothing else works).
In my view, T&E (with my precise definition of it) can still be a last resort technique, but it is mainly a general (and universal) very broad classification tool (T&E-depth). But that's an aside that doesn't change the above remark.
A (negative) main difference of templates with T&E or DFS is, it is not generic: it depends in an essential way on application-specific structures, the templates.
But a generally overlooked difference is, templates can be defined in pure pattern-based (though application-specific) terms. It is the purpose of this thread to elaborate on this view.
As a result, templates could be understood as being in the same category as e.g. Subsets. But there's a major difference that blocks such a view. In order to apply the template patterns, one must not know only one of their instantiations (as is the case for Subsets), but all of them at once. This makes the technique too complex and therefore useless for a manual solver for most of the puzzles.
Like "whips" or "braids", "templates" is a general term that doesn't refer to any pattern. In reality, template patterns will only appear as template[1], template[2], template[3]... And, contrary to chain patterns, for reasons that will appear later, I won't speak of the length of a template but of its depth (or combinatorial depth).
Two main questions are therefore:
- is this template-depth intrinsic (independent of any particular implementation)? YES
- is it related to other useful classifications? It remains to be seen.
There's nothing really new about the definition below, except maybe its explicit formulation in terms of first order variables.
(Question marks indicate variables, by opposition to fixed, possibly arbitrary, values.)
Definition 1: the template[1] pattern is defined by:
- a digit ?nb
- a set of 9 rc-cells (?ri, ?ci), i=1...9 such that:
for any pair i≠j , (?ri, ?ci) and (?rj, ?cj) are not in the same row, not in the same column and not in the same block.
(Note: this can easily be transformed into a formula in the first order Sudoku language defined in [HLS], [CRT] or [PBCS], i.e. into a precise pattern according to my definitions there.
It can therefore straightforwardly be coded in SudoRules.)
By ordering the rows from 1 to 9 (i.e. setting ri=i), it is trivial to see that this is equivalent to:
Definition 1bis: the template[1] pattern is defined by:
- a digit ?nb
- a sequence of 9 columns ?ci, i=1...9 such that:
for any pair i≠j , the cells (i, ?ci) and (j, ?cj) are not in the same column and not in the same block.
As this is much simpler, I'll always use this definition.
(Note: this also can easily be transformed into a formula in the first order Sudoku language.
It can therefore straightforwardly be coded in SudoRules. Indeed, it is coded this way.)
Definition: instantiation (or occurrence) of the template[1] pattern
Given a puzzle and a resolution state RS for it, an occurrence of the template[1] pattern in RS is defined by:
- a fixed digit n,
- a fixed sequence of columns c1...c9,
such that:
- they satisfy the conditions of the template[1] pattern and
- in each of the (i, ci) rc-cell, the digit n is still a possible candidate (possibly a decided value).
Said otherwise, an instantiation is any full assignment of 9 compatible places in the grid for digit n.
The conditions of the template[1] pattern guarantee that each of its instantiations is a priori possible in any puzzle - until it appears to somehow contradict the givens.
It is easy to compute that, in an empty grid, there are 46,656 instantiations of the template[1] pattern, for each digit. In practice, in a real puzzle there may be much fewer; but the real number is highly variable from one puzzle to the other.
Remark: one might ask about a super-symmetric version of the template[1] pattern. Would it not be for the block constraint, the rn or cn version would respectively be the assignment of a full column or a full row. But:
- there are many more possible assignments for a single row or column in an empty grid, namely 9! = 362,880;
- due to the block constraint, a single row provides much less information than a template[1] instantiation;
- whenit comes to combine templates, it would be much more complicated (though feasible).
Extended resolution rules based on template[1]
There are two extended resolution rules based on template[1] (the following is just a reformulation of rules that have been known for years):
- rule T1-assert: if a fixed candidate C=(n r c) belongs to all the instantiations of the template[1] pattern with digit n, then assert C as True;
- rule T1-delete: if a fixed candidate C=(n r c) belongs to none of the instantiations of the template[1] pattern with digit n, then delete C.
Their proofs are obvious.
They are not resolution rules in the strict sense I've given this expression, i.e. "pattern instantiation => assertion or elimination of a candidate".
Two obvious problems with needing all the instantiations at once instead of only one at a time for any rule application are:
- complexity is a priori higher than for usual resolution rules;
- it's impossible in practice to print all the instantiations used for the conclusion. In the following examples, I'll give only the general information used for each rule application.
The T1 extended resolution theory
Define T1 as the union of:
- BRT (the universal Basic Resolution Theory, i.e. Singles, Elementary Constraints Propagation, Solution Detection, Contradiction Detection - as defined in [HLS], [CRT], or [PBCS]),
- T1-assert
- T1-delete.
Theorem: T1 is stable under confluence and it has the confluence property.
If a candidate C1 is asserted or deleted for any reason, any other candidate C that could have been asserted or eliminated by T1 can still be. The reason is, the change in C1 can only leads to the deletion of instantiations for templates[1]. But rules T1-assert and T1-delete remain obviously applicable to the same candidates after such instantiations disappear.
References
Myth Jellies 2006: http://forum.enjoysudoku.com/converting-from-candidate-space-to-pom-space-and-beyond-t4398.html
pjb 2012: http://forum.enjoysudoku.com/new-solving-technique-i-think-t30444.html
Myth Jellies 2016: http://forum.enjoysudoku.com/basics-of-pom-pattern-overlay-method-t33451.html
(anonymous, undated): https://sudopedia.org/wiki/Pattern_Overlay_Method
(anonymous, undated): https://www.sudokuwiki.org/Pattern_Overlay
P.O. 2022: http://forum.enjoysudoku.com/pattern-overlay-method-t40180.html
[Edit: added colour to rules T1-assert and T1-delete]
[Edit: added reference]
.