The New Sudoku Players' Forum

[rjamil]

Hi SpAce,

PS. Please start using the standard terminology I outlined in the previous post. It makes communication easier and more accurate. Thanks.

Allow me to correct my terminology accordingly. Thanks.

I'll study your extensively about BUG+n replies and come back shortly.
Till then, be patience and accept apology if I hurt you indirectly/unintentionally.

R. Jamil

[SpAce]

I'll study your extensively about BUG+n replies and come back shortly.
Till then, be patience and accept apology if I hurt you indirectly/unintentionally.

Oh no, you haven't. Sorry if anything I said seemed to imply otherwise. I only hope I can be of assistance! That's why I insist on the common terminology, because else we probably can't avoid misunderstandings at both ends.

[rjamil]

Hi SpAce,

Thanks for your kind consideration.

Meanwhile, I have onetwo more wild (or may be dumb) questions in my mind. Hope you won't mind to answer.

If BUG+n condition fall. And if one of the guardian cell contain more than one guardians, then is it safe to remove BUG candidates (bi-values) from that guardian cell?

[Added] If the Karaken/chain move are formed based on assumption that either one or all of the guardian cell(s) may contain guardian value, but not sure about which guardian cell contain (one of the) guardian value, then …
Why not that move be called T&E Kraken/chain move? (Basically, I am considering BUG+n move as pattern based move.)

BTW, I have taken BUG-cell and BUG-value naming from your post (wrongly). However, now replace the same with guardian cell and guardian in to my dictionary accordingly. (How about guardian cell, BUG value and guardian value naming?)

Now let be concentrate with BUG+3 (or BUG+2) for the moment. Why it is consider to be more complex moves (like Kraken, chains, etc,) when, in most of the cases, all three guardian cells contain guardian value in solution (of course, I do agree that, not for all cases.)?

According to my observation, just pick a guardian value and build its corresponding guarding cells. The guardian value may be eliminated from all guardian cells common peer/buddy cells, without going further applying to some more complex moves? (However, this may not be include all possible eliminations but essential exclusions may be enough to crack the puzzle to either stte or btte solution.)

Note: Actually, I am thinking about BUG+n move slowly.

R. Jamil

[SpAce]

Hi rjamil,

Sorry about the delay in responding.

Meanwhile, I have onetwo more wild (or may be dumb) questions in my mind. Hope you won't mind to answer.

Of course not. I just hope I can.

If BUG+n condition fall. And if one of the guardian cell contain more than one guardians, then is it safe to remove BUG candidates (bi-values) from that guardian cell?

If you have a confirmed BUG+n situation and exactly one guardian cell which holds multiple guardians (i.e. all of them), then yes, it is safe to eliminate all the other candidates (BUG candidates) from it because all of the guardians see them. It's like BUG+1 generalized (because in BUG+1 the sole guardian also eliminates all the other candidates from its cell). However, I'm not sure if that can ever happen in a real grid. I think all situations with just one guardian-cell must be BUG+1s, but I can't be sure. Do you have an example in mind? In any case, your logic is valid in theory, even if it can't happen in a real grid. It's basically minimal kraken logic.

[Added] If the Karaken/chain move are formed based on assumption that either one or all of the guardian cell(s) may contain guardian value, but not sure about which guardian cell contain (one of the) guardian value, then …
Why not that move be called T&E Kraken/chain move? (Basically, I am considering BUG+n move as pattern based move.)

I'm not exactly sure what you're asking. In any case, a proper BUG+n move is not T&E, and neither is any other kraken type of move (including AICs which can be seen as two-way krakens, i.e. the simplest kind). They prove derived verities, i.e. truths that hold under all possible cases, based on known starting facts, i.e. premises. What are those starting facts in a BUG+n situation? Let's enumerate them, and use a BUG+3 as an example:

