The New Sudoku Players' Forum

[ArkieTech]

Code: Select all

 *-----------*
 |...|..1|.8.|
 |.2.|..3|...|
 |..3|9..|1..|
 |---+---+---|
 |2..|...|.7.|
 |..1|.4.|9..|
 |.8.|...|..6|
 |---+---+---|
 |..5|..9|4..|
 |...|4..|.9.|
 |.7.|2..|...|
 *-----------*


Play/Print this puzzle online

[SteveG48]

Code: Select all

 *--------------------------------------------------*
 | 9    4    7    | 5    2    1    | 6    8    3    |
 | 1    2    8    | 7    6    3    | 5    4    9    |
 | 6    5    3    | 9    8    4    | 1    2    7    |
 *----------------+----------------+----------------|
 | 2    9    6    | 18   15   58   | 3    7    4    |
 | 7    3    1    | 6    4    2    | 9    5    8    |
 | 5    8    4    | 3    9    7    | 2    1    6    |
 *----------------+----------------+----------------|
 |d38   16   5    |c18   7    9    | 4    36   2    |
 | 8-3  16   2    | 4  ac135  568  | 7    9    15   |
 | 4    7    9    | 2  bc135 b56   | 8   b36   15   |
 *--------------------------------------------------*


3r8c5 = (356)r9c568 - (5=138)b8p158 - (8=3)r7c1 => -3 r8c1 ; stte

Or:

Code: Select all

 *--------------------------------------------------*
 | 9    4    7    | 5    2    1    | 6    8    3    |
 | 1    2    8    | 7    6    3    | 5    4    9    |
 | 6    5    3    | 9    8    4    | 1    2    7    |
 *----------------+----------------+----------------|
 | 2    9    6    | 18   15   58   | 3    7    4    |
 | 7    3    1    | 6    4    2    | 9    5    8    |
 | 5    8    4    | 3    9    7    | 2    1    6    |
 *----------------+----------------+----------------|
 | 38  d16   5    | 8-1  7    9    | 4   d36   2    |
 | 38   6-1  2    | 4   a135 b568  | 7    9    15   |
 | 4    7    9    | 2   b135 c56   | 8   c36   15   |
 *--------------------------------------------------*


(1r8c5 = 5b8c68)[BUG+3] - (5=36)r9c68 - (3=16)r7c28 => -1 r7c4,r8c2 ; stte

[Ngisa]

Code: Select all

+---------------+------------------+---------------+
| 9     4     7 | 5     2      1   | 6    8     3  |
| 1     2     8 | 7     6      3   | 5    4     9  |
| 6     5     3 | 9     8      4   | 1    2     7  |
+---------------+------------------+---------------+
| 2     9     6 |c18   15     d58  | 3    7     4  |
| 7     3     1 | 6     4      2   | 9    5     8  |
| 5     8     4 | 3     9      7   | 2    1     6  |
+---------------+------------------+---------------+
|a38    16    5 |b18    7      9   | 4   f6-3   2  |
| 38    16    2 | 4     135    568 | 7    9     15 |
| 4     7     9 | 2     135   d56  | 8   e36    15 |
+---------------+------------------+---------------+


(3=8)r7c1 -r7c4 = r4c4 - (8=56)r49c6 - (6)r9c8 = (6)r7c8 => - 3r7c8; stte

Clement

[SpAce]

The (more?) controversial original related to the following discussion: Show

Code: Select all

.---------------.---------------------.--------------.
| 9     4     7 | 5    2         1    | 6  8     3   |
| 1     2     8 | 7    6         3    | 5  4     9   |
| 6     5     3 | 9    8         4    | 1  2     7   |
:---------------+---------------------+--------------:
| 2     9     6 | 18   15        58   | 3  7     4   |
| 7     3     1 | 6    4         2    | 9  5     8   |
| 5     8     4 | 3    9         7    | 2  1     6   |
:---------------+---------------------+--------------:
| 38    16    5 | 18   7         9    | 4  36    2   |
| 38  d(6)-1  2 | 4   A35(+1)  dB68+5 | 7  9   B(1)5 |
| 4     7     9 | 2   c13+5     c56   | 8  36    15  |
'---------------'---------------------'--------------'

BUG+3

[1.r8c5 =BUG= 51.r8c69] =BUG= 56.r9c56 - 6.r8c(6=2) => -1 r8c2; stte

Code: Select all

