The New Sudoku Players' Forum

[ArkieTech]

Code: Select all

 *-----------*
 |...|...|...|
 |...|.8.|7.5|
 |9.6|.47|.2.|
 |---+---+---|
 |4.9|7..|..6|
 |..7|.6.|5..|
 |2..|..8|9.7|
 |---+---+---|
 |.7.|41.|8.9|
 |1.2|.9.|...|
 |...|...|...|
 *-----------*


Play/Print this puzzle online

[Ngisa]

Code: Select all

+--------------------+----------------------+--------------------+
| 7     1258    a158 | 12356    35    13569 | 46    1369    134-8|
| 3     124      14  | 126      8     169   | 7     169     5    |
| 9     15-8     6   | 135      4     7     |e1*3   2      f138  |
+--------------------+----------------------+--------------------+
| 4     135      9   | 7        2    d15    |d13    8       6    |
| 8     13       7   | 9        6     4     | 5     13      2    |
| 2     6        15  | 135      35    8     | 9     4       7    |
+--------------------+----------------------+--------------------+
| 56    7        3   | 4        1     2     | 8     56      9    |
| 1    c48       2   | 3568     9    c356   |c46    7      c3*4  |
| 56    9       b48  | 368      7     36    | 2     1356    134  |
+--------------------+----------------------+--------------------+


(8)r1c3 = r9c3 - (8=3*456)r8c2679 - (5=13)r4c67 - (3=1*)r3c7 - (1*3*=8)r3c9 => -8r1c9,r3c2; stte

Clement

[SpAce]

Code: Select all

.-------------------.------------------.------------------.
| 7    258-1    158 | 12356  35  13569 | 46   1369   1348 |
| 3    24-1   a(1)4 | 126    8   169   | 7    169    5    |
| 9    58-1     6   | 135    4   7     | 13   2      138  |
:-------------------+------------------+------------------:
| 4    135      9   | 7      2   15    | 13   8      6    |
| 8  d(1)3      7   | 9      6   4     | 5   d13     2    |
| 2    6        5-1 | 135    35  8     | 9    4      7    |
:-------------------+------------------+------------------:
| 56   7        3   | 4      1   2     | 8    56     9    |
| 1    48       2   | 3568   9   356   | 46   7      34   |
| 56   9       b48  | 368    7   36    | 2   c1356  c134  |
'-------------------'------------------'------------------'

(1=4)r2c3 - r9c3 = (41)r9c98 - 1r5c(8=2) => -1 r123c2,r6c3; stte

[SteveG48]

Code: Select all

 *---------------------------------------------------------------------*
 | 7      1258   158    | 12356 bc5-3    13569  | 46     1369   1348   |
 | 3      124    14     | 126     8      169    | 7      169    5      |
 | 9     g158    6      |d135     4      7      |d13     2    eh138    |
 *----------------------+-----------------------+----------------------|
 | 4      135    9      | 7       2    bc15     |c13     8      6      |
 | 8      13     7      | 9       6      4      | 5      13     2      |
 | 2      6      15     | 15-3   a35     8      | 9      4      7      |
 *----------------------+-----------------------+----------------------|
 | 56     7      3      | 4       1      2      | 8      56     9      |
 | 1     f48     2      | 3568    9      356    | 46     7     f34     |
 | 56     9      48     | 368     7      36     | 2      1356   134    |
 *---------------------------------------------------------------------*


(3=5)r6c5 - 5r1c5,r4c6 = ((13)r4c67)&(3r1c5) - 3r3c47 = 3r3c9 - (3=48)r8c29 - 8r3c2 = 8r3c9 Contradiction => -3 r1c5,r6c4 ; stte

[SpAce]

(3=5)r6c5 ... Contradiction => -3 r1c5,r6c4 ; stte

Hi Steve! I'm perfectly fine with your contradiction proof, but speaking of clarity, I think it would be better to conclude +3r6c5 (or just 3r6c5). It's the direct conclusion since your initial assumption is -3r6c5 (which you prove false). The eliminations of course follow that, but they're not the direct conclusion of your chain. Another possibility is to start the chain (3)r6c4 - (3=5)r6c5... and then conclude -3 r6c4. (That'd be a more typical Nishio, although starting with a negative assumption works just as well.)

[Cenoman]