1. Assumption: You know the puzzle is valid (i.e. has exactly one solution), because you trust your puzzle provider or have used software to check that.
2. Fact: A BUG+0 pattern can never occur in a valid puzzle, because it would mean that it has either 0 or (at least?) 2 solutions.
3. Derived: 1..2 -> You know that a BUG+0 pattern can't occur in this puzzle.
4. Assumption: You recognize that if certain candidates (a & b & c) were removed, you would have a BUG+0 pattern.
5. Derived: 4 -> You have a BUG+3 situation with (a, b, c) as the guardians.
6. Derived: 3..5 -> You know that at least one of the three guardians (a | b | c) must be true in the solution. You don't know which one(s), though, and there's no easy way to figure it out (so don't even try).
7. Fact: True candidates can't imply falsehoods.
8. Fact: False candidates can imply anything.
9. Derived: 6..8 -> If you find a common conclusion (e.g. an elimination) with which all three guardians (a & b & c) can agree, either directly or via chains, it must be valid. The reason is that since at least one of them must be true, and true candidates can't lie, the agreed implication can't be a falsehood. Hence it must be true, and the agreed target candidate can be eliminated.
10. Fact: The logic in step 9 is a verity. No T&E whatsoever involved. It starts with known facts and derives new facts based on them, resulting in a verifiable conclusion. No assumptions or trials are made at any step.
11. Fact: If you reverse the process and assume the eliminated candidate to be true, it will eliminate all three guardians (a & b & c) which results in a BUG+0 pattern, i.e. a contradiction (because as per step 3 you know it can't exist in this puzzle). Thus you know the assumption must be false, and the assumed candidate can be eliminated.
12. Fact: The logic in step 11 is T&E. It starts with an assumption and ends in a contradiction (if you're lucky). It's the exact opposite of the logic in step 9.
13. Derived: 9..12 -> Verity proofs and T&E are two very different, though intimately related, approaches. In fact they're exact opposites of each other. Both result in the same conclusion, because they're two sides of the same coin.
14. Fact: Verity proofs are considered more elegant. Many solvers think they're more fun to find too.

BTW, I have taken BUG-cell and BUG-value naming from your post (wrongly).

Touché Even my own posts can be obsolete, even if they're not that ancient. In fact, it would be pretty sad if they weren't, as that would indicate a total lack of progress on my part.

However, now replace the same with guardian cell and guardian in to my dictionary accordingly.
(How about guardian cell, BUG value and guardian value naming?)

I don't know what you mean by "value". A digit? A candidate? Remember that a digit and a candidate are two different things, so they should be normally distinguished. Only in a single cell they're basically the same because it can't hold but a single candidate of each digit. In any other context, say a row, column, box, locked set, etc, they're very different concepts because a single digit can have many candidates.

Now let be concentrate with BUG+3 (or BUG+2) for the moment. Why it is consider to be more complex moves (like Kraken, chains, etc,) when, in most of the cases, all three guardian cells contain guardian value in solution (of course, I do agree that, not for all cases.)?

Because if you start trusting and acting on assumed probabilities, you're guessing. Some may think it's a valid way to solve sudokus (and in a speed solving contest it might very well be), but it's not our way. If you want to play with probabilities, try poker. It's actually a much more complex game than sudoku, because most of the information is hidden and you actually have to make educated guesses. In sudoku you have all the facts right before you, so you can always make exact deductions without ever having to guess.

According to my observation, just pick a guardian value and build its corresponding guarding cells. The guardian value may be eliminated from all guardian cells common peer/buddy cells, without going further applying to some more complex moves? (However, this may not be include all possible eliminations but essential exclusions may be enough to crack the puzzle to either stte or btte solution.)

I'm not really sure what you're saying/asking. The only situation where you can eliminate anything based on just one guardian is BUG+1. In all other cases you must find a consensus between all of the guardians.

[rjamil]

Hi SpAce,

Sorry for replying late and partially due trap on Ali Baba and the forty Thieves oil jars.

I was studying BUG+n from here.

It looks to me simple but need more explanation due language barrier and first time trying to understand the same.

R. Jamil

[SpAce]

Hi rjamil,

I was studying BUG+n from here.

I didn't read the discussion, but here's my BUG solution for the first puzzle:

Code: Select all

.---------------------------.-----------.-----------.
| 7      2         69       | 5   3  69 | 8  1   4  |
| 89   cd46+89     5        | 1   2  48 | 3  69  7  |
| 1      3         48       | 69  7  48 | 5  69  2  |
:---------------------------+-----------+-----------:
| 6      1         2        | 8   4  5  | 9  7   3  |
| 5      47        47       | 3   9  1  | 6  2   8  |
| 3      89        89       | 7   6  2  | 1  4   5  |
:---------------------------+-----------+-----------:
| 89  ace78+(6)9  a7[+89]-6 | 4   1  3  | 2  5   69 |
| 4   be(6)9       3        | 2   5  69 | 7  8   1  |
| 2      5         1        | 69  8  7  | 4  3   69 |
'---------------------------'-----------'-----------'

BUG+6

Code: Select all

(6)r7c2
||
(8)r7c3
||
(9)r7c3
||
(9)r2c2 - (9=6)r8c2
||
(9)r7c2 - (9=6)r8c2
||
(8-6)r2c2 = (6)r78c2

=> -6 r7c3; stte

Even though it's a BUG+6 (pretty big), it's really easy (took me less than 10 minutes total). The reason is that three of the guardians see my chosen elimination directly (89r7c3 via cell and 6r7c2 via box/row), and the other three with extremely short chains (two of which are in fact identical). In total I need only one extra cell (r8c2) for chaining, all the rest happens in the guardian cells. Such simplicity with a BUG+6 is pretty rare. Thanks for this specimen! (I haven't checked if there might be even simpler BUG-based eliminations, but I kind of doubt it.)

Because of that simplicity, it can also be written as an AIC easily. That's also rare with a BUG+6:

(6)r7c2|(8|9)r7c3 == [(6=9)r8c2 - r27c2 == (8-6)r2c2 = (6)r78c2] => -6 r7c3; stte

(Btw, the group node (6)r78c2 could be replaced with the simpler single cell (6)r1c3, but I wanted to use as few cells as possible. I use the other option in the compressed chain below.)

compressed: Show

(6)r7c2|(8|9)r7c3 == [(6,9)r8,27c2 == (86)b1p53] => -6 r7c3; stte

Btw, the May 28 puzzle has a BUG+6 too. It's much more complicated, though. However, it can be easily reduced to a simpler BUG+3 with a loop. That gives a relatively nice two-step solution. I can write both of those as examples in that thread.

Added. I just briefly looked at the discussion... I don't recommend even reading that! I don't know how they could make such a simple thing sound so complicated. Very obsolete terminology too. (That said, let's not forget that it was 2005. These kinds of things probably weren't as self-evident for anyone as they are today. So, I definitely don't mean any disrespect towards anyone. On the contrary, I'm grateful for the efforts of the pioneers.)

[rjamil]

Hi SpAce,

Well, I am trying to avoid complexity of BUG+n move and studying simplicity like this one.

(Actually, I am digging the post that I read about BUG+n long ago, which looks almost like the one sharing above. But, due to not interested at that time, not bookmarked that post.)

Here is the above mentioned puzzle state:

Code: Select all

 +-------------+-------------+--------------+
 | 15   6    9 | 2    3    4 | 7    8    15 |
 | 24+1 17+4 3 | 5    79   8 | 6    29   14 |
 | 25+4 47   8 | 6    79   1 | 29   3    45 |
 +-------------+-------------+--------------+
 | 3    5    7 | 1    2    6 | 8    4    9  |
 | 6    9    1 | 8    4    7 | 3    5    2  |
 | 8    2    4 | 9    5    3 | 1    6    7  |
 +-------------+-------------+--------------+
 | 7    14   5 | 3    6    9 | 24   12   8  |
 | 14   3    2 | 7    8    5 | 49   19   6  |
 | 9    8    6 | 4    1    2 | 5    7    3  |
 +-------------+-------------+--------------+

According to what I need to know about BUG+n move is that:
After detecting BUG-cell(s) and its guardian(s), is there any simple way to eliminate some/all BUG-value(s) from BUG-cell(s) (so that the puzzle crack enough to solve, not necessary but, with either stte or btte only)?

What I understand from above scenario is that:
1) Lets build the BUG-cells against each guardians:
a) 1 in r2c1; and
b) 4 in r2c2 and r3c1.

Now check each guardian, if it is present in remaining BUG-cell's BUG-value then remove that guardian from remaining BUG-cell's BUG-value.
In above case guardian 1 is present in r2c1, and it sees remaining BUG-cells, i.e., r2c2 and r3c1. But only one BUG cell contain 1 as BUG-value, so is it safe to remove from r2c2?
Now check guardian 4 is present in r2c2 and r3c1; and both sees r2c1; and it contains 4 as BUG-value. It is safe to remove 4 from BUG-cell r2c1.

Note that, in my Sudoku-dictionary, clue means given; value means candidate (except for Locked candidate name), digit means number, and so on.

Added. I just briefly looked at the discussion... I don't recommend even reading that! I don't know how they could make such a simple thing sound so complicated. Very obsolete terminology too. (That said, let's not forget that it was 2005. These kinds of things probably weren't as self-evident for anyone as they are today. So, I definitely don't mean any disrespect towards anyone. On the contrary, I'm grateful for the efforts of the pioneers.)

I am trying to revive some oldies.

R. Jamil

[SpAce]

grid: Show

Code: Select all

 +-------------+-------------+--------------+
 | 15   6    9 | 2    3    4 | 7    8    15 |
 | 24+1 17+4 3 | 5    79   8 | 6    29   14 |
 | 25+4 47   8 | 6    79   1 | 29   3    45 |
 +-------------+-------------+--------------+
 | 3    5    7 | 1    2    6 | 8    4    9  |
 | 6    9    1 | 8    4    7 | 3    5    2  |
 | 8    2    4 | 9    5    3 | 1    6    7  |
 +-------------+-------------+--------------+
 | 7    14   5 | 3    6    9 | 24   12   8  |
 | 14   3    2 | 7    8    5 | 49   19   6  |
 | 9    8    6 | 4    1    2 | 5    7    3  |
 +-------------+-------------+--------------+

According to what I need to know about BUG+n move is that:
After detecting BUG-cell(s) and its guardian(s), is there any simple way to eliminate some/all BUG-value(s) from BUG-cell(s) (so that the puzzle crack enough to solve, not necessary but, with either stte or btte only)?

It depends on the situation. If there's a candidate that ALL of the guardians see, then it can be eliminated. It doesn't matter if it's in one of the guardian cells or not; the logic is the same either way. In your example there is such a candidate and it happens to be in a guardian cell: 4r2c1. It can be eliminated because all three guardians see it. Just like ronk wrote:

From the BUG+3 we know that at least one of r2c1=1, r2c2=4 and r3c1=4 must be true. Each individually true implies r2c1<>4.

That's all there is to it. There's no simpler or more complicated logic to solve BUGs. It's always the same: you must prove the same elimination with each guardian. Otherwise the logic is not valid (even if the elimination happens to be correct).

What I understand from above scenario is that:
1) Lets build the BUG-cells against each guardians:
a) 1 in r2c1; and
b) 4 in r2c2 and r3c1.