.---------------.---------------------.--------------.
| 9     4     7 | 5    2         1    | 6  8     3   |
| 1     2     8 | 7    6         3    | 5  4     9   |
| 6     5     3 | 9    8         4    | 1  2     7   |
:---------------+---------------------+--------------:
| 2     9     6 | 18   15        58   | 3  7     4   |
| 7     3     1 | 6    4         2    | 9  5     8   |
| 5     8     4 | 3    9         7    | 2  1     6   |
:---------------+---------------------+--------------:
| 38    16    5 | 18   7         9    | 4  36    2   |
| 38  c(6)-1  2 | 4   a35(+1)  ca68+5 | 7  9   a(1)5 |
| 4     7     9 | 2   b13+5     b56   | 8  36    15  |
'---------------'---------------------'--------------'


(15)r8c569 =[BUG+3]= (56)r9c56 - 6r8c(6=2) => -1 r8c2; stte

Edit: Added a new (improved?) version and hid the original.

[eleven]

Very creative notation. Hope it's just a joke, i am not a fan of riddle solutions.

Normally you probably would write it as kraken (3-way) move or (similarly to Steve) as
1r8c5 =BUG= 5b8p68 - (5=6)r9c6 - r8c6 = r8c2 => -1 r8c2; stte

[SpAce]

Very creative notation. Hope it's just a joke, i am not a fan of riddle solutions.

Thanks for the honest feedback! No, it's not a joke. I'm just experimenting, and feedback like that is valuable. Which part of the notation did you hate the most? Hard to know because it had so many questionable parts Do you think it's logically incorrect or just ugly? I know it's not standard Eureka, of course, but I'm looking for some ways to improve Eureka. Especially the way it handles bilocation links is very inefficient. Why not steal the good parts from Denis' 3D-notation and make them an optional extension to Eureka? It shortens some chains considerably, plus I like the 3D way of seeing the nrc coordinates.

Normally you probably would write it as kraken (3-way) move

Yes. This would be my standard way of writing that (BUG-derived strong links implied):

(1)r8c5
||
(51)r8c69
||
(56)r9c56 - r8c6 = (6)r8c2

...which can be written as a nested AIC (afaik) in standard notation:

[(1)r8c5 =BUG= (51)r8c69] =BUG= (56)r9c56 - r8c6 = (6)r8c2

Can we agree on that? If so, then the real question is about the notational peculiarities, which I guess can be summed up with the last node:

6.r8c(6=2) <-> (6)r8c6 = (6)r8c2

It's obviously a 3D shorthand for a bilocation link. I like the idea because it takes less space is and actually more readable too once you get used to it (because there's less repetition and it's much clearer what the linking axis is). However, I'm not sure how the rest of it should be written. This was the first time I tried the dot to separate the n-coordinate. The two more standard possibilities would be (6)r8c(6=2) or 6r8c(6=2). I don't like the first, because I'd prefer at most one set of brackets in a node (preferably dedicated to linking action). I think the latter is better, but I'm not a big fan of it either because it's a bit harder to read (especially if there's an ALS node with many digits and cells). So, I experimented with the dot-separator, which improves readability but takes half the space of brackets (and without the confusion of two sets of brackets in a single node).

I guess there's also the possibility to not use brackets in the linking part: (6)r8c6=2. Not sure how that would work. Maybe even the most readable way, at least in simple scenarios?

So, there's my rationale for those experimental choices. Honest feedback is still welcome, as always

or (similarly to Steve) as
1r8c5 =BUG= 5b8p68 - (5=6)r9c6 - r8c6 = r8c2 => -1 r8c2; stte

Sure, but it would have been too similar to Steve's, so no point in repeating it.

[eleven]

If you explain it, before using it, the notation is ok for me (as long as it is logically correct), whatever you use.
[Added:] This part in my eyes is logically not corrrect: [(1)r8c5 =BUG= (51)r8c69]
Apart from that, i am not interested in discussions about notations.

[SpAce]

This part in my eyes is logically not corrrect: [(1)r8c5 =BUG= (51)r8c69]

Can you elaborate? I know there's something that hurts my eyes too, but I can't see why it's incorrect. What about this unnested version (possible here because there's no further chaining action):

(1)r8c5|(51)r8c69 =BUG= (56)r9c56 - r8c6 = (6)r8c2 ?

This would be clearly incorrect (two strong links next to each other in the top-level chain):

(1)r8c5 =BUG= (51)r8c69 =BUG= (56)r9c56 - r8c6 = (6)r8c2

[SteveG48]

...which can be written as a nested AIC (afaik) in standard notation:

[(1)r8c5 =BUG= (51)r8c69] =BUG= (56)r9c56 - r8c6 = (6)r8c2

