claudiarabia wrote:You have this BUG also with 3 cells with 3candidates or 4. They form a naked quad or even quint then, leaving other cells in-line with a single candidate. This is the BUG3-principle.

I've never heard of a "BUG3-principle." Do you have link to where that terminology might have originated?

I also was confused about the BUG Type 3. This BUG appears rather seldom. It's solution lays always in one line. (If somebody shows me an example with a box I take this back). In this line (column or row), in our example column 7, you have at least two cells with three candidates, disturbing the BUG-symmetry. BUG-Symmetrie means, that in every line and in every box every candidate has to appear exactly twice and every cell has 2 candidates.

You single out now the two Candidates disturbing the BUG-symmetry. In your case these are the 7 in r2c7 and the 8 in r6c7. These two candidates form together with another cell of the respective column, here with r7c7, a naked triplet. By this method r1c7 and r5c7 stay with one candidate only. The rest is placing singles.

Mike Barker wrote:Most anything you can do with a Unique Rectangle you can do with a BUG (and more since BUGs are bigger). Links for several threads discussing BUGs are found in the Collection of Solving Techniques. Check out the UR links as well (especially for the basic four types). Examples can be found in the Local Zoo.

In light of this and Claudiarabia's example, I can see the analogies. I guess part of it is that while I understand the theory behind UR and even BUGs, I never find myself with a Type 3 situation with either. While I find situations that are close to being a Type 3 UR, I never have enough to actually have a Type 3 and instead usually end up with Type 4 UR's or utilizing forcing chains to make eliminations. With BUGs, I rarely look at analogies (except with BUG-lites) to UR's and instead look at forcing chains to make eliminations.

I am usually doing these puzzles by hand, so I often wait until I am down to about 3 or 4 poly-valued cells to even try utilizing the BUG. So, generally I don't really think much about the URs or BUGs in terms of a type. Heck, I don't even look at the AURs much differently.

Thanks for pointing out the links. I enjoy using the examples as I learn more from them, and it is easier than just doing puzzles hoping that examples will show up.

I was reading through this thread yesterday (before I had asked about the Types of BUGs) and saw the example that had the + candidate for the BUG in a bi-valued cell rather than the tri-valued cell.

I wish I would have noticed that sooner, as I ran across a puzzle the other day that came down to an apparent BUG+2 situation (2 poly-valued cells). However, neither of the cells could be reduced to create a BUG. It turned out that the BUG candidates were actually in bi-value cells in the same block (for each case). Working with those two cells solved the puzzle.

I'm not sure that the situation is common, but I think I ran into it one other time in a BUG+1 situation. I wish I would have kept the puzzles, and will keep track of it the next time I run into that situation.

The key observation I make is that the polyvalued cell does not have a number that shows up 3 times in its r/c/b (perhaps in 2 units but not all 3 units). That usually draws me to another cell in the block that has the number with the most potential to be the + candidate (perhaps it showed up 3 times in 2 of the units).

So, while the Poly-valued cell couldn't be BUG reduced, a buddy cell could be (i.e. the Poly-valued cell helped, just indirectly).

emalvick wrote:I'm not sure that the situation is common, but I think I ran into it one other time in a BUG+1 situation. I wish I would have kept the puzzles, and will keep track of it the next time I run into that situation.

The key observation I make is that the polyvalued cell does not have a number that shows up 3 times in its r/c/b (perhaps in 2 units but not all 3 units). That usually draws me to another cell in the block that has the number with the most potential to be the + candidate (perhaps it showed up 3 times in 2 of the units).

So, while the Poly-valued cell couldn't be BUG reduced, a buddy cell could be (i.e. the Poly-valued cell helped, just indirectly).

I do understand that (and that discussion was the case I was thinking of), and the situation I had may not have been a BUG+1, which is why I stated apparent BUG. This where what I observed was interesting as one of the bi-valued cells in the 1 polyvalued cell puzzle had 3 of one of its possiblities in its row, column, and block (same block and row as the polyvalued cell). This number turned out to be the correct answer. Is this a coincidence? I wish I still had the puzzle to check it out.

The other puzzle I referred to (the 2 polyvalued case, an apparent BUG+2) had the same thing happen. a buddy cell for each one had the 3 candidates in each row, col, and box. One of those was correct. I used a forcing chain to reduce a common cell under the assumption that one of the extra candidates had to be correct.

Unfortunately, I hadn't read the thread you just pointed to beforehand, or I would have saved both puzzles. It seems likely that in each of the cases, using the value that was not the extra candidate would have produced a BUG grid, which probably explains how I got the correct solution even though the grids were not technically BUGs to begin with (i.e. we don't want to put the puzzle into a BUG state).