Correct so far (except I'd rather call those 'guardian cells' instead of 'BUG cells'). Note that in that one post of mine you mentioned as a source for your terms, I called them 'BUG+ cells' which is more descriptive because the + implies the presence of at least one guardian; i.e. it's a synonym for a 'guardian cell'. On the other hand, 'BUG cell' could be any unsolved cell in the grid, so it's an ambiguous term.

Now check each guardian, if it is present in remaining BUG-cell's BUG-value then remove that guardian from remaining BUG-cell's BUG-value.

I don't know where you found that piece of logic, but it's incorrect (if I even understand it). The only valid eliminations in any situation are those candidates that are seen by every guardian, either directly or via a chain. It doesn't matter where they are. It's the one and only logic that is applicable in a BUG situation. Forget anything else. There are no simpler tricks, nor are they needed, because that simple piece of logic covers every situation.

It's inefficient and error-prone to try build a catalogue of special cases, when a single simple rule works in all cases. It's trivial to check if all guardians see a candidate directly. It only gets more difficult if you want to eliminate a candidate that is not directly visible to all (or any) of the guardians because then you need chains. On the other hand, any directly visible eliminations are extremely easy. Don't make it more complicated than it is.

In above case guardian 1 is present in r2c1, and it sees remaining BUG-cells, i.e., r2c2 and r3c1. But only one BUG cell contain 1 as BUG-value, so is it safe to remove from r2c2?

No. The guardian 4r3c1 doesn't see it directly. 1r2c1 and 4r2c2 do, but once more: they ALL need to see the elimination. The only way to eliminate 1r2c2 here with BUG logic is to build a chain from 4r3c1 to a remote candidate that does see 1r2c2. For example:

Code: Select all

.-------------------.-----------.-------------.
|  15      6      9 | 2   3   4 |  7   8   15 |
| a24+1  ah7+4-1  3 | 5  g79  8 |  6   29  14 |
| b25+4    47     8 | 6  f79  1 | e29  3   45 |
:-------------------+-----------+-------------:
|  3       5      7 | 1   2   6 |  8   4   9  |
|  6       9      1 | 8   4   7 |  3   5   2  |
|  8       2      4 | 9   5   3 |  1   6   7  |
:-------------------+-----------+-------------:
|  7       14     5 | 3   6   9 |  24  12  8  |
| c14      3      2 | 7   8   5 | d49  19  6  |
|  9       8      6 | 4   1   2 |  5   7   3  |
'-------------------'-----------'-------------'

(1)r2c1
||
(4)r2c2
||
(4)r3c1 - r8c1 = (4-9)r8c7 = r3c7 - (9=7)r3c5 - r2c5 = (7)r2c2

=> -1 r2c2; stte

That chain proves that 4r3c1 -> 7r2c2. Since 7r2c2 sees 1r2c2 (same cell), the latter can be eliminated, because the other two guardians see it directly (same box or cell).

Remember that the BUG logic only guarantees that at least one of the guardians is true. It means that any single guardian can be false (except in BUG+1) so we can't trust their individual implications at all. In fact, all but one of them can be false (like in this case: only 4r2c2 is a true candidate, but we can't know that in advance). That's why the only valid logic is one that looks at the implications of all guardians at the same time to find where they agree. Only those eliminations can be accepted.