Can we agree on that?

Sorry, but while I know that Eureka isn't perfect, I don't think structures like this are the answer. An AIC should be just that: alternating weak and strong links.

The notation (1)r8c5 =BUG= (51)r8c69 turns me off because the links don't appear to alternate, and that's fatal to the notation, IMO. That's why I've chosen to write it as
(1r8c5 = 5r8c69)[BUG+3], where the BUG+3 in brackets is intended as purely explainatory. I'm open to alternate ideas that don't mask the alternating links.

Just my thought on the subject.

[SpAce]

...which can be written as a nested AIC (afaik) in standard notation:

[(1)r8c5 =BUG= (51)r8c69] =BUG= (56)r9c56 - r8c6 = (6)r8c2

Sorry, but while I know that Eureka isn't perfect, I don't think structures like this are the answer. An AIC should be just that: alternating weak and strong links.

Steve, thanks for your feedback too! I fully agree with you: AICs should be just that -- and I'm pretty sure mine is! (Early on they all weren't, but I remember you among others helped me fix that)! The first node is a nested (very short) chain in the [brackets]. Either that nested chain is true or the next node of the top level chain is. Nested chains have been used here quite frequently, especially by Cenoman and eleven, and sometimes myself. What is different about this one?

The notation (1)r8c5 =BUG= (51)r8c69 turns me off because the links don't appear to alternate, and that's fatal to the notation, IMO. That's why I've chosen to write it as
(1r8c5 = 5r8c69)[BUG+3], where the BUG+3 in brackets is intended as purely explainatory. I'm open to alternate ideas that don't mask the alternating links.

Well, in that regard my style is almost exactly what AIC gurus such as David or Myth Jellies (if I remember correctly) have used in the past, so I think it does have a pretty strong precedent. If you search for examples of David's chains you'll find that he writes derived links as =[UR]= or =[BUG]= or -[JE]- etc. The only difference is that I don't use brackets there because they take space and aren't really needed for readability. The meaning of such inlined tags is exactly the same as yours -- to be an explanation to a derived link -- but I personally prefer it within the link where it belongs. I don't see anything wrong with your style either, but I do know that my style is not wrong (if, for example, David's AICs are used as a reference). It should not be interpreted as two strong links next to each other -- it's just one derived link with an inlined explanation. If I use an external explanation instead, I still write derived strong links as == to differentiate them from native links. Do you see that as a problem too?

I'm surprised that this part of my notation raised questions. I was expecting resistance to everything else, but I thought these things were pretty standard!

[eleven]

This part in my eyes is logically not corrrect: [(1)r8c5 =BUG= (51)r8c69]

Can you elaborate?

If you nest something in brackets it should make sense for it's own. E.g. you can nest an xy-wing and there is an xy-wing in the brackets.
But here is no BUG in the brackets. If you had not marked the BUG candidates in the grid, it would have been impossible for me to understand, what you mean.

[SpAce]

This part in my eyes is logically not corrrect: [(1)r8c5 =BUG= (51)r8c69]

Can you elaborate?

If you nest something in brackets it should make sense for it's own. E.g. you can nest an xy-wing and there is an xy-wing in the brackets.

I agree with everything so far.

But here is no BUG in the brackets.

I sure hope so, as we're trying avoid one! There's a BUG+2, however. There are three BUG-guardians in the whole grid: (1)r8c5, (5)r8c6, and (5)r9c5. If the last one is false, then we have a BUG+2 with the first two, which is depicted in the brackets. What's wrong with that? Written like that the BUG+3 can be seen as an almost-BUG+2 with the third BUG-candidate as a spoiler, just like we do with an almost-XY-Wing or almost-Skyscraper or whatever. What am I still missing?

Or, are you objecting to my habit of combining guardian candidates into bigger nodes, like (51)r8c69 and (56)r9c56? That of course hides them a bit but it doesn't make those nodes or the derived links incorrect (and I've done that a lot in the past, so why would this be different?). Of course I could have written the chain like this with explicit BUG-candidates:

[(1)r8c5 =BUG= (5)r8c6 - (5=1)r8c9] =BUG= (5)r9c5 - (5=6)r9c6 - r8c6 = (6)r8c2

Is that somehow more correct in your eyes? Or is the logical error you see somewhere else? I'd like you to pinpoint it more accurately because I'm still blind to it.

Or would this possibly clarify the different BUG-links:

[(1)r8c5 =BUG+2= (5)r8c6 - (5=1)r8c9] =BUG+3= (5)r9c5 - (5=6)r9c6 - r8c6 = (6)r8c2

Added: Looking at the chain above, I think the real culprit might be the second =BUG= link which doesn't seem to make sense written like that. If the third BUG-candidate is seen as a spoiler to BUG+2, then perhaps it should be treated as such. How about something like this (the spoiler made explicit with #):

[(1)r8c5 =[BUG+2+#]= (5)r8c6 - (5=1)r8c9] = (#5)r9c5 - (5=6)r9c6 - r8c6 = (6)r8c2

Would that make more sense as a nested chain? BUG+3 <-> almost-BUG+2.

If you had not marked the BUG candidates in the grid, it would have been impossible for me to understand, what you mean.

Isn't that why they're marked in the grid? Without that visual aid I probably would have written the chain differently, but since we have it, I've thought there's more freedom in compacting the chains without losing too much clarity.

[999_Springs]

aside note: at 65 clues and se 6.2, this puzzle will be crossposted to the "maximum clues per se rating" thread when i get the chance to update it

[SteveG48]

Well, in that regard my style is almost exactly what AIC gurus such as David or Myth Jellies (if I remember correctly) have used in the past, so I think it does have a pretty strong precedent.

I didn't realize that, so you certainly have two very strong supporters.

The reason I don't like it is the equals signs on both sides of BUG. It breaks the symmetry of the AIC.

Now let's look at what you've written in the brackets:

(1)r8c5 =BUG= (51)r8c69

What this says to me is that if 1 is not true in r8c5 then BUG is true. At that point in the chain, that's not a correct Boolean conclusion. Then the expression says that if BUG is true then 51 is true in r8c69. Not so. 51 must be true in r8c69 if 1 is not true in r8c1 and BUG is not true. To me, using BUG as a term in the Boolean expression, rather than as an explanatory note, simply shouldn't be done. BUG is not a Boolean expression that can be evaluated as true or false. It must always be false in a Sudoku puzzle.

[SpAce]

The reason I don't like it is the equals signs on both sides of BUG. It breaks the symmetry of the AIC.

In a way it does, but so does your way of adding the explanation to the end separately (just in a different way). I think it's a matter of taste which way hurts the eyes more. I don't think there's a really good way of doing it, but for some reason I dislike one of them less than the other. I understand that you see it the opposite way, and I'm not going to argue about that. (We also write the digits in ALS nodes in a different order, but I'm certainly not saying your way is wrong -- it has its own advantages just like mine).

Now let's look at what you've written in the brackets:

(1)r8c5 =BUG= (51)r8c69

What this says to me is that if 1 is not true in r8c5 then BUG is true.

I understand. I had the same difficulty when I first saw those expressions. That's not what it says, however. Once I figured that out, it's seemed quite natural: just a single link with an explanation in the middle. With proper white-spacing it's not very hard to see like that, I think. (If the white-space is removed, then it's gets more hairy.) The way I see it is that when there's a DP-name of any kind in a link (=BUG=, =UR=, =Oddagon=, ...) it acts as a catalyst which makes the derived link possible -- it's obviously never at either end of the link because it can never be true (but it can be in the middle, just like a catalyst in a chemical process). The only confusion is that UR is not really a DP like the others (strictly speaking, a UR pattern includes the extra candidates that prevent a DR), which means that URs can also be used as valid nodes unlike the real DPs.

At that point in the chain, that's not a correct Boolean conclusion. Then the expression says that if BUG is true then 51 is true in r8c69. Not so. 51 must be true in r8c69 if 1 is not true in r8c1 and BUG is not true. To me, using BUG as a term in the Boolean expression, rather than as an explanatory note, simply shouldn't be done. BUG is not a Boolean expression that can be evaluated as true or false. It must always be false in a Sudoku puzzle.

Yep. But since all of that should be self-evident to any non-beginners, there should be no confusion about what the expression really means (or at least what it doesn't mean). Your interpretation would imply two clear mistakes in the AIC: one, that two links of the same type follow each other, and two, that a link somehow makes a BUG true in the chain. Because none of us is likely to make either mistake, the expression must mean something else. And since it's been used that way for a long time by many solvers (which, of course, doesn't mean it's perfect), it shouldn't come as a huge surprise either.

PS. AICs have other weird expressions too, starting with things like (3=5) which make zero sense unless you know how it's to be interpreted. The most unintuitive sudoku notation I've seen is the truth and link sets which are pretty much impossible to interpret with just common sense (Denis Berthier was right about that and Allan Barker should have listened -- even though everything else he did was brilliant).