The New Sudoku Players' Forum

[ArkieTech]

Code: Select all

 *-----------*
 |.6.|...|.4.|
 |8.7|...|9.5|
 |.9.|5.8|.6.|
 |---+---+---|
 |..6|.5.|4..|
 |...|8.7|...|
 |..3|.4.|8..|
 |---+---+---|
 |.5.|9.2|.1.|
 |6.9|...|7.2|
 |.3.|...|.8.|
 *-----------*


Play/Print this puzzle online

[Cenoman]

Code: Select all

 +--------------------+-----------------+-----------------+
 |  12*    6     5    |  7    9    3    |  12*  4    8    |
 |  8      12*   7    |  46   12*  46   |  9    3    5    |
 |  3      9     4    |  5    12*  8    |  12*  6    7    |
 +--------------------+-----------------+-----------------+
 |  29     8     6    |  12   5    19   |  4    7    3    |
 |  1249  a124*  12*  |  8    3    7    |  5    29   6    |
 |  5      7     3    |  26   4    69   |  8    29   1    |
 +--------------------+-----------------+-----------------+
 |  7      5     8    |  9    6    2    |  3    1    4    |
 |  6      1-4   9    |  3    8    14   |  7    5    2    |
 | b124*   3     12*  |  14   7    5    |  6    8    9    |
 +--------------------+-----------------+-----------------+

DP(12)b1p15, r23c5, r13c7, r5c23, r9c13 (BUG-lite) using internals
(4)r5c2==r9c1 => -4 r8c2; ste

[SpAce]

Code: Select all

.-----------------------.------------.-----------.
|   12      6      5    | 7   9   3  | 12  4   8 |
|   8       12     7    | 46  12  46 | 9   3   5 |
|   3       9      4    | 5   12  8  | 12  6   7 |
:-----------------------+------------+-----------:
|   9-2     8      6    | 12  5   19 | 4   7   3 |
| ab49+12  b24+1  a1+2  | 8   3   7  | 5   29  6 |
|   5       7      3    | 26  4   69 | 8   29  1 |
:-----------------------+------------+-----------:
|   7       5      8    | 9   6   2  | 3   1   4 |
|   6       14     9    | 3   8   14 | 7   5   2 |
|  a14+2    3     b2+1  | 14  7   5  | 6   8   9 |
'-----------------------'------------'-----------'

BUG+6: (2)r5c13,r9c1 == (1)r5c12,r9c3 - (1=2)r5c3 => -2 r4c1; stte

[SteveG48]

Code: Select all

 *-----------------------------------------------------------*
 | 12    6     5     | 7     9     3     | 12    4     8     |
 | 8     12    7     | 4-6   12  d46     | 9     3     5     |
 | 3     9     4     | 5     12    8     | 12    6     7     |
 *-------------------+-------------------+-------------------|
 |b29    8     6     |a12    5    a19    | 4     7     3     |
 | 1249 b124  b12    | 8     3     7     | 5     29    6     |
 | 5     7     3     |a26    4     69    | 8     29    1     |
 *-------------------+-------------------+-------------------|
 | 7     5     8     | 9     6     2     | 3     1     4     |
 | 6    c14    9     | 3     8    d14    | 7     5     2     |
 | 124   3     12    | 14    7     5     | 6     8     9     |
 *-----------------------------------------------------------*


(6=129)b5p137 - (9=124)b4p156 - 4r8c2 = (46)r29c6 => -6 r2c4 ; stte

[SteveG48]

Code: Select all

.-----------------------.------------.-----------.
|   12      6      5    | 7   9   3  | 12  4   8 |
|   8       12     7    | 46  12  46 | 9   3   5 |
|   3       9      4    | 5   12  8  | 12  6   7 |
:-----------------------+------------+-----------:
|   9-2     8      6    | 12  5   19 | 4   7   3 |
| ab49+12  b24+1  a1+2  | 8   3   7  | 5   29  6 |
|   5       7      3    | 26  4   69 | 8   29  1 |
:-----------------------+------------+-----------:
|   7       5      8    | 9   6   2  | 3   1   4 |
|   6       14     9    | 3   8   14 | 7   5   2 |
|  a14+2    3     b2+1  | 14  7   5  | 6   8   9 |
'-----------------------'------------'-----------'