Think it this way. What happens if the only true guardian is 4r3c1 (as it could be because you just don't know)? It would (most simply) imply that r2c2=1. Yet you were just about to eliminate it! That should wake you up to the fact that you can't act on any individual implications (or even combined implications up to N-1) because you can't know if they're true or false. What does it mean in this case that we find a different chain from 4r3c1 that implies the opposite conclusion r2c2<>1? It doesn't mean anything individually either.

However, if we find both of those contradictory implications for 4r3c1 we do know that it (4r3c1) must be false and can be eliminated (that's T&E). It would leave a BUG+2 with just 1r2c1 and 4r2c2 as guardians. Since they both see 1r2c2, it can now be eliminated without any chains. That's one way to simplify BUG situations by reducing guardians, but like I said, if you're going to use T&E you could do it more efficiently by testing and eliminating non-guardians.

Now check guardian 4 is present in r2c2 and r3c1; and both sees r2c1; and it contains 4 as BUG-value. It is safe to remove 4 from BUG-cell r2c1.

Yes, but not with that logic. Again, you only mention 2/3 guardians, and that's not enough for any elimination. You need all 3/3 to agree. No exceptions, ever. In this case that's possible, however, because 1r2c1 also sees 4r2c1 (same cell) so the latter can be eliminated directly (but it's a pretty useless elimination).

Note that, in my dictionary, clue means given; value means candidate (except for Locked candidate name) and so on.

I wish you used "candidate" instead of "value" to avoid confusion, but it's up to you.

[rjamil]

Hi SpAce,

Is this post helps to convey my point of view?

Finally, I dug my desired post.

R. Jamil

[SpAce]

Hi rjamil,

Is this post helps to convey my point of view?

Yes, it does. Sorry to say, but you've misunderstood RW's beautiful logic which only works in a specific BUG+2 situation where the two guardians are different digits, the two guardian cells see each other (are in the same unit), and at least one guardian cell has the opposite guardian digit as a candidate. It's still based on the same simple principle I've now mentioned a million times. Nothing new, except a very elegant application of it. That trick is surely nice to know, but it can't (edit: actually it can) be generalized to BUG+(N>2) situations like you tried to do earlier (edit: with that qualifier it's still true). On the other hand, the general rule works everywhere, including here.

Code: Select all

.------------------.------------.------------.
| 8   5      79    | 17  4   19 | 6   3   2  |
| 3   6      29    | 28  5   89 | 7   1   4  |
| 1   27     4     | 3   27  6  | 5   89  89 |
:------------------+------------+------------:
| 79  28     3     | 6   1   5  | 4   27  89 |
| 4   1      28    | 9   3   7  | 28  6   5  |
| 6   79     5     | 4   8   2  | 3   79  1  |
:------------------+------------+------------:
| 79  9+7-8  6     | 5   27  4  | 1   28  3  |
| 5   3      1+8-7 | 27  9   18 | 28  4   6  |
| 2   4      18    | 18  6   3  | 9   5   7  |
'------------------'------------'------------'

BUG+2:

(7)r7c2 == (8)r8c3 => -7r8c3, -8 r7c2

The reason why that works is explained here (though not very well). It's basic AIC logic, though possibly the most unintuitive kind. Here the chain just happens to be as short as possible (only one strong link).

Think it this way. As usual, we know that at least one of the guardians must be true. If it's 7r7c2, it will eliminate other candidates in its cell (including 8r7c2) as well as all other 7s it sees (including 7r8c3). On the other hand, if 8r8c3 is true, it will also eliminate other candidates in its cell (including 7r8c3) as well as all other 8s it sees (including 8r7c2). In both cases both 7r8c3 and 8r7c2 will get eliminated, so they're valid eliminations.

This is an example where seeing a simple trick that works in a specific situation can lead you astray if you don't understand the fundamentals. To avoid that risk, study the fundamentals and you don't need to learn any tricks. The fundamentals of BUG logic are very simple, and I've now repeated them a million times. When are you going to start trusting me on that?

Finally, I dug my desired post.

I'm glad you did. That's certainly a very nice example! Btw, RW is probably the best BUG expert there is, so you can most likely trust anything he says. I don't think you'll find him contradicting anything I've said either.

--
Edit 1. Corrected the first paragraph to say that the guardian cells see each other (instead of the guardians themselves).
Edit2. Added the link to how the rule can be generalized.

[SpAce]

The same trick works in your previous example if it's reduced to BUG+2 by eliminating 4r3c1:

Code: Select all

.-----------------.----------.------------.
| 15     6      9 | 2  3   4 | 7   8   15 |
| 2+1-4  7+4-1  3 | 5  79  8 | 6   29  14 |
| 25     47     8 | 6  79  1 | 29  3   45 |
:-----------------+----------+------------:
| 3      5      7 | 1  2   6 | 8   4   9  |
| 6      9      1 | 8  4   7 | 3   5   2  |
| 8      2      4 | 9  5   3 | 1   6   7  |
:-----------------+----------+------------:
| 7      14     5 | 3  6   9 | 24  12  8  |
| 14     3      2 | 7  8   5 | 49  19  6  |
| 9      8      6 | 4  1   2 | 5   7   3  |
'-----------------'----------'------------'

BUG+2

(1)r2c1 == (4)r2c2 => -1r2c2, -4 r2c1; stte

That's a BUG+2 where the two guardian cells see each other, the guardians are different digits, and at least one has the other's digit in its cell (or both, like here and in the original example). In that specific situation you can eliminate either guardian digit from the opposite guardian cell (where that digit is not a guardian). That's the rule for this very specific situation if you really want to use it as such. Yet the general BUG logic yields those eliminations without memorizing it as a trick.

Note that if we eliminate 1r2c1 we get a different BUG+2 where that rule doesn't work (but the general one does, as always):

Code: Select all

.---------------.----------.------------.
| 15    6     9 | 2  3   4 | 7   8   15 |
| 2-4   17+4  3 | 5  79  8 | 6   29  14 |
| 25+4  7-4   8 | 6  79  1 | 29  3   45 |
:---------------+----------+------------:
| 3     5     7 | 1  2   6 | 8   4   9  |
| 6     9     1 | 8  4   7 | 3   5   2  |
| 8     2     4 | 9  5   3 | 1   6   7  |
:---------------+----------+------------:
| 7     14    5 | 3  6   9 | 24  12  8  |
| 14    3     2 | 7  8   5 | 49  19  6  |
| 9     8     6 | 4  1   2 | 5   7   3  |
'---------------'----------'------------'

(4)r2c2 == (4)r3c1 => -4 r2c1,r3c2; stte

Now we have a BUG+2 with the same digit (4) as both guardians. Again the guardian cells see each other, but now we can't eliminate anything from them because the actual guardians see each other as well (because they're the same digit)! Instead we can eliminate any external 4s they both see. So, that's a second specific BUG+2 rule for you, if you want to collect such tricks. (Note that with this rule neither the two guardian cells nor the guardians have to see each other. It's just coincidental in this example.) But, like I said, the same general BUG logic works here just as well as everywhere. Doesn't matter if it's a BUG+1 or a BUG+23. It always works without memorizing anything.

