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