emalvick"][quote="ronk wrote:It seems likely that in each of the cases, using the value that was not the extra candidate would have produced a BUG grid, which probably explains how I got the correct solution even though the grids were not technically BUGs to begin with (i.e. we don't want to put the puzzle into a BUG state).

There are many situations looking buglike but aren't. Of couse you can avoid it, when you eliminate candidates in the bi-value-cells. Experience showed that the candidates in the poly-valued cells, whose reduction leads to the BUG-pattern are mostly easier to eradicate with short forcing chains then the ones in the bi-value-cells. For them you need usually longer and more complicate chains, a brute step. These are two methods of solving a puzzle.

claudiarabia wrote:There are many situations looking buglike but aren't. Of couse you can avoid it, when you eliminate candidates in the bi-value-cells. Experience showed that the candidates in the poly-valued cells, whose reduction leads to the BUG-pattern are mostly easier to eradicate with short forcing chains then the ones in the bi-value-cells. For them you need usually longer and more complicate chains, a brute step. These are two methods of solving a puzzle.

Claudia

Since I am usually working by hand, I usually don't like using long complicated frames. Unfortunately, I didn't think much about what I was doing when I utilized the concepts from a true BUG+1 for the bi-valued cells (i.e. looked for the number in 3 r/c/b). It happened to work, and I can only guess that it worked because the other number probably would have created a BUG.

You know, part of the reason I've been trying to really understand the whole BUG and UR (and AUR) concepts is that I am trying to avoid having to use too complicated chains since I am working things by hand. What this whole pseudo-BUG situation has taught me is that my method (although it worked) is not sound. I will, however, observe its behavior should the situation come up again. I do believe there is something there with the bi-valued cell having the extra candidate, and I'll see if it leads anywhere when I get it next time (and whether it makes sense).

With non-forcing chain techniques and a Turbot fish, which eliminates the candidate 8 in r1c5 you get a BUG Type 4 which is connected with a BUG Type 1 afterwards.This is the first puzzle I saw with this constellation and it is also the first in which I spotted 4 candidates in a bug-cell.

BUG4: Cells r9c58 are the two BUG-cells. BUG Type 4 always has it's BUG-center-cells in one row as BUG type 3 has. We need the 1 in these two cells because row 9 needs a one. 7 and 8 in r9c5 and 5 in r9c8, who show up three times in lines and boxes, have to remain too because they avoid the deadly pattern. Only the 5 in r9c5 and the 6 in r9c8 can be eliminated.

A nice BUG type 1 easy to solve by placing 8 in cell r9c5 as the only number showing up thrice in each connected line and it's box. Creating that puzzle was it worth spending the German night in front of the computer.

BUG4: Cells r9c58 are the two BUG-cells. BUG Type 4 always has it's BUG-center-cells in one row as BUG type 3 has. We need the 1 in these two cells because row 9 needs a one. 7 and 8 in r9c5 and 5 in r9c8, who show up three times in lines and boxes, have to remain too because they avoid the deadly pattern. Only the 5 in r9c5 and the 6 in r9c8 can be eliminated.

Very nice example, but I'm not aware of a "BUG Type 4" definition. Would you please point me to a source

For some time, it was customary on this thread to illustrate the non-BUG candidates as "xy+a...", as in the grid below. "xy" denotes the BUG candidates and "+a..." the one or more non-BUG candidates.

ronk wrote:[For some time, it was customary on this thread to illustrate the non-BUG candidates as "xy+a...", as in the grid below. "xy" denotes the BUG candidates and "+a..." the one or more non-BUG candidates.

Then, to avoid the Bivalue Universal Grave, at least one of (r9c5=7 or r9c5=8) and r9c8=5 must be true. All three cases imply r9c5<>5.

You are totally right. I will follow this notation in future. A definition of BUG 4 you find in the Explainer. That the two BUG Type4-Cells with the extra candidates are always in one line is my observation. I wonder if there are examples where the BUG-Center-cells are in one box. If somebody brings me an example I will rectify my assumption.

Today I made a puzzle in which I originally wanted to produce through highly symmetrical placement of numbers some cycles. This sudoku SE 9.0 ends up according to the Explainer in a BUG Type 2 which is easily transformed into a final BUG Type 1-situation.

Here the BUG Type 2-pattern. If all the 3 in r4c6, r7c6 and r8c3 would be missing, then you would have the Bivalue Grave, highly symmetric, but without a solution. So at least on the the three 3s has to remain in the grid. Regardless, which of the three 3s will stay, each of them eliminate the 3 in r8c6. Placing the 6 into r8c6 and afterwards in r7c3 you will have the final BUG Type 1-Situation below:

claudiarabia wrote:Today I made a puzzle in which I originally wanted to produce through highly symmetrical placement of numbers some cycles. This sudoku SE 9.0 ends up according to the Explainer in a BUG Type 2 which is easily transformed into a final BUG Type 1-situation.

Here the BUG Type 2-pattern. If all the 3 in r4c6, r7c6 and r8c3 would be missing, then you would have the Bivalue Grave, highly symmetric, but without a solution. So at least on the the three 3s has to remain in the grid. Regardless, which of the three 3s will stay, each of them eliminate the 3 in r8c6. Placing the 6 into r8c6 and afterwards in r7c3 you will have the final BUG Type 1-Situation below:

Alternatively, you can note that if r4c3=3, then r5c6=3 and this will again give a BUG situation. Therefore, r4c3=8, solving the puzzle.