--
Edit. The same corrections as with the previous post, i.e. guardians -> guardian cells, in several places.

[rjamil]

Hi SpAce,

Thanks God, I finally conveyed my point of you.

Actually, I am only interested in that one type of case. If it is applicable for BUG+2 only, ok fine. I will not consider the rest of the cases for the time being.

Similarly, I am confused what you mean about "sees" in your explanation with buddy/peer (i.e., one cell is within 20 peer/buddy cells of other).

If BUG+n move alone is not producing any elimination; and rather help/support to build other move, then its beyond my current knowledge/capabilities in Sudoku.

Thanks for explaining in such detail. BTW, I see your May 28, 2020 puzzle's BUG+6 and BUG+3 solutions too. Hope it will help me to understand BUG+n later.

Just one last time, look again in to my previous BUG+3 example:

Code: Select all

 +-------------+-------------+--------------+
 | 15   6    9 | 2    3    4 | 7    8    15 |
 | 24+1 17+4 3 | 5    79   8 | 6    29   14 |
 | 25+4 47   8 | 6    79   1 | 29   3    45 |
 +-------------+-------------+--------------+
 | 3    5    7 | 1    2    6 | 8    4    9  |
 | 6    9    1 | 8    4    7 | 3    5    2  |
 | 8    2    4 | 9    5    3 | 1    6    7  |
 +-------------+-------------+--------------+
 | 7    14   5 | 3    6    9 | 24   12   8  |
 | 14   3    2 | 7    8    5 | 49   19   6  |
 | 9    8    6 | 4    1    2 | 5    7    3  |
 +-------------+-------------+--------------+