BUG+6: (2)r5c13,r9c1 == (1)r5c12,r9c3 - (1=2)r5c3 => -2 r4c1; stte

I don't see the derived BUG link. If you eliminate the 2 at r9c1, then you only have one candidate 2 left on row 9. You need 2 for a BUG pattern. What am I missing?

[blue]

I don't see the derived BUG link. If you eliminate the 2 at r9c1, then you only have one candidate 2 left on row 9. You need 2 for a BUG pattern. What am I missing?

Valid point.

I do see this:

Code: Select all

+------------------+------------+-----------+
| 12     6      5  | 7   9   3  | 12  4   8 |
| 8      12     7  | 46  12  46 | 9   3   5 |
| 3      9      4  | 5   12  8  | 12  6   7 |
+------------------+------------+-----------+
| 9-2    8      6  | 12  5   19 | 4   7   3 |
| 49+12  24+1  /12 | 8   3   7  | 5   29  6 |
| 5      7      3  | 26  4   69 | 8   29  1 |
+------------------+------------+-----------+
| 7      5      8  | 9   6   2  | 3   1   4 |
| 6      14     9  | 3   8   14 | 7   5   2 |
| 14+2   3     /12 | 14  7   5  | 6   8   9 |
+------------------+------------+-----------+


BUG-Lite+4 in all unfilled cells except for r59c3

2r59c1 =[BUG-Lite]= 1r5c12 - (1=2)r5c3 => -2r4c1; stte

---

For an interesting twist, there's also an "Almost BUG+1", with the BUG in the same cells as the BUG-Lite:

2r5c3 = ((1r5c3,-1r5c12) & (2r9c3,-2r9c1) & (BUG + 2r5c1))

(2r5c3 == 2r5c1) => -2r4c1,-2r5c2; stte

Maybe SpAce had something similar/related in mind ?

The underlined candidates, in "2r5c3 = ((1r5c3,-1r5c12) & (2r9c3,-2r9c1) & (BUG + 2r5c1))", along with a -1r9c3 that I omitted ... are SpAce's "+6".

[SpAce]

Steve, blue, thanks for the comments! I don't have time to read them with thought right now, so just a very quick answer until I do.

Here's what I originally had (copy-pasted from my notes, not double-checked now):

Almost-BUG+1: 1r5c3 -> BUG+1 (+2r5c1); -> +2r5c13; stte

(2)r5c3 = (1,2)r59c3 - (1)r5c12|(2)r9c1 =BUG= (2)r5c1 => -2 r4c1,r5c28; stte

Assuming the idea was more or less correct, I guess something went wrong when I tried to simplify it.

I'll get back to this later!

[SpAce]

Ok, I found some time. Let's see.

I don't see the derived BUG link. If you eliminate the 2 at r9c1, then you only have one candidate 2 left on row 9. You need 2 for a BUG pattern. What am I missing?

Valid point.

I knew I was walking on thin ice when I wrote it, so I'm not surprised it raised eyebrows. However, I'm still kind of blind to the exact reason why you both seem to agree that it's wrong. I guess we can all agree that if all of those six +-candidates are removed we have a BUG+0 (1r5c3 and 2r9c3 become placements, so they're not part of the pattern), and vice versa: if any of them is placed the BUG (at least that particular BUG) is prevented. In other words, at least one of them must be true. So why is it not a BUG+6 and/or why doesn't the derived link work, then?

I do see this:

BUG-Lite+4 in all unfilled cells except for r59c3

2r59c1 =[BUG-Lite]= 1r5c12 - (1=2)r5c3 => -2r4c1; stte

Nice! I wanted to reduce it to that exact chain but didn't see the BUG-Lite logic justifying it. In fact, it's still kind of hard to see, but I trust it's there. Dealing with the full BUG feels more intuitive and easier to check (to me) than such a huge BUG-Lite.

For an interesting twist, there's also an "Almost BUG+1", with the BUG in the same cells as the BUG-Lite:

2r5c3 = ((1r5c3,-1r5c12) & (2r9c3,-2r9c1) & (BUG + 2r5c1))

(2r5c3 == 2r5c1) => -2r4c1,-2r5c2; stte

Maybe SpAce had something similar/related in mind ?

That's exactly what I had in mind (originally). I just wrote it a bit differently (my version in the previous post). The first time I tried that idea was in the July 22 puzzle. No one complained then, so maybe I should have written it similarly here. Yet, I still don't quite understand what was wrong with the way I did write it. Help me identify my blind spot!

[blue]

Hi SpAce,

Help me identify my blind spot!

Until now at least, when someone says "BUG+n", the "+n" candidates are only in cells with 3 or more candidates.
That would mean that r9c3 should be part of the BUG pattern, and (what Steve was getting at) the 2 in r9c1 would need to be one of the BUG candidates in r9.

I guess we can all agree that if all of those six +-candidates are removed we have a BUG+0 (1r5c3 and 2r9c3 become placements, so they're not part of the pattern)

I understand what you mean, but it's certainly a new twist.
It seems like a dangerous idea to pursue -- "placements" being implied by all of the +n candidates being false.
Since neither of {1r5c3,2r9c3} would void any of the BUG candidates in the other cells, though, it's safe in this case.

The first time I tried that idea was in the July 22 puzzle.
No one complained then, so maybe I should have written it similarly here.

I would agree that some other way of writing it, would have been helpful.
BTW: There's a typo in that post [ "(2=57)r5c93" --> "(2=57)r53c9" ].

Cheers,
Blue.

[SpAce]

Hi blue,

Thanks for explaining!

Until now at least, when someone says "BUG+n", the "+n" candidates are only in cells with 3 or more candidates.

That is indeed the convention, and in that light I see how my extension could (and did) cause confusion. Btw, if generalized, I don't think the defining difference is in the number of original candidates in the cells but how many are left once the guardians are removed. Normally two are always left, as the pattern name (Bivalue...) implies. With my extension also singles can be left, but then those cells are obviously excluded from the resulting BUG-pattern.

I understand what you mean, but it's certainly a new twist.

Yes, but who likes old twists? It does open up some new BUG possibilities, doesn't it? I don't know how useful it is in general, but I think it's conceptually educating. I know I used to have very false ideas about BUGs before that multi-BUG discussion with you and eleven, and I wouldn't be surprised if others had too. From that I learned that a single puzzle state can have multiple different BUGs depending on the choice of guardians, which didn't seem intuitive at first. Even less intuitive is the fact that a BUG can be hiding in plain sight even when it seems that there isn't any -- if my extension is allowed.

It seems like a dangerous idea to pursue -- "placements" being implied by all of the +n candidates being false.
Since neither of {1r5c3,2r9c3} would void any of the BUG candidates in the other cells, though, it's safe in this case.

Do you have an example in mind where it wouldn't be safe?

The first time I tried that idea was in the July 22 puzzle.
No one complained then, so maybe I should have written it similarly here.

I would agree that some other way of writing it, would have been helpful.

Perhaps so. Or how about just calling it something else, like a "Hidden BUG" or something? That should alert the reader to the fact that it's not quite conventional. In that case the July 22 puzzle could have been written:

Code: Select all

.-----------------.----------.------------.
| 69+7  14+79  17 | 2  46  5 | 39  8   37 |
| 2     49     5  | 7  8   3 | 1   49  6  |
| 67    8      3  | 9  46  1 | 2   45  57 |
:-----------------+----------+------------:
| 1     23     6  | 4  5   9 | 8   7   23 |
| 59    29     8  | 1  3   7 | 4   6   25 |
| 57+3  37     4  | 8  2   6 | 35  1   9  |
:-----------------+----------+------------:
| 8     5      2  | 6  9   4 | 7   3   1  |
| 3+7   17+3   9  | 5  17  8 | 6   2   4  |
| 4     6      17 | 3  17  2 | 59  59  8  |
'-----------------'----------'------------'

HBUG+6:

(7)r1c12,r8c1
||
(3)r6c1,r8c2 - (3=7)r8c1
||
(9)r1c2 - (9=2)r5c2 - (2=5)r5c9 - (5=7)r3c9

=> -7 r3c1

...which should be equivalent to this (lazily written with the embedded end point):

Almost BUG+3:

(7=3)r8c1 - r6c1|r8c2 =BUG= (7)r1c12@|(92)r15c2 - (2=57)r53c9 => -7 r3c1

BTW: There's a typo in that post [ "(2=57)r5c93" --> "(2=57)r53c9" ].

Thanks! Fixed.

[blue]

Hi SpAce,

It seems like a dangerous idea to pursue -- "placements" being implied by all of the +n candidates being false.
Since neither of {1r5c3,2r9c3} would void any of the BUG candidates in the other cells, though, it's safe in this case.

Do you have an example in mind where it wouldn't be safe?

I had two things in mind when I wrote that. One was that one or more of the "placements" might imply line of sight eliminations that destroy part of the BUG pattern. The other, was the possiblity that two or more "placements", might be collectively incompatible, and that somehow that could cause a problem with the rest of the logic.

Whatever "danger" I sensed, though, it doesn't matter if it was real or not ... any elimination(s) that follow from strong link on the "+n" candidates, would still be valid (assuming the puzzle doesn't have multiple solutions).

I realize now, that if you have one of your (new) "BUG+n+k" patterns, where 'k' of the "+" candidates are in cells that reduce to "placements" when the "+" candidates are all false ... then the "BUG+n" part of the the pattern, is actually a "BUG-Lite + n" pattern, where the BUG-Lite cells are "every unfilled cell, except for the 'placement' cells".

In that view, showing that each of the "+k" candidates also implies some particular elimination, would be an extra burdon that could be avoided by using the "BUG-Lite + n" alternative.

------

None of what follows is important.
It's just "idle talk" from a wandering mind.

This next bit, is just an observation: If we allow that your "BUG+n with a new twist" patterns can be called "BUG+n", then something that was "always true, but (generally) never relevant" ... is lost, apparently: if the puzzle doesn't have multiple solutions, then the BUG part of the pattern is actually a deadly pattern of the type that has no solutions. We lose it, I'm saying, only because generally a similar claim can't be made be made for the BUG-Lite part of a "BUG-Lite + n" pattern. For a BUG-Lite + n, genereally the only thing we can say is that if the BUG-Lite does have solutions, then none of them can be extended to a solution to the entire puzzle.

On the other hand, for the "new twist" kind of BUG+n, that might still be true. The "likely" way to extend a solution to the BUG(-Lite) part, to a solution for the entire puzzle, would be to simply add the cell values corresponding to the "placement(s)". That would work, it seems, as long as the placement(s) are mutually compatible, and they don't destoy the BUG(-Lite) part of the pattern, through line of sight eliminations -- the kind of "dangers" that I mentioned.

So what then ? It would seem that if we can make a reasonable argument that none of those "dangerous possiblities" is real ... i.e. that we *could* extend a solution to the BUG-Lite in that way, if one existed ... then we could make a similar claim for the BUG(-Lite) -- i.e. that it's a deadly pattern with no solution(s), provided that the puzzle itself, doesn't have multiple solutions.

Cheers.

[SpAce]

Thanks again, blue, for your thoughts!

I had two things in mind when I wrote that. One was that one or more of the "placements" might imply line of sight eliminations that destroy part of the BUG pattern.

I wonder if that's possible. Based on these few examples, it seems to me that those "placements" always have a line of sight to the corresponding guardians only, so they shouldn't break anything on their own. Then again, that kind of implies what you've been saying all along that those cells are actually redundant if we use the corresponding BUG-Lite pattern.

The other, was the possiblity that two or more "placements", might be collectively incompatible, and that somehow that could cause a problem with the rest of the logic.

This seems like a more real threat, I guess, especially if those placement cells aren't directly connected (like in your Sep 25 example).

Whatever "danger" I sensed, though, it doesn't matter if it was real or not ... any elimination(s) that follow from strong link on the "+n" candidates, would still be valid (assuming the puzzle doesn't have multiple solutions).

So the logic can be safely used? Then again, I'm leaning towards your better alternative anyhow:

I realize now, that if you have one of your (new) "BUG+n+k" patterns, where 'k' of the "+" candidates are in cells that reduce to "placements" when the "+" candidates are all false ... then the "BUG+n" part of the the pattern, is actually a "BUG-Lite + n" pattern, where the BUG-Lite cells are "every unfilled cell, except for the 'placement' cells".

In that view, showing that each of the "+k" candidates also implies some particular elimination, would be an extra burdon that could be avoided by using the "BUG-Lite + n" alternative.

If that rule is always valid, and I trust it is, then it's clearly better to use the corresponding BUG-Lite for a simpler presentation. In my (three) examples so far the extra guardians haven't been a huge burden because they've seen the eliminations directly. However, your recent example demonstrates that they can complicate things, so the corresponding BUG-Lite with fewer guardians is definitely better. My only concern is that it seems unintuitive to call such a huge pattern BUG-Lite when it's actually anything but. Maybe BUG-Heavy?

If the full HBUG is used for presentation, then I think it might be clearer to say "(H)BUG+n+k" as per your suggestion. In that case it could be agreed that showing the chains for the k-guardians would be optional, resulting in the same effect as the BUG-Lite. I guess the only reason to do that instead of using the BUG-Lite directly is if one wants to show how it was found. I still think the HBUG-idea could make finding such huge BUG-Lites easier, but it could just be a bias because I didn't realize the connection before you said it.

[SpAce]

Hi again blue,

I think there's actually a way to get the best of both worlds. It's been clear all along that some of the guardians in the full HBUG are redundant, which is rectified by the BUG-Lite approach. However, it's not the only way to do it, and doesn't always result in the simplest chain(s) either. If the equivalent guardians are identified, which is pretty easy, we can pick any combination of them that produces the simplest solution -- just like we can choose internals/externals in other DPs. In fact, I think the guardians in the "placement" cells can be considered kind of externals to the corresponding BUG-Lite. Examples:

Ex1. July 22, 2019:

Code: Select all

.-----------------.----------.------------.
| 69+7  14+79  17 | 2  46  5 | 39  8   37 |
| 2     49     5  | 7  8   3 | 1   49  6  |
| 6-7   8      3  | 9  46  1 | 2   45  57 |
:-----------------+----------+------------:
| 1     23     6  | 4  5   9 | 8   7   23 |
| 59    29     8  | 1  3   7 | 4   6   25 |
| 57+3  37     4  | 8  2   6 | 35  1   9  |
:-----------------+----------+------------:
| 8     5      2  | 6  9   4 | 7   3   1  |
| 3#7   17+3   9  | 5  17  8 | 6   2   4  |
| 4     6      17 | 3  17  2 | 59  59  8  |
'-----------------'----------'------------'

Here the equivalence is: +3r6c1|+3r8c2 <-> #7r8c1. No need to use them both. Mixed:

(7)r1c12,r8c1 == (92)r15c2 - (2=57)r53c9 => -7 r3c1; stte

(...which is exactly what I wrote originally, but with a different justification.)

Ex 2. September 24, 2019 (this thread)

Code: Select all

.-----------------------.------------.-----------.
|   12      6      5    | 7   9   3  | 12  4   8 |
|   8       12     7    | 46  12  46 | 9   3   5 |
|   3       9      4    | 5   12  8  | 12  6   7 |
:-----------------------+------------+-----------:
|   9-2     8      6    | 12  5   19 | 4   7   3 |
| ab49+12  b24+1  a1#2  | 8   3   7  | 5   29  6 |
|   5       7      3    | 26  4   69 | 8   29  1 |
:-----------------------+------------+-----------:
|   7       5      8    | 9   6   2  | 3   1   4 |
|   6       14     9    | 3   8   14 | 7   5   2 |
|  a14+2    3     b2#1  | 14  7   5  | 6   8   9 |
'-----------------------'------------'-----------'

Equivalences: +1r5c12 <-> #2r5c3; +2r9c1 <-> #1r9c3. Again, we can pick one or the other from both. Mixed:

(2)r59c1 == (2)r5c3 => -2 r4c1

That's even shorter than your BUG-Lite.

Ex 3. September 25, 2019 (mine):

Code: Select all

.--------------.---------------------.----------------.
| 8  47   5    |  6      2      1    | b49+7   3   79 |
| 3  1    2    |  47+8  a8#4    9    |  47     6   5  |
| 6  47   9    |  5      3      7-4  |  8      2   1  |
:--------------+---------------------+----------------:
| 5  2   c34+8 | c48+7   9     a67+4 |  1     c78  36 |
| 7  69   48   |  1      46+8   3    |  5      89  2  |
| 1  69   38   |  78     5      2    |  79     4   36 |
:--------------+---------------------+----------------:
| 4  8    6    |  3      1      5    |  2      79  79 |
| 9  5    7    |  2      46     46   |  3      1   8  |
| 2  3    1    |  9      7      8    |  6      5   4  |
'--------------'---------------------'----------------'

Equivalence: 8r2c4|8r5c5 <-> 4r2c5. That doesn't help all that much, but it does shave off one branch:

Code: Select all

a: (4)r2c5,r4c6
   ||
b: (7)r1c7 - r6c7 = r6c4 - (7=64)r48c6
   ||
c: (87)r4c348 - (7=64)r48c6

=> -4 r3c6; stte

Ex 4. September 25, 2019 (yours)

Code: Select all

+-------------+------------------+-----------------+
| 8  47  5    | 6     2     1    | 49+7  3     9-7 |
| 3  1   2    | 78+4  48    9    | 47    6     5   |
| 6  47  9    | 5     3     47   | 8     2     1   |
+-------------+------------------+-----------------+
| 5  2   38+4 | 4#78  9     67+4 | 1     78    36  |
| 7  69  4#8  | 1     68+4  3    | 5     89    2   |
| 1  69  38   | 78    5     2    | 79    4     36  |
+-------------+------------------+-----------------+
| 4  8   6    | 3     1     5    | 2     79    79  |
| 9  5   7    | 2     46    46   | 3     1     8   |
| 2  3   1    | 9     7     8    | 6     5     4   |
+-------------+------------------+-----------------+

Equivalences: +4r2c4|+4r5c5|+4r4c36 <-> #(7|8)r4c4; +4r4c3|+4r5c5 <-> #8r5c3. Here it seems simplest to use the "internals" only, as you did with the BUG-Lite:

(7)r1c7 == (4)r2c4,r4c36,r5c5 - r4c4 = (4,7)r2c47 => -7 r1c9,r6c7

"Externals":

(7)r1c7 == (7|8)r4c4|(8,4)r5c35 - (4)r4c4 = (4,7)r2c47 => -7 r1c9,r6c7

Mixed:

(7)r1c7 == (7|8)r4c4|(4)r4c3,r5c5 - (4)r4c4 = (4,7)r2c47 => -7 r1c9,r6c7

--

What do you think? Have I stepped on any mines?

[blue]

Hi SpAce,

Just a couple of quick notes, on my way out the door ...

What do you think? Have I stepped on any mines?

No ... looks good ... looks very interesting !
I've always been curious about the idea of "external guardians" for (large) BUG-Lites.

Sorry I haven't found time to reply your last 3 posts on this topic.
I'll do better this weekend, I promise.

Cheers,
Blue.

[SpAce]

No ... looks good ... looks very interesting !
I've always been curious about the idea of "external guardians" for (large) BUG-Lites.

That's encouraging! Looking forward to hearing if you find any real use for it.

Sorry I haven't found time to reply your last 3 posts on this topic.

No problem, I've been busy too!