The New Sudoku Players' Forum

[surbier]

Hi,

When I coded them, I was not aware of the zoo thread
and also not of the Mike Barker 'May 16 2006' post which ronk recently linked as addendum.

When I submit yor mentioned examples on UR+3C/2SL (= hidden UR acccording to hodoku; = hidden UR of type 1 according to scanraid)
to my code, I get:

Code: Select all

000000008000008630090130400047300000000510090000000000620800010078000005000625800 #1
singles
UR+3C/2SL (HUR1) (79)[14|66] cancel 9[66]
orig/ha M-wing  WeakLinkInDiscontLoop-7 2[64]-2[69]=1[69]-1[63]=1[23]-2[23]=2[24]-2[64] cancel 2[64]
singles

002090000004607000090004300708000009040020800050030100000500000006008900000000037 #2
singles
UR+3x/1SL yb  (46)[95|77] cancel 6[77]
orig/ha M-wing  WeakLinkInDiscontLoop-7 1[81]-1[88]=2[88]-2[97]=2[96]-1[96]=1[91]-1[81] cancel 1[81]
singles

000030040000206030102090000000003890003000027054000000500087200001600000400000005 #3
singles
UR+3C/2SL (HUR1) (68)[12|51] cancel 8[51]
orig/ha M-wing  WeakLinkInDiscontLoop-7 7[11]-7[21]=9[21]-9[61]=9[64]-7[64]=7[14]-7[11] cancel 7[11]
singles

201000008000003000000000062603007000052094700700300100400006051900500040007010000 #4
singles, line-block, naked triplet in row 1
UR+3X (27)[75|24]  cancel 9[3][4]
pointing pair : 9 in block 2 aligned in row 1 : cancel 9[12]
UR+3x/1SL yb  (27)[75|24] cancel 7[24]
xy-chain        WeakLinkInDiscontLoop-13 7[74]-7[34]=8[34]-8[54]=6[54]-6[59]=3[59]-3[99]=9[99]-9[77]=2[77]-2[75]=7[75]-7[74] cancel 7[74]
singles


Yes, the UR+3C/2SL is not the bottleneck of the puzzles. In two of the cases, easier UR methods (methods with higher preference; higher application priority)
apply before the UR+3C/2SL got its chance.

When I switch off the UR+3x/1SL in #2, I get
UR+3C/2SL (HUR1) (46)[95|77] cancel 6[77]

When I switch off UR+3X for #4, I get
UR+3x/1SL yb (27)[75|24] cancel 7[24]
When I switch off UR+3x/1SL for #4, I get finally the
UR+3C/2SL (HUR1) (27)[75|24] cancel 7[24]

surbier

[ronk]

When I reached these puzzles:

--- UR+3C/2SL: both strong links share a node, do not include the bivalue cell and have equal labels => "b" can be removed from "abZ"

Code: Select all

 ab     abX
         |
        a|
     a   |
abY-----abZ


I was able to duplicate the UR pattern, but I wasn't able to get it to crack the puzzles. Do you get any better results?

I believe Mike was applying these two patterns simultaneously.

Code: Select all

 ab     abX
         |
        a|
     a   |
abY-----abZ

Removes "b" from the "abZ" cell



 ab     abX
 |
b|
 |   a
abY-----abZ

Removes "b" from the "abX" cell


In the 2nd illustration, note that a "strong link corner" may exist at the "abX" cell too ... for a total of three exclusions.

[daj95376]

Thanks surbier for confirming that UR+3C/2SL is insufficient to crack these puzzles.



Thanks ronk for supplying the companion UR pattern.

I believe Mike was applying these two patterns simultaneously.
...
In the 2nd illustration, note that a "strong link corner" may exist at the "abX" cell too ... for a total of three exclusions.

I found four eliminations in the first three puzzles corresponding to:

Code: Select all

 ab-----abX
 |   b   |
b|      a|
 |   a   |
abY-----abZ

Removes "a" from "ab" and "b" from "abX","abY","abZ"


The fourth puzzle uses your second pattern once.

[Edit: specifically listed eliminations.]

[ronk]

I found four eliminations in the first three puzzles corresponding to:

Code: Select all

 ab-----abX
 |   b   |
b|      a|
 |   a   |
abY-----abZ

Removes "a" from "ab" and "b" from "abZ" ... a Naked Single on "b" completes the eliminations


The fourth puzzle uses your second pattern once.

The "b" in "ab" becomes a hidden single, so IMO that 4th elimination shouldn't be counted as part of the underlying UR move.

[daj95376]

I found four eliminations in the first three puzzles corresponding to:

Code: Select all

 ab-----abX
 |   b   |
b|      a|
 |   a   |
abY-----abZ

Removes "a" from "ab" and "b" from "abZ" ... a Naked Single on "b" completes the eliminations


The fourth puzzle uses your second pattern once.

The "b" in "ab" becomes a hidden single, so IMO that 4th elimination shouldn't be counted as part of the underlying UR move.

I should have simply listed all of the eliminations directly attributable to the UR pattern.

Code: Select all

Removes "a" from "ab" and "b" from "abX","abY","abZ"