Code: Select all

 +--------------------+-----------------------+---------------------+
 |  7   a1258# b158   | a12356#  35   13569   |  46   1369  E1348   |
 |  3    124    14    |  126     8    169     |  7    169    5      |
 |  9    158*   6     |  135*    4    7       | D13   2     E138    |
 +--------------------+-----------------------+---------------------+
 |  4   d135*   9     |  7       2  Be15*     | C13   8      6      |
 |  8    13     7     |  9       6    4       |  5    13     2      |
 |  2    6     c15    |  135*   A35#  8       |  9    4      7      |
 +--------------------+-----------------------+---------------------+
 |  56   7      3     |  4       1    2       |  8    56     9      |
 |  1    48     2     | y3568#   9  zf356     |zf46   7    zf34     |
 |  56   9      48    |  368     7    36      |  2    1356  F13-4   |
 +--------------------+-----------------------+---------------------+

In the 5s, 5-links oddagon (*) with four guardians (#)
(5)r1c24 - r1c3 = r6c3 - r4c2 = r4c6 - (536=4)r8c679
(5)r6c5 - (5=1)r4c6 - r4c7 = r3c7 - r13c9 = (1)r9c9
(5)r8c4 - (536=4)r8c679
=> -4 r9c9; ste

[SteveG48]

(3=5)r6c5 ... Contradiction => -3 r1c5,r6c4 ; stte

Hi Steve! I'm perfectly fine with your contradiction proof, but speaking of clarity, I think it would be better to conclude +3r6c5 (or just 3r6c5). It's the direct conclusion since your initial assumption is -3r6c5 (which you prove false). The eliminations of course follow that, but they're not the direct conclusion of your chain. Another possibility is to start the chain (3)r6c4 - (3=5)r6c5... and then conclude -3 r6c4. (That'd be a more typical Nishio, although starting with a negative assumption works just as well.)

True enough. Also, -5 r6c5 works for me.

On yours, I like your solution a lot, but I still wish you would drop the practice of putting links in the cell set designator.

[SpAce]

True enough. Also, -5 r6c5 works for me.

Yeah, that would actually be best (shortest), if you change the start node to that.

On yours, I like your solution a lot, but I still wish you would drop the practice of putting links in the cell set designator.

I know, and your objection has been noted. However, I still think that notation is both conceptually and practically superior to standard Eureka, so I want to continue testing it. The only argument (I've seen) against it is reduced clarity. I agree that reading that notation is still a bit harder for me too, but it's too early to conclude whether it's an intrinsic property or just that I'm so used to the standard notation. So, I'll keep testing it, but I can also provide a decrypted version of my chains.

Added: I'm not the first to get tired of the lengthy Eureka chains. For example, David has said that he would have preferred a chess board notation (K9 or similar), or even different sequences of letters for both rows and columns, but was overruled when the Eureka standards were being developed. I haven't always agreed with that point of view, but I think I mostly do now. Eureka chains are often too damn long, which hinders readability as well. However, for someone used to rNcN it would take some effort to switch to K9 (at least for me those chains are hard to read), and it's not as intuitive to adopt in the first place.

My 3D notation preserves rNcN but still shortens many chains considerably, and I don't think it's that hard to decipher even if you've never seen it before (it's a logical extension). Of course 3D would work with K9 too with even more drastic shortenings. (My biggest problem with K9 is how to notate box/positions without resorting to the longer bNpN format which is more in line with rNcN. If someone has a good solution to that, then I might advocate K9 as well.)

[eleven]

Code: Select all

 *------------------------------------------------------------------*
 |  7    1258   158   |  12356  d35   13569   |  46   1369   1348   |
 |  3    124    14    |  126     8    169     |  7    169    5      |
 |  9    158    6     | d135     4    7       |  1-3  2      138    |
 |--------------------+-----------------------+---------------------|
 |  4    135    9     |  7       2   b15      | a13   8      6      |
 |  8    13     7     |  9       6    4       |  5    13     2      |
 |  2    6      15    | c135    c35   8       |  9    4      7      |
 |--------------------+-----------------------+---------------------|
 |  56   7      3     |  4       1    2       |  8    56     9      |
 |  1    48     2     |  3568    9    356     |  46   7      34     |
 |  56   9      48    |  368     7    36      |  2    1356   134    |
 *------------------------------------------------------------------*

Maybe others find a better way to write it.
The logic is, that if not 3 but 1 in r4c7, you get 13 in r6c56, and 3r3c4,5r1c5.
(3=1)r4c7 - r4c6 = hp13r6c56 - 1r3c4|3r1c5 = 3r3c4 => -3r3c7, stte

[SpAce]

Maybe others find a better way to write it.

Since you invited, I'll try...

(3=1)r4c7 - r4c6 = hp13r6c45 - 1r3c4|3r1c5 = 3r3c4 => -3r3c7, stte

