The New Sudoku Players' Forum

[tarek]

Code: Select all

+-------+-------+-------+
| 1 . . | . . 6 | . 4 . |
| . . . | . . 3 | . 2 7 |
| . 2 . | 1 . . | . . . |
+-------+-------+-------+
| 8 . . | . . . | . 6 5 |
| . 9 7 | . 2 . | . . . |
| 3 . . | . . . | 4 . . |
+-------+-------+-------+
| 2 . . | . 8 . | . . . |
| . . . | . 5 . | 8 . . |
| . . 8 | 7 . 4 | . . 3 |
+-------+-------+-------+
1....6.4......3.27.2.1.....8......65.97.2....3.....4..2...8........5.8....87.4..3


Play this puzzle online

Download Sukaku Explainer

[SpAce]

Code: Select all

.------------------------.----------------.-----------------.
|  1      357     359    |  2    79   6   |  59   4     8   |
| h469    8       469    |  5   g49   3   |  1    2     7   |
| f4579   2       459    |  1   g479  8   |  569  3     69  |
:------------------------+----------------+-----------------:
|  8     b14      2      | b49   3    179 | c79   6     5   |
| a4-6    9       7      |  46   2    5   |  3    8     1   |
|  3      156     156    |  8    16   79  |  4   d79    2   |
:------------------------+----------------+-----------------:
|  2      134567  134569 |  369  8    19  |  679  1579  469 |
|  4679   13467   13469  |  369  5    2   |  8    179   469 |
| f569    156     8      |  7    16   4   |  2   e159   3   |
'------------------------'----------------'-----------------'

(4)r5c1 = (49)r4c24 - r4c7 = r6c8 - r9c8 = 9r9c1.[(95-7)r93c1 = (74)r32c5] - (9|4=6)r2c1 => -6 r5c1; stte

as a memory chain: Show

(4)r5c1 = r4c2 - (4=9)r4c4 - r4c7 = r6c8 - r9c8 = (9*-5)r9c1 = (5-7)r3c1 = (7-4)r3c5 = r2c5 - (4|*9=6)r2c1 => -6 r5c1; stte

8x8 TM: Show

Code: Select all

 4r5c1 4r4c2
       4r4c4 9r4c4
             9r4c7 9r6c8
                   9r9c8 9r9c1
                         5r9c1 5r3c1
                               7r3c1 7r3c5
                                     4r3c5 4r2c5
 6r2c1                   9r2c1             4r2c1
================================================
-6r5c1

[eleven]

Code: Select all

 *----------------------------------------------------------------------*
 |  1      357      359      |  2     79    6     |  59    4      8     |
 |  469    8        469      |  5     49    3     |  1     2      7     |
 |  4579   2        459      |  1     479   8     |  569   3      69    |
 |---------------------------+--------------------+---------------------|
 |  8     d14       2        |  49    3    c179   |  79    6      5     |
 |  46     9        7        |  46    2     5     |  3     8      1     |
 |  3      156      156      |  8     16   b79    |  4    a79     2     |
 |---------------------------+--------------------+---------------------|
 |  2      134567   134569   |  369   8    d19    |  679   1579   469   |
 |  4679   13467    13469    |  369   5     2     |  8     179    469   |
 |  569   e156      8        |  7    e16    4     |  2    f159    3     |
 *----------------------------------------------------------------------*

(9=7)r6c8 - r6c6 = (7-1)r4c6 = 1r4c2&r7c6 - r9c25 = 1r9c8 => -9r8c8, stte

[SpAce]

Lacking a recent example of my own, I'll use eleven's chain to propose a rather radical syntax upgrade. (No, there's nothing wrong with eleven's chain as per the current standards. It's perfectly correct and a very nice solution. I just don't like the current standards in this case.) Once again, this is only for those who are interested in thinking about notational details.

(9=7)r6c8 - r6c6 = (7-1)r4c6 = 1r4c2&r7c6 - r9c25 = 1r9c8 => -9r8c8, stte

I've always hated the '&' because it hinders readability much more than its counterpart '|' or most other common symbols we use. It almost begs to use white space around it, which in turn would practically require brackets:

(7-1)r4c6 = (1r4c2 & 1r7c6) - r9c25

Or perhaps:

(7-1)r4c6 = 1(r4c2 & r7c6) - r9c25

Much more readable. Note that the brackets aren't absolutely necessary in the first case, since the surrounding links demarcate the node boundaries without any ambiguity, but without them the readability benefit is lost.

Obviously neither of those "fixes" is optimal because they add 4-5 extra characters per case, which adds up since the need for the AND-symbol is ubiquitous. It also makes the '&' different from other common symbols that don't need such white space, and I don't like differences that don't have semantic meanings. Since basically just one of the common symbols has that problem, I think it would be easiest to switch to a more readable symbol.

For those reasons I started replacing most '&' with ',' in my own chains quite a while back. It's not perfect (which is why I recently switched to a completely new symbol '.' when applicable), but it works correctly in most cases even with the current standards. Not in this case, though. If we were to write:

(7-1)r4c6 = 1r4c2,r7c6 - r9c25

...that would break the logic as per the current interpretation, because it would just state that 1 is somewhere within the multi-house node {r4c2 r7c6} but not necessarily in both cells. In other words the semantics would be the same as in the following r9c25 node which could be written explicitly r9c2,r9c5.

Yet I think that interpretation should be changed in favor of the comma meaning AND here as well. Thus: 1r4c2,r7c6 should be equal to 1r4c2&r7c6. (I'm feeling shock waves right now, especially in Florida -- sorry! ) Obviously that change would require another symbol for the other meaning, but for that I suggest the dot. (Using the dot for AND and keeping the comma for the original purpose would certainly be easier for this case, but I think it would be less intuitive and cause other problems. Thus, I'm pretty sure I prefer the roles this way.)

For example, my old chain from here:

(9)r2c13 = r2c8&r3c3 - r3c6|r79c8 = r5c6&r9c9 - r59c1 = (9)r2c1 => -9 r3c3; stte

...could be written:

(9)r2c13 = r2c8,r3c3 - r3c6.r79c8 = r5c6,r9c9 - r59c1 = (9)r2c1 => -9 r3c3; stte

...though in this case I might keep the '|' for a better contrast:

(9)r2c13 = r2c8,r3c3 - r3c6|r79c8 = r5c6,r9c9 - r59c1 = (9)r2c1 => -9 r3c3; stte

(Btw, I would whole-heartedly agree that the original is the most intuitively understandable. This is about readability, which is a different concept.)

I know it's a huge change which would break tons of old chains, so I don't expect it to be welcomed with open arms. Yet, it would make ANDed nodes more readable and also the comma usage more intuitive, at least as far as I'm concerned. I remember when I saw a comma between cells as a newbie I automatically interpreted it as AND, until I learned it was not. That's why I've never liked the comma being used in the original meaning, so I've mostly written those cases as r4c2|r7c6 making the OR-logic explicit. Yet I've recently considered potential semantic problems with that approach as well, so I've mostly switched to using the completely new '.' for that purpose.

If I now want to state that a digit is somewhere in the multi-house node {r4c1 r7c6}, I write it 1r4c2.r7c6, which has the exact same semantics as when a single-house node is written 1r9c25. In other words, the latter is a short-cut for 1r9c2.r9c5 (note how it looks much more similar to the short form than if written with the comma). In my new system 1r9c2,r9c5 would be impossible because both of those cells can't hold the same digit. On the other hand, both 1r4c2.r7c6 and 1r4c2,r7c6 are possible but have different meanings. Yet 1r4c2.1r7c6 and 1r4c2,1r7c6 would mean the same (both cells have a 1).

In general, when the digits are explicitly written for every cell, there's no practical difference between the three AND-symbols. The only difference is when the digit is written only once (or implied by an earlier node) and applies to the whole combined node. (Of course the comma also retains its other special meaning when applied to digits instead of cells. The new system is more in line with that usage as well.) In most cases any of the three symbols can be used to mean AND, as in my own solution to this puzzle:

9r9c1.[(95-7)r93c1 = (74)r32c5]

is the same as:

(9r9c1 & [(95-7)r93c1 = (74)r32c5])