The elimination of "a" from "ab" can be derived based solely on the UR pattern.

Code: Select all

"ab"=a => { "abX"=b and "abY"=b } either of which => "abZ"=a ... unacceptable!!!


[ronk]

The elimination of "a" from "ab" can be derived based solely on the UR pattern.

Code: Select all

"ab"=a => { "abX"=b and "abY"=b } either of which => "abZ"=a ... unacceptable!!!


A hazard of using induction instead of deduction is that one doesn't pause to count the strong links. Don't know about the "3x" part, but you're now talking about a "UR+3x/3SL" ... instead of an overlay of "UR+3x/2SL"s.

[daj95376]

A hazard of using induction instead of deduction is that one doesn't pause to count the strong links. Don't know about the "3x" part, but you're now talking about a "UR+3x/3SL" ... instead of an overlay of "UR+3x/2SL"s.

That's why I didn't try to give the pattern a name! It was only suppose to show that combining a UR+3C/2SL with 2x of your second pattern (UR+3N/2SL) results in the three eliminations from the individual patterns ... and ... one additional elimination based on examining the combination as a whole.

From a practical standpoint, it's sufficient to perform the three patterns individually and let the fourth elimination fall by way of a Hidden Single. I was just impressed that "the combination" provided directly for the elimination in "a" -- as found by my solver -- and not as a subsequent Hidden Single elimination.

[eleven]

From a practical standpoint, ...

... you could solve them this way:

Code: Select all

 *----------------------------------*
 | 47  3  46  | 79 5  .  | 1  2  8  |
 | 17  5  12  |*27 4  8  | 6  3  9  |
 | 8   9  26  | 1  3  26 | 4  5  7  |
 |------------+----------+----------|
 | 19  4  7   | 3  6 x29 | 5  8  12 |
 | 2   8  3   | 5  1  4  | 7  9  6  |
 | 5   6  19  | .  8  .  | 3  4  12 |
 |------------+----------+----------|
 | 6   2  5   | 8  7  3  | 9  1  4  |
 | 3   7  8   | 4  9  1  | 2  6  5  |
 | 49  1  49  | 6  2  5  | 8  7  3  |
 *----------------------------------*

DP 79 in r16c46, either r2c4 must be 7 or r4c6 must be 9. Both directly imply r1c4=9.
(When i get a number, i normally dont look for other UR eliminations, though
r2c4=7->r6c6=7 and r4c6=9 both imply r6c6<>9.)

Code: Select all

 *----------------------------------*
 | 47  3  46  | 9  5  67 | 1  2  8  |
 | 17  5  12  | 27 4  8  | 6  3  9  |
 | 8   9  26  | 1  3  6  | 4  5  7  |
 |------------+----------+----------|
 | 19  4  7   | 3  6  29 | 5  8  12 |
 | 2   8  3   | 5  1  4  | 7  9  6  |
 | 5   6  19  | 27 8  #  | 3  4  12 |
 |------------+----------+----------|
 | 6   2  5   | 8  7  3  | 9  1  4  |
 | 3   7  8   | 4  9  1  | 2  6  5  |
 | 49  1  49  | 6  2  5  | 8  7  3  |
 *----------------------------------*

Now here you have a good chance to see that a 9 in r6c6 leads to the deadly pattern too.

[daj95376]

I hope it's okay to use this thread for additional questions about Mike Barker's UR patterns.

Free Press April 22, 2011 (and posted by Keith elsewhere)

Is this UR pattern among MB's UR patterns?