According to RW statement, why it is not possible to eliminate 4 from r2c1 when rest of the BUG+cells sees it; and 1 from r2c2 when rest of the BUG+cells sees it? (Corrected.)
Why it is possible in BUG+2 condition only?
According to two unique guardians, is it BUG+2 condition? (Confusion cleared. It depends on number of guardians, irrespective of uniqueness.)
Just to reconfirm, in BUG+n move, where 'n' represent number of either BUG+cells or guardians? (Got it, its number of guardians.)

R. Jamil

[SpAce]

Hi rjamil,

Thanks God, I finally conveyed my point of you.

Yeah, I'm glad I finally understood what you meant. Seeing RW's post was crucial. I just hope I can also convey my point to you!

Actually, I am only interested in that one type of case. If it is applicable for BUG+2 only, ok fine. I will not consider the rest of the cases for the time being.

Ok. It's definitely better than nothing. If you implement those two rules I showed (two different guardian digits in cells that see each other, or two same guardian digits in cells anywhere), you should find all BUG+2 eliminations that don't require chains.

Similarly, I am confused what you mean about "sees" in your explanation with buddy/peer (i.e., one cell is within 20 peer/buddy cells of other).

You're right to be confused! I was communicating inaccurately. It should be corrected now in both of my previous posts. Hope it gets clearer if you read them again. There's indeed a crucial difference between cells "seeing" each other and candidates "seeing" each other.