The comma could be used as well, but I think I prefer the dot when the special semantics of the comma aren't needed (*). The dot has less baggage so it can be more easily used as a general purpose separator/connector when needed. Like I said, in most -- but not all -- cases all three symbols are interchangeable. Three possible symbols for the same thing is a bit much, though, so I'd be quite happy to drop the '&' unless someone can argue that it's still needed for some special case. The only possible need I see is if white space is actually required around the AND-symbol, as in that case both '.' and ',' would look weird. When would that be?

(*) I'm not sure of that, though. It might be clearest to use the comma for most normal AND situations. That would leave the dot as the default cell connector, and a no-op digit separator. In other words, (123)r456c7 would be the same as (1.2.3)r456c7 but not the same as (1,2,3)r456c7. Similarly r456c7 would be the same as r4.5.6c7 or r4c6.r5c7.r6c7 but not r4,5,6c7 or r4c7,r5c7,r6c7. We'll see.

--

As always, I'm happy to hear constructive criticism about those ideas. At this time I would especially appreciate if someone could find difficult edge cases where my new semantics might break. I can't claim that I've thought through every possibility, because most of these are very recent ideas. Yet in my own limited testing the new rules have worked quite nicely and produced more readable chains in my opinion. In any case, consider this a further warning that I will be testing these ideas in my chains in the near future, as I've already been doing. Thus they need to be interpreted under these rules until further notice.

Also, if you think my ideas might make sense in theory, but would really hate changing Eureka to accommodate that, don't be overly concerned. Even I'm not sure if I want to push such drastic changes into Eureka at this point. I'm actually working on a whole new language (working title: Neureka) without any legacy burdens or compromises. So, think of this from that perspective. (I'm not necessarily expecting anyone to actually use that language, but I'd just like to create a paragon reference from my point of view.

PS. For teasers: besides probably banning '&' (at least without white space), Neureka won't use '=' for strong links, and it has a perfected and probably unique coordinate system (though rYcX, bBpP remain options). Readability is one of the cornerstones of its design, so it makes every effort to avoid compromises on that even if it breaks backwards compatibility. (Like I said, readability and understandability are two different things.)

[SteveG48]

Code: Select all

 *------------------------------------------------------------------------------*
 | 1       357     359     |  2       79      6       | 59      4       8       |
 | 469     8       469     |  5       49      3       | 1       2       7       |
 | 4579    2       459     |  1       479     8       | 569     3       69      |
 *-------------------------+--------------------------+-------------------------|
 | 8      d14      2       |cd49      3      c179     |b79      6       5       |
 | 46      9       7       |  46      2       5       | 3       8       1       |
 | 3       156     156     |  8       16     d79      | 4      a79      2       |
 *-------------------------+--------------------------+-------------------------|
 | 2       134567  134569  |  369     8      d19      | 679     1579    469     |
 | 4679    13467   13469   |  369     5       2       | 8       179     469     |
 |e569    e156     8       |  7      e16      4       | 2       15-9    3       |
 *------------------------------------------------------------------------------*


9r6c8 = r4c7 - r4c46 = (41)r4c24&(91)r67c6 - (1=569)r9c125 => -9 r9c8 ; stte

Ouch. Almost the same as Eleven.

[SpAce]

Just another way to route and write it (sans '&'), to test the proposed syntax elements:

Code: Select all

.----------------------.----------------.----------------.
| 1     357     359    |  2    79   6   | 59   4     8   |
| 469   8       469    |  5    49   3   | 1    2     7   |
| 4579  2       459    |  1    479  8   | 569  3     69  |
:----------------------+----------------+----------------:
| 8    c14      2      | c49   3    179 | 79   6     5   |
| 46    9       7      |  46   2    5   | 3    8     1   |
| 3     156     156    |  8    16  b79  | 4   a79    2   |
:----------------------+----------------+----------------:
| 2     134567  134569 |  369  8   c19  | 679  1579  469 |
| 4679  13467   13469  |  369  5    2   | 8    179   469 |
| 569  d156     8      |  7   d16   4   | 2   e15-9  3   |
'----------------------'----------------'----------------'

(9)r6c8 = r6c6 - (9=41,1)r4c42.r7c6 - r9c25 = (1)r9c8 => -9r9c8; stte

The cleanest, I think, would be this (almost exactly the same as eleven's):

(9)r6c8 = (97-1)r64c6 = r4c2,r7c6 - r9c25 = (1)r9c8 => -9 r9c8; stte