Code: Select all

 (*) UR cell
 (#) bivalue support cell

 *r8c5=1 SL[ *r7c5=8 *r8c9=8 ] r7c9<>8
   ||                  ||
   ||                #r5c9=3   r7c9<>3
 #r7c6=2                       r7c9<>2

                              *r7c9=1

 =>  r8c5<>1
 +------------------------------------------------------------------------+
 |  8      7      69     |  1      236     4      |  2356   2369   235    |
 |  59     356    2      |  7      36      8      |  1      369    4      |
 |  146    136    146    |  236    5       9      |  7      8      23     |
 |-----------------------+------------------------+-----------------------|
 |  3      1258   189    |  4      79      6      |  258    127    12578  |
 |  46     68     7      |  25     12      125    |  9      34    #38     |
 |  59     125    149    |  8      79      3      |  25     1247   6      |
 |-----------------------+------------------------+-----------------------|
 |  7      4      5      |  9     *18+236 #12     |  2368   1236  *18+23  |
 |  2      9      3      |  56    *18+6    15     |  4      167   *18+7   |
 |  16     168    168    |  23     4       7      |  23     5      9      |
 +------------------------------------------------------------------------+
 # 87 eliminations remain


TIA !!!

[ronk]

Is this UR pattern among MB's UR patterns?

I didn't make a close check, but I don't recall any of Mike's patterns having two "support cells" that didn't "see" each other. Here's a "ttt-like diagram" for that.

Code: Select all

UR(18)r78c59
 ||
(6)r8c5
 ||
(236-8)r7c5 = (8)r8c5
 ||
(7-8)r8c9 = (8)r8c5
 ||
(2)r7c9 - (2=1)r7c6
 ||
(3)r7c9 - (3=8)r5c9 - (8)r8c9 = (8)r8c5  ==> r8c5<>1

[daj95376]

Thanks Ron for the deductive perspective on the elimination. For some reason, I'm drawn to the Dark Side when it comes to UR eliminations. I love making an invalid assignment and watching the domino effect produce a deadly pattern. The main drawback to this approach is the possible creation of secondary contradictions while striving for the DP.

If I were to tackle this UR manually, then I wouldn't look for a common elimination resulting from so many non-UR candidates in the pattern. I'd have noticed the two strong links on <8> and immediately tested r8c5=1 to see if it would force r7c9=1. Thus, the reason for the format I chose.

Regards, Danny

[ronk]

... I wouldn't look for a common elimination resulting from so many non-UR candidates in the pattern. I'd have noticed the two strong links on <8> and immediately tested r8c5=1 to see if it would force r7c9=1.

I agree on the "so many non-UR candidates", but that was the only practical way to preserve your two bivalued "helper cells." With too many internal non-UR candidates, I normally look for the external "DP busters." In this case:

Code: Select all

UR(18)r78c59
 ||
(1)r78c6
 ||
(8)r7c7 - (8)r7c5 = (8)r8c5
 ||
(1-7)r4c9 = (7-8)r8c9 = (8)r8c5  ==> r8c5<>1

[surbier]

In addition to my post from April 11 (if not outdated):

When applying the mentioned URs simultaneously to examples 1, and 3 , there remain only singles.
For #4, when applying the latter two URs simultaneously (keeping r2c4<>7 on hold), it also solves
down to singles.

Code: Select all

201000008000003000000000062603007000052094700700300100400006051900500040007010000 #4
+--------------------------+--------------------------+--------------------------+
|   2     469       1      | 69      456     59       |   3       7       8      |
|   8     67      459      |#267    #267       3      | 459       1     459      |
|   3     479     459      |978      478       1      | 459       6       2      |
+--------------------------+--------------------------+--------------------------+
|   6     489       3      |   1     258       7      | 4589    289     459      |
|   1       5       2      | 68        9       4      |   7     38      36       |
|   7     489     49       |   3     2568    25       |   1     289     4569     |
+--------------------------+--------------------------+--------------------------+
|   4       3       8      |#279    #27        6      | 29        5       1      |
|   9       1       6      |   5       3     28       | 28        4       7      |
|   5       2       7      |   4       1     89       |   6     389     39       |
+--------------------------+--------------------------+--------------------------+

27+6  -2- 27+6

|2

27+9  -7- 27


UR+3X         (27)[r7c5|r2c4] r3c4<>9  (supporting cell (69)[r1c4] )
pointing pair                 r1c2<>9
UR+3x/1SL yb  (27)[r7c5|r2c4] r2c4<>7  (supporting cell (67)[r2c2] )
UR+3N/2SL     (27)[r7c5|r2c4] r2c5<>7  (or a UR+3U/2SL)


[daj95376]

Yes, the individual eliminations can be found using two of Mike Barker's patterns.

A forcing network perspective that might be used manually.

Code: Select all

 Either (one of) r2c45=6 and/or r7c4=9

 r2c45=6 ->                     r2c2=7  =>  r2c45<>7
 r7c4 =9 -> r1c4=6 -> r5c4=8 -> r3c4=7  =>  r2c45<>7
 +--------------------------------------------------------------+
 |  2     469   1     |  69    456   59    |  3     7     8     |
 |  8     67    459   | *27+6 *27+6  3     |  459   1     459   |
 |  3     479   459   |  789   478   1     |  459   6     2     |
 |--------------------+--------------------+--------------------|
 |  6     489   3     |  1     258   7     |  4589  289   459   |
 |  1     5     2     |  68    9     4     |  7     38    36    |
 |  7     489   49    |  3     2568  25    |  1     289   4569  |
 |--------------------+--------------------+--------------------|
 |  4     3     8     | *27+9 *27    6     |  29    5     1     |
 |  9     1     6     |  5     3     28    |  28    4     7     |
 |  5     2     7     |  4     1     89    |  6     389   39    |
 +--------------------------------------------------------------+
 # 63 eliminations remain

 -or- (7=6)r2c2 - (6)r2c45 =UR= (9)r7c4 - (9=687)r153c4  =>  r2c45<>7


Since I have a difficult time following most of Mike Barker's explanations, I have no idea if he has a scenario for this approach.

Too bad ronk dropped the idea of examining (and explaining) Mike Barker's patterns. I could see one thread where the patterns are presented and discussed ... and a separate thread -- for reference purposes -- that posts just the consensus drawn from those discussions. (What should have been done for the Ultimate Fish Guide.)

[David P Bird]

You've gone over to the dark side again daj!

(8a)r3c5 = (8)r3c4 - (8=96)r15c4 - (9b=27)r7c45 -[UR]- (27)r2c45 = (78c)r3c45
=> [ac] r3c5 <> 4, [bc] r3c4 <> 9 making (4)r1c5 single and (78)r2c45 a naked pair.