My only problem is with the colored link (and the unnecessary 'hp'-marker, but that's just a preference). At least at first glance I don't think it's valid as written, because too much stuff is left for imagination. I haven't tried to find any more elegant ways to rewrite it, but a simple memory chain should work at least:

(3=1)r4c7 - r4c6 = (1*3)r6c45 - (3=5)r1c5 - (5|*1=3)r3c4 => -3 r3c7; stte

or:

(3=15)r4c76 - (5=1*3)r6c45 - (3=5)r1c5 - (5|*1=3)r3c4 => -3 r3c7; stte

Nice logic anyway!

Added: perhaps something like this (closest to your original) would work too (if my comma notation is acceptable):

(3=1)r4c7 - r4c6 = 13r6c45 - 1r3c4|3r1c5 = (5,3)b2p27 => -3 r3c7; stte

[eleven]

For me there is a difference between memorizing a digit for a long time and just keeping 2,3 digits in mind for one link.
AIC's are not made for the latter, but that is easier for me.

[SpAce]

How about my added version?

[eleven]

It looks ok, but i don't think, that it is as easy to understand as to spot.

[SteveG48]

Code: Select all

 *------------------------------------------------------------------*
 |  7    1258   158   |  12356  d35   13569   |  46   1369   1348   |
 |  3    124    14    |  126     8    169     |  7    169    5      |
 |  9    158    6     | d135     4    7       |  1-3  2      138    |
 |--------------------+-----------------------+---------------------|
 |  4    135    9     |  7       2   b15      | a13   8      6      |
 |  8    13     7     |  9       6    4       |  5    13     2      |
 |  2    6      15    | c135    c35   8       |  9    4      7      |
 |--------------------+-----------------------+---------------------|
 |  56   7      3     |  4       1    2       |  8    56     9      |
 |  1    48     2     |  3568    9    356     |  46   7      34     |
 |  56   9      48    |  368     7    36      |  2    1356   134    |
 *------------------------------------------------------------------*

Maybe others find a better way to write it.
The logic is, that if not 3 but 1 in r4c7, you get 13 in r6c56, and 3r3c4,5r1c5.
(3=1)r4c7 - r4c6 = hp13r6c56 - 1r3c4|3r1c5 = 3r3c4 => -3r3c7, stte

Nice solution. I'd write it:

(3=15)r4c67 - (5=13)r6c45 - (3r1c5)|(1r3c4) = (5r1c5)&(3r3c4) => -3 r3c7

I know it looks complicated, and illustrates the weakness of Eureka, but sometimes spelling out the results for each individual cell in a node makes things clear.

[SpAce]

The logic is, that if not 3 but 1 in r4c7, you get 13 in r6c56, and 3r3c4,5r1c5.
(3=1)r4c7 - r4c6 = hp13r6c56 - 1r3c4|3r1c5 = 3r3c4 => -3r3c7, stte

Nice solution. I'd write it:

(3=15)r4c67 - (5=13)r6c45 - (3r1c5)|(1r3c4) = (5r1c5)&(3r3c4) => -3 r3c7

I know it looks complicated, and illustrates the weakness of Eureka, but sometimes spelling out the results for each individual cell in a node makes things clear.

To be honest, it doesn't make things very clear to me. Written like that it implies (3=5)r1c5 (which is true) and (1=3)r3c4 (which is not directly true). Maybe it doesn't really imply that but that's definitely how it looks to me at first glance, because most split-nodes work that way. In any case, they're not truly parallel operations, because the latter depends on the former happening first. Thus, I'm not sure if the last link is much more correct than the original, though it's clearer because the 5r1c5 is spelled out. The underlying problem is the same: as a separate entity 3r3c4 is not a direct result of the previous link.

Then again, the same is mostly (or maybe fully) true with my (5,3)b2p27 approach (which can of course be written as (5,3)r1c5,r3c4 if it's any clearer). The difference between that and Steve's split-node is splitting hairs. The reason why I think the unsplit-node is a (tiny) bit better is that it implies (more clearly) that the contained cells/candidates form a connected tuple and are capable of interacting. When split, that's not as clear, and it remains a bit of a mystery what causes 3r3c4. I don't think it's very explicit either way, though. The only fool-proof way of showing it is the memory chain (or other net notation).

Fact is, this logic uses a tiny net where the (3=5)r1c5 must happen before 3r3c4 can happen, and it's hard to communicate with split-nodes. Of course the net is so tiny that the logic is easy to see even if it's not fully explicit in the chain. AICs and Eureka were not designed for stuff like this, and I don't think there's a completely correct and standard way to write this as such. I'd like to stand corrected, though.