ab wrote:Here it is:
1. Find all locked pairs (type 1), but pretend they do not exist.
2. Make eliminations based on the locked pairs found in step 1.
3. Find all hidden singles, but pretend they do not exist.
4. Place the hidden singles found in step 3 and perform eliminations.
5. Increment step counter and repeat from step 1.
tarek wrote:You are right gsf in saying that a box line elimination is possible.
however, I actually wouldn't go for a box-line elimination if there is
an obvious hidden single there.....I would place the hidden single only
[If two deductions can be made based on one cell then I would go for
the more obvious or easier deduction first, if that was the hidden
single then the step ends there. If it was the box-line elimination
then you are correct in your assumption].
I think that the setting should be at >1 per line per box because I
consider the hidden single EASIER than box-line elimination.
the point I hope is not to do what any particular user would do
but to do what the rules say
ab's ulterior rules don't have provisions for "more obvious"
- Code: Select all
(1) locked pairs
(2) commit
(3) hidden singles
(4) commit
(5) increment step count
tarek wrote:You are solving it Pat in the method which this thread does not employ
(we employ ab's method, Hidden & box-line at the same time).... (Pat's
method, is exhausting hidden singles before going to type one box-line
eliminations)......
The puzzle you mentioned solves in 12 steps(ab's method), 11 out of
these steps you can make box-line eliminations out of which 6 should
put more placements than if left for hidden singles alone......
even though its been spelled out there is still confusion
ab's rules are not exacty "Hidden & box-line at the same time"
I've was confused too until I came up with an expression syntax
(that can be input to my solver) that defines what a "step" is
(you can substitute any constraint names you like in the following
the operations on the constraints are what's important)
define a
move to be one or more placements or eliminations
moves are
identified by
applying a constraint for a puzzle position
moves are
committed by actually making the placements or eliminations
a concatenation of constraint names specifies a left to right order on constraint application
- Code: Select all
C1...Ci...Cn
means:
- Code: Select all
repeat:
apply the constraints in order C1 ... Cn
for the first Ci that has at least one move
identify all Ci moves
commit all Ci moves in one batch
increment the step-count
goto repeat
end for
if no Ci has moves then either
the puzzle is solvable in step-count steps or
the puzzle is not solvable (constrained) by the given constraints
end if
let {...} treat groups of constraints as one constraint
- Code: Select all
{C1...Cn}
means
- Code: Select all
identify all C1 moves
...
identify all Cn moves
commit all C1...Cn moves in one batch
(all constraints in the group are applied, not all need produce moves)
finally, let : within a group denote "commit":
- Code: Select all
{C1:C2C3}
means
- Code: Select all
identify all C1 moves
commit all C1 moves
identify all C2 moves
identify all C3 moves
commit all C2 and C3 moves
the inferior and ulterior threads involve these constraints
- Code: Select all
F naked singles
N hidden singles
B2 locked pairs (box-line)
so the ulterior step count expression (ab's rules) is
- Code: Select all
{B2:N}
and the inferior step count expression is
- Code: Select all
{FN}
the {FN} expression captures all of the posted inferior counts
{B2:N} captures the ulterior counts except the cases where F and/or N may also be identfied by B2
for reproducability it seems that B2 should identify singles if those singles match the
B2 constraints
)???