In your original BUG+3 example all three guardian cells see each other because they're all in the same unit (box 1). However, of the guardians themselves (i.e. guardian candidates) only 4r2c2 and 4r3c1 see each other. The additional requirement for candidates is that they must be the same digit in addition to being in cells that see each other (or otherwise two different digits in the same cell). The third guardian 1r2c1 doesn't see either of the other two guardians because they're different digits and not in the same cell.

What does it really mean that two candidates "see" each other? It simply means that they can't both be true (but it's possible that neither is). If one is true it will eliminate the other. In chaining terms it means that they're weakly linked. Two candidates are natively weakly linked if they see each other directly. Any other weak links are derived.

Two candidates of the same digit are natively weakly linked if they're in the same unit (row, col, box). In other words, all candidates of a single digit that are in the same unit see each other directly (only one of them can be true). Two candidates of different digits are natively weakly linked only if they're in the same cell. In other words, all candidates in a single cell see each other directly (only one of them can be true).

With chaining we can also build derived weak links between two candidates that don't see each other directly. In that case they see each other remotely, and the same rule applies: both can't be true. If more than two candidates see each other, either directly or remotely, it means that at most one of them can be true. In all cases it's possible that none of them is true, unless they're also strongly linked (i.e. at least one must be true).

If BUG+n move alone is not producing any elimination; and rather help/support to build other move, then its beyond my current knowledge/capabilities in Sudoku.

I understand. If direct eliminations aren't possible, you need chains to make all guardians "see" the same elimination. It can't of course happen until you've learned chaining in general.

Thanks for explaining in such detail.

No problem. I hope we're progressing.

Just one last time, look again in to my previous BUG+3 example:

BUG+3 grid: Show

Code: Select all

 +-------------+-------------+--------------+
 | 15   6    9 | 2    3    4 | 7    8    15 |
 | 24+1 17+4 3 | 5    79   8 | 6    29   14 |
 | 25+4 47   8 | 6    79   1 | 29   3    45 |
 +-------------+-------------+--------------+
 | 3    5    7 | 1    2    6 | 8    4    9  |
 | 6    9    1 | 8    4    7 | 3    5    2  |
 | 8    2    4 | 9    5    3 | 1    6    7  |
 +-------------+-------------+--------------+
 | 7    14   5 | 3    6    9 | 24   12   8  |
 | 14   3    2 | 7    8    5 | 49   19   6  |
 | 9    8    6 | 4    1    2 | 5    7    3  |
 +-------------+-------------+--------------+

According to RW statement, why it is not possible to eliminate 4 from r2c2 when rest of the BUG+cells sees it; and 1 from r2c3 when rest of the BUG+cells sees it?
Why it is possible in BUG+2 condition only?

Ask me again once you've read what I explained above (about the "seeing" rules) and reread my two earlier posts that I corrected (the clarified difference between candidates and cells seeing each other). Please check the cell coordinates too (there's no 1 in r2c3) so I can answer without making assumptions about what you meant.

According to two guardians, is it BUG+2 condition?
Just to reconfirm, in BUG+n move, where 'n' represent number of either BUG+cells or guardians?

Guardians. (In the old posts it can mean the number of cells, so don't get confused by that). Edit: I see you noticed that yourself already.

[SpAce]

I was slightly inaccurate also when I said that RW's rule can't be generalized to BUG+(N>2). Sure it can, but it gets weaker, as it can only eliminate a single candidate from a single cell. The simplest elimination of 4r2c1 in your original BUG+3 example is an example of that:

Code: Select all

.----------------.----------.------------.
| 15     6     9 | 2  3   4 | 7   8   15 |
| 2+1-4  17+4  3 | 5  79  8 | 6   29  14 |
| 25+4   47    8 | 6  79  1 | 29  3   45 |
:----------------+----------+------------:
| 3      5     7 | 1  2   6 | 8   4   9  |
| 6      9     1 | 8  4   7 | 3   5   2  |
| 8      2     4 | 9  5   3 | 1   6   7  |
:----------------+----------+------------:
| 7      14    5 | 3  6   9 | 24  12  8  |
| 14     3     2 | 7  8   5 | 49  19  6  |
| 9      8     6 | 4  1   2 | 5   7   3  |
'----------------'----------'------------'

(1)r2c1 == (4)b1p67 => -4 r2c1

The logic is similar to RW's in that we have exactly two different guardian digits (in this case 1 and 4) but multiple cells (there could be more than three). The rule requires that one of the two digits has only one candidate (in a single cell, obviously). In our example it's 1r2c1. That cell must see all the other guardian cells (but they don't have to see each other). If that's the case, then you can eliminate the second digit (4 in this case) from the lonely cell with the first digit, because that candidate sees all of the guardians (one through the cell, and the others through shared units because they're the same digit).

In this case it means that 4r2c1 can be eliminated, because it sees 1r2c1 (in the cell) and 4r2c2 and 4r3c1 (in the box). Since one of those must be true, 4r2c1 can't be true.

That rule could be further generalized by allowing multiple guardians (different digits obviously) in the elimination cell, as long they don't include the external guardian digit (which is to be eliminated from that cell).

Note that there's no way to use even that extended rule to eliminate 1r2c2, because it doesn't see all three guardians directly.

[SpAce]

I see you corrected the cell coordinates, so I'll answer this now:

Just one last time, look again in to my previous BUG+3 example:

Code: Select all

 +-------------+-------------+--------------+
 | 15   6    9 | 2    3    4 | 7    8    15 |
 | 24+1 17+4 3 | 5    79   8 | 6    29   14 |
 | 25+4 47   8 | 6    79   1 | 29   3    45 |
 +-------------+-------------+--------------+
 | 3    5    7 | 1    2    6 | 8    4    9  |
 | 6    9    1 | 8    4    7 | 3    5    2  |
 | 8    2    4 | 9    5    3 | 1    6    7  |
 +-------------+-------------+--------------+
 | 7    14   5 | 3    6    9 | 24   12   8  |
 | 14   3    2 | 7    8    5 | 49   19   6  |
 | 9    8    6 | 4    1    2 | 5    7    3  |
 +-------------+-------------+--------------+

According to RW statement, why it is not possible to eliminate 4 from r2c1 when rest of the BUG+cells sees it; and 1 from r2c2 when rest of the BUG+cells sees it?

I hope my previous post(s) mostly answered that already. We CAN eliminate 4r2c1 using that rule -- not because the 'BUG+ cells' see it but because all of the 'BUG+ candidates' (i.e. guardians) see it. That's been clear since the beginning. My previous post explains how that rule is related to RW's and how it can be generalized to multiple cells (and even multiple digits). It should also explain why that rule can't eliminate 1r2c2.

The systemic misunderstanding seems to be that you somehow assume that it's enough that the guardian cells see each other. Nope, not at all. All of the actual guardian candidates must see the elimination candidate. Sorry I made that problem worse by communicating inaccurately myself, but that should be fixed now in the previous posts.

It's mostly irrelevant what the cells see. We're only interested in what the candidates see. Of course the latter depends on the former, but they're not the same thing. Even if two cells see each other, most of their candidates don't -- only the ones that are the same digit. That's why 4r3c1 doesn't see 1r2c2, which means you can't eliminate the latter with a direct BUG rule.

Why it is possible in BUG+2 condition only?

The full rule (which allows two eliminations in two different cells) is only available in BUG+2, but as I explained, a slightly weaker generalized version can be used with any BUG+n>2 as well. Here too, to eliminate 4r2c1. The required conditions for that situation just get harder to achieve with bigger BUGs because more cells and candidates have to play along to get the exact pattern.