The New Sudoku Players' Forum

[ArkieTech]

Code: Select all

 *-----------*
 |.6.|9..|...|
 |9.7|..1|.26|
 |3.5|...|7.1|
 |---+---+---|
 |.93|.7.|...|
 |...|...|...|
 |...|.9.|63.|
 |---+---+---|
 |5.8|...|3.2|
 |27.|3..|9.8|
 |...|..5|.1.|
 *-----------*
 

Play/Print this puzzle online

[Cenoman]

Code: Select all

 +-------------------+----------------------+-----------------+
 |  18    6     12   |  9       258   7     |  58   4    3    |
 |  9     48    7    |  458     3     1     |  58   2    6    |
 |  3     248   5    |  248     6     248   |  7    9    1    |
 +-------------------+----------------------+-----------------+
 | a14    9     3    |  6       7    a24    |  12   8    5    |
 |  148   258   6    |  12458  b258   3     |  12   7    9    |
 |  7     258   2-1  | b1258    9    b28    |  6    3    4    |
 +-------------------+----------------------+-----------------+
 |  5     1     8    |  7       4     9     |  3    6    2    |
 |  2     7     4    |  3       1     6     |  9    5    8    |
 |  6     3     9    |  28      28    5     |  4    1    7    |
 +-------------------+----------------------+-----------------+

(14=2)r4c16 - (258=1)b5p579 => -1 r6c3; ste

[SpAce]

Code: Select all

.-----------------.------------------.-----------.
| a(8)-1  6    12 | 9       258  7   |  58  4  3 |
|  9      48   7  | 458     3    1   |  58  2  6 |
|  3      248  5  | 248     6    248 |  7   9  1 |
:-----------------+------------------+-----------:
| c(1)4   9    3  | 6       7    24  | c12  8  5 |
| b148   b258  6  | 12458  b258  3   | b12  7  9 |
|  7      258  12 | 1258    9    28  |  6   3  4 |
:-----------------+------------------+-----------:
|  5      1    8  | 7       4    9   |  3   6  2 |
|  2      7    4  | 3       1    6   |  9   5  8 |
|  6      3    9  | 28      28   5   |  4   1  7 |
'-----------------'------------------'-----------'


(8)r1c1 = (852'1)r5c1257 - 1r4(c7=c1) => -1 r1c1; stte

Steve, would that little change make you hate the 3D notation a bit less? I think it might improve readability, though duplicating one character.

[Sudtyro2]

Code: Select all

+--------------+-------------------+--------------+
| 18  6   12   |  9       258  7   |  58  4   3   |
| 9   48  7    |  458     3    1   |  58  2   6   |
| 3   248 5    |  248     6    248 |  7   9   1   |
+--------------+-------------------+--------------+
| 14  9   3    |  6       7   b24  | b12  8   5   |
| 148 258 6    | c2458-1  258  3   | a12  7   9   |
| 7   258 12   |  1258    9    28  |  6   3   4   |
+--------------+-------------------+--------------+
| 5   1   8    |  7       4    9   |  3   6   2   |
| 2   7   4    |  3       1    6   |  9   5   8   |
| 6   3   9    |  28      28   5   |  4   1   7   |
+--------------+-------------------+--------------+

1r5c7 = (12-4)r4c67 = 4r5c4 => -1r5c4; stte

SteveC

[SteveG48]

Code: Select all

.-----------------.------------------.-----------.
| a(8)-1  6    12 | 9       258  7   |  58  4  3 |
|  9      48   7  | 458     3    1   |  58  2  6 |
|  3      248  5  | 248     6    248 |  7   9  1 |
:-----------------+------------------+-----------:
| c(1)4   9    3  | 6       7    24  | c12  8  5 |
| b148   b258  6  | 12458  b258  3   | b12  7  9 |
|  7      258  12 | 1258    9    28  |  6   3  4 |
:-----------------+------------------+-----------:
|  5      1    8  | 7       4    9   |  3   6  2 |
|  2      7    4  | 3       1    6   |  9   5  8 |
|  6      3    9  | 28      28   5   |  4   1  7 |
'-----------------'------------------'-----------'


(8)r1c1 = (852'1)r5c1257 - 1r4(c7=c1) => -1 r1c1; stte

Steve, would that little change make you hate the 3D notation a bit less? I think it might improve readability, though duplicating one character.

A bit, but mainly I don't like the idea of including links in the part of the term notation that identifies the cell set (your third term). Also, I really don't need the ' in your second term, though I have no objection.

I like what Cenoman did above with the font designating the relevant digits, if the writer wants to go to the trouble. I really have no objection at all to the abbreviated notation. I only avoid it because some members of the forum say that affects clarity for them.

[SpAce]

A bit, but mainly I don't like the idea of including links in the part of the term notation that identifies the cell set (your third term).

Fair enough. Can you elaborate a bit why you don't like the idea? I liked it the very first time when I saw people like SteveK and Denis Berthier use something like that. I just didn't like their implementations, but I really liked the idea (makes clearer what the linking axis is). I still do, and I think my implementation is more readable than theirs -- especially for someone used to normal Eureka.

Also, I really don't need the ' in your second term, though I have no objection.

True, it doesn't really need it.

I like what Cenoman did above with the font designating the relevant digits, if the writer wants to go to the trouble. I really have no objection at all to the abbreviated notation. I only avoid it because some members of the forum say that affects clarity for them.

Well, different people like and dislike different things. Personally I don't like either the font hack very much (too much work for little gain) or the abbreviated notation at all. Regarding non-abbreviated ALS nodes, in most cases I'd be happy if people just followed this simple rule:

When an embedded ALS is part of the chain, the digit linked to the previous node is isolated from the remaining digits with a strong link symbol. The remaining digits are placed in such an order that the digit linked to the next node is the last one. (source)

If not, then the clarity is more or less a wash between that and the abbreviated form, as far as I'm concerned (in both cases the reader has to consult the pm grid more to see what's really happening). Again, that's just my personal preference, and I can see why you (for example) don't like to follow that rule. From another point of view I would agree that it's clearer if the digits are in their natural order, but it does make following links a bit harder. Can't have both so one must choose one or the other compromise.

[Cenoman]

I like what Cenoman did above with the font designating the relevant digits, if the writer wants to go to the trouble.

Thank you, Steve. Honestly, I am not the inventor of this way of writing ALS's. eleven is the forumer to congratulate

When SpAce raised the point a few weeks ago, I found four ways of writing ALS's on the forum:

- the Eureka standard notation:

When an embedded ALS is part of the chain, the digit linked to the previous node is isolated from the remaining digits with a strong link symbol. The remaining digits are placed in such an order that the digit linked to the next node is the last one.

I used it until recently.
Note: this Sudopedia quote is dated 2007 ! Note2: SpAce and me have met at the library...

- Your (SteveG48's) notation, also used by phil (pjb). The digit linked to the previous node is isolated from the remaining digits with a strong link symbol. The remaining digits (ANS) are placed in their natural order (as well as the cell coordinates) Ex. (3=12478)r9c34567 - (1=3459)r4c5678 => -3 r8c5 ; stte from here

- the abbreviated notation, with the linking digits between the brackets, without bystanders (used by Leren & al.)

- eleven's notation, with the order of Eureka, but with bystanders in a smaller font.

A 5th notation has appeared recently with SpAce's proposal to keep the order of Eureka, with a character ' separating bystanders from the linking digit in the ANS.

I used the abbreviated notation for a while and I stopped using it because such a practise cannot be used symetrically in AHS's notation; in AHS's, bystanders are the digits locked in the AHS cells, and are not easy to find if these cells have 4 or more candidates each. So back to Eureka notation, until I recently became aware that eleven's notation was a good compromise to improve it.
On this site, the work load to lower the font size is very light (just select the bystanders and click "small" in the font list).
Steve's and phil's notation is easy to read, despite appearances; no need to search the linking digit in the middle of ANS digits, just read it at the beginning of the next node.
SpAce's notation is also easy to read, with one additional character lengthening the chains.

Everyone's taste is different and there is no arguing matters of taste.
Personally, I will read on the five notations, and write on eleven's.

[RSW]

My text based solution (since I haven't learned the notation yet):

Basic Operations:
r9c7=4, r9c9=7, r7c8=6, r8c8=5, r9c1=6, r9c2=3, r9c3=9, r2c5=3, r5c6=3, r1c9=3, r5c3=6, r1c6=7, r6c1=7, r7c4=7, r5c8=7, r3c8=9, r5c9=9, r7c6=9, r1c8=4, r4c8=8, r7c2=1, r7c5=4, r8c3=4, r8c6=6, r8c5=1

XY-wing: Interdependent cells r4c1 r4c6 r6c3 each have two out of the three candidates 1 2 4.
Depending on the value of pivot cell r4c1, either r4c6 or r6c3 must have the value 2.
Therefore candidate 2 can be eliminated from cells which intersect r4c6 and r6c3.
- Eliminating candidate 2 from cells r6c4 r6c6

Basic operations:
r4c4=6, r3c5=6, r4c9=5, r6c9=4, r6c6=8

XY-wing: Interdependent cells r5c5 r5c7 r6c4 each have two out of the three candidates 1 2 5.
Depending on the value of pivot cell r5c5, either r5c7 or r6c4 must have the value 1.
Therefore candidate 1 can be eliminated from cells which intersect r5c7 and r6c4.
- Eliminating candidate 1 from cell r5c4

Basic operations:
r6c4=1, r6c3=2, r6c2=5, r5c2=8, r2c2=4, r3c2=2, r3c6=4, r3c4=8, r2c4=5, r2c7=8, r1c7=5, r1c5=2, r5c5=5, r9c5=8, r9c4=2, r5c4=4, r5c1=1, r5c7=2, r4c7=1, r1c1=8, r4c1=4, r4c6=2, r1c3=1

[SpAce]

When SpAce raised the point a few weeks ago, I found four ways of writing ALS's on the forum

A good list! In this thread you'll find a couple more (JC Van Hay's and Leren's distinctly different ways). My interest in this problem started with that thread. For a while I used JC's (1=34=2) notation, especially with loops, but thought it was a bit confusing and possibly incorrect (especially if things like (1=UR=2) are used with a different meaning). It was the most symmetrical, though, which was great because I like chains to be easily readable both ways (and symmetry in general). My recent (1=34'2) hack is a compromise based on those wishes. Then again, I don't think the ' or other separator is necessary in most chains, but with loops it's important to both see and separate the bystanders, because they have their own eliminations apart from the normal weak links. I think many ALS loops I've seen lack that kind of clarity, and it's especially bad if the bystanders are completely missing.

I used the abbreviated notation for a while and I stopped using it because such a practise cannot be used symetrically in AHS's notation; in AHS's, bystanders are the digits locked in the AHS cells, and are not easy to find if these cells have 4 or more candidates each.

A good point in addition to the loop argument!

So back to Eureka notation, until I recently became aware that eleven's notation was a good compromise to improve it.
On this site, the work load to lower the font size is very light (just select the bystanders and click "small" in the font list).

Good point. I only recently discovered this easy way of applying any of the tags. It does make my "too much work" argument a bit weaker, I admit. However, I usually type and store my chains on a separate editor and would prefer to just copy-paste them here (I'd also like them to look the same on both platforms). I'd also like to be able to use the same style when writing chains by hand, which I do when solving on p&p. The latter is partly the same reason why I'd like to make Eureka less verbose, by either using the 3D notation or K9 or both.

A 5th notation has appeared recently with SpAce's proposal to keep the order of Eureka, with a character ' separating bystanders from the linking digit in the ANS.

I also take the Sudopedia style one step further by trying to match the order of the cell addresses with their corresponding digits. It's not my invention but I can't remember from whom I picked it. I'm not even sure if I like it, as it doesn't always make sense (the same digit in multiple cells) and in those cases it may seem more messy than informative. However, it's mandatory if using the ordered tuple notation with the comma, but that's another controversial notation.

Steve's and phil's notation is easy to read, despite appearances; no need to search the linking digit in the middle of ANS digits, just read it at the beginning of the next node.

True, but for me there's a slight discontinuity in reading the chain then. It's not a big problem, but how is that style used with loops, though? How are the bystanders and linking digits separated then?

Everyone's taste is different and there is no arguing matters of taste.
Personally, I will read on the five notations, and write on eleven's.

I totally share that attitude! I'm pretty sure all of us regulars can read whatever notation we see here, and I personally welcome different styles with different pros and cons. The only question is how much harder it makes newcomers' lives. Then again, I don't see (m)any of those around, so it's not something I'd worry about too much. As far as I know, I'm the latest (hopefully not last) newcomer who's stuck around, and even several veterans seem to have quit the scene lately. That's why I don't see much of a problem with experimenting. Potential troubles of imaginary newcomers seem pretty irrelevant to me at this point, which of course is pretty sad. If that weren't the case, then I'd be voting for stricter adherence to established standards as well.

And the irony.... While I was typing the previous paragraph, a newcomer just posted a solution!! Welcome here as well, RSW! I guess we do need to think about notation standards after all

[SpAce]

My text based solution (since I haven't learned the notation yet)

Well... looks like you've come to the wrong place if you want to learn THE notation, as we can't seem to agree what it is Anyway, hope you can eventually make sense of the slightly different dialects of Eureka we're using here. I'm sure we're all happy to help.

It's good you decided to join this part of the forum as well. Certain conventions are used here, and I guess they're best explained here. There are no strict rules, however, so feel free to participate even if you can't comply with some parts (yet). In short:

1. Apply basics (singles, intersections, subsets) as far as they go. Don't list those steps.
2. Find a non-basic move that reduces the puzzle to singles or basics, or a sequence of such moves if necessary.
3. Express the critical move (or moves) with a grid diagram and preferably with the Eureka notation.
4. If the puzzle solves with singles after applying the previous step(s), append: stte (or ste), which stands for "singles to the end".
5. If the puzzle solves with singles + other basics, append: lclste ("locked candidates, locked sets to the end").

For example, I'd express your solution like this:

Two steps (2 x XY-Wing):

Code: Select all

.------------------.-------------------.----------.
|  18   6     12   | 9      258   7    | 58  4  3 |
|  9    48    7    | 458    3     1    | 58  2  6 |
|  3    248   5    | 248    6     248  | 7   9  1 |
:------------------+-------------------+----------:
| b14   9     3    | 6      7    c(2)4 | 12  8  5 |
|  148  258   6    | 12458  258   3    | 12  7  9 |
|  7    258  a1(2) | 158-2  9     8-2  | 6   3  4 |
:------------------+-------------------+----------:
|  5    1     8    | 7      4     9    | 3   6  2 |
|  2    7     4    | 3      1     6    | 9   5  8 |
|  6    3     9    | 28     28    5    | 4   1  7 |
'------------------'-------------------'----------'

1) XY-Wing: (2=1)r6c3 - (1=4)r4c1 - (4=2)r4c6 => -2 r6c46

Code: Select all

.--------------.-------------------.-------------.
| 18   6    12 |   9       258  7  |   58   4  3 |
| 9    48   7  |   458     3    1  |   58   2  6 |
| 3    248  5  |   248     6    24 |   7    9  1 |
:--------------+-------------------+-------------:
| 14   9    3  |   6       7    24 |   12   8  5 |
| 148  58   6  |   245-1  b25   3  | c(1)2  7  9 |
| 7    25   12 | a(1)5     9    8  |   6    3  4 |
:--------------+-------------------+-------------:
| 5    1    8  |   7       4    9  |   3    6  2 |
| 2    7    4  |   3       1    6  |   9    5  8 |
| 6    3    9  |   28      28   5  |   4    1  7 |
'--------------'-------------------'-------------'

2) XY-Wing: (1=5)r6c4 - (5=2)r5c5 - (2=1)r5c7 => -1 r5c4; stte

That's it. As you can see, basic steps at any stage of the solution are not listed, just the critical non-basic moves (and the corresponding grid stages). On the grid, it's customary to mark the relevant cells and chains using varying conventions, usually letters a..z marking the order of chain nodes, as in above (a..c). I also mark the chain end points (which are responsible for the eliminations) with brackets to help locate them. Typical moves result in one or more critical eliminations and only they're shown instead of any resulting placements, unless the placements are a direct conclusion of the move's logic (rare but possible). Eliminations are shown using the "minus" sign in both the grid and the notation (some use the more verbose r5c4 <> 1, but rarely here).

[SteveG48]

A bit, but mainly I don't like the idea of including links in the part of the term notation that identifies the cell set (your third term).

Fair enough. Can you elaborate a bit why you don't like the idea? I liked it the very first time when I saw people like SteveK and Denis Berthier use something like that. I just didn't like their implementations, but I really liked the idea (makes clearer what the linking axis is). I still do, and I think my implementation is more readable than theirs -- especially for someone used to normal Eureka.

Basically, it's a matter of complexity for people learning the Eureka "language". In it's simplest form, Eureka consists of terms connected by strong and weak links. Each term consists of a candidate or candidate list and a cell or set of cells. To shorten a chain a bit, we've agreed that if the cell set in successive terms is the same, then we can use parentheses with the two candidate lists and the link written together. Thus (a)set1 = (b)set1 becomes (a=b)set1. Now you propose that we do the same with set designations. Thus (a)set1 = (a)set2 becomes
(a)(set1=set2). Things are getting more complicated. What happens when someone decides to write (a=b)(set1=set2) ? What does this mean? It just seems to me that we're on a slippery slope of complexity.

[SpAce]

Hi Steve, and thanks for explaining your reasons! I appreciate it.

Basically, it's a matter of complexity for people learning the Eureka "language".

Well, it is a language, and languages do evolve -- or in most cases should. For example, one of the early selling points of the Java programming language was its simplicity compared to mammoths like C++, and it probably helped make it popular. However, quite soon experienced developers started missing features that had been dropped as too complex, and one by one they've been added to the language and then some. Someone who learned it 20 years ago would hardly recognize the language now. It's become a complex monster, yet most active developers would agree that the changes were needed. Simplicity is nice for newcomers but eventually it gets painful for experienced users who have to jump through unnecessary hoops or create their own kludges to get anything done. As a result there's actually more complexity because everyone has their own set of work-arounds instead of common standards.

As I said above, I don't really expect a whole lot of new growth for the user base of the Eureka language no matter what, so I think it's more important that it fits the needs of the existing power-users. We're already using many features that aren't part of the Eureka standard, such as memory chains. I think we need more. Yet I haven't suggested anything that would break the core language or forbid using its simplest and most standard syntax. I'd just like some optional features that would make it more expressive, consistent, and concise for those who'd like that.

In it's simplest form, Eureka consists of terms connected by strong and weak links. Each term consists of a candidate or candidate list and a cell or set of cells. To shorten a chain a bit, we've agreed that if the cell set in successive terms is the same, then we can use parentheses with the two candidate lists and the link written together. Thus (a)set1 = (b)set1 becomes (a=b)set1. Now you propose that we do the same with set designations. Thus (a)set1 = (a)set2 becomes
(a)(set1=set2). Things are getting more complicated.

I don't really see how they are. In any native link we're using three axes: n (digit), r (row), and c (column), OR n (digit), b (box), and p (position) with two of those fixed so that the third one can be linked in 1D. That fact is evident when we use the short notation for 1r1c5 = 2r1c5 <-> (1=2)r1c5, where the redundancy of the fixed row & column axes is rightfully stripped. The linking action is also very easy to see because it's contained within the brackets, and it it really means: (n1=n2)r1c5. Why shouldn't we be able to strip the same redundancy from the other link types where a different coordinate is being linked? Inconsistency is one way to increase complexity and the learning curve, and to me it seems that the standard Eureka notation is inconsistent, because it insists on treating different link types differently even though they're logically equivalent. That, imho, is confusing and hinders learning.

The n-coordinate is just one of the three nrc (or nbp) -linking possibilities. It's not really different from the others, except that we're using the n-coordinates without the explicit n, which makes it seem different. If everything were written like Denis wanted, i.e. n1r1c5, then the 3D nature would be more explicit, and the equivalency of those three coordinates would be obvious. I'm not (at all) suggesting that or any of his other notations, however, and I don't think it's necessary for seeing things in 3D. I totally prefer the n-coordinate without the n, and other Eureka conventions, but I still don't see why it should be treated any different from the other coordinates.

To me it just seems incredibly stupid to have to write bilocation links verbosely as 1r1c5 = 1r1c8, because logically they're no different from bivalue links. In both cases two axes are fixed and the third one is doing the linking. In the standard bilocation link notation it's just harder to see with a glance which axis is doing the linking. To me 1r1(c5=c8) makes much more sense, plus it's very easy to mentally expand to 1r1c5 = 1r1c8 if need be. A more complex way of seeing it is as a bivalue link in nr-space where columns are candidates, but that's not necessary to understand what's happening.

What happens when someone decides to write (a=b)(set1=set2) ?

Well, I can only tell what happened when I did. In my eagerness I already tried to use that abomination some time ago, and even posted one of my solutions here like that, but quickly figured that it would not make any sense. Hopefully I managed to delete it before anyone saw it If that happens to others, I hope they also realize their mistake, or otherwise someone should tell them.

What does this mean?

Nothing, because it's an ambiguous expression. If I were suggesting something like that you'd be right to set me straight. Like I said, 2/3 coordinates need to be fixed for any linking to happen along the third axis. So, there can be only one link at a time in any expression, which strips any logical meaning from the above horror case.

It just seems to me that we're on a slippery slope of complexity.

I'm not a big buyer of slippery slope arguments. I'd rather deal with arguments about what's actually been suggested, and how it relates to current reality instead of some imaginary mass immigration of new Eureka users in the future.

[SpAce]

A bit off-topic. Somewhat related to the 3D notation, I found a quote that exactly matches the way I look at the sudoku grid -- or cube, actually:

For now, forget standard Sudoku cells and digits as I don't rely on either and I will avoid the terms.

The physical picture.

Start with a 9x9x9 cube sitting on a table with a viewer facing one side of the cube. The cube has 729 identical cubical units. Since this is a crystal cube, you can look from any face to the opposite face through 81 channels and each channel has 9 cubical units running from face to face. The 3 cube faces, top, left, and front represent 3 orthogonal groups of 81 channels that intersect. These channels are Sudoku sets and Sudoku rules say that each of the 324 sets (now incluing 81 box sets) must contain exactly one object for a total of 81 objects in the cube. The box sets are horizontal 3x3x1 regions. This is sufficient to define Sudoku and solve puzzles.

Coordinates and labels

The coordinate system is 3D where the left to right channels are rows, front to back channels are columns, top to bottom channels are stacks, and boxes are the horizontal 3x3x1 regions. The 81 objects can be all the same or different, it doesn't matter.

In fact, I'd love to have a physical cube like that with which to play The fun bit is that it's actually playable no matter which side you're looking at. I've solved a couple of sudokus completely with only the nr or nc space, and I'm conjecturing that anything that can be done in one space can be done in the others (it just looks different). Interestingly enough, I think Denis Berthier has said (somewhere) that it shouldn't be possible because supposedly only Latin Squares rules can be used in the nr or nc spaces, i.e. box constraints aren't usable. Either I misunderstood what he meant, or it's obviously crap, because the box constraints are almost easier to use in those spaces.

[Cenoman]

In fact, I'd love to have a physical cube like that with which to play The fun bit is that it's actually playable no matter which side you're looking at. I've solved a couple of sudokus completely with only the nr or nc space, and I'm conjecturing that anything that can be done in one space can be done in the others (it just looks different). Interestingly enough, I think Denis Berthier has said (somewhere) that it shouldn't be possible because supposedly only Latin Squares rules can be used in the nr or nc spaces, i.e. box constraints aren't usable. Either I misunderstood what he meant, or it's obviously crap, because the box constraints are almost easier to use in those spaces.

Here is mini-row 1, in box 1, of a (solved) sudoku grid in canonical form, written in its r-c space:

Code: Select all

  +--c1----c2----c3---+--c5----c5--
r1|  1     2     3    |  .     .   
r2|  .     .     .    |  .     .   
r3|  .     .     .    |  .     .   
  +-------------------+------------
r4|  .     .     .    |  .     .   
r5|  .     .     .    |  .     .

The corresponding box 1 of the same grid, written in its n-c space:

Code: Select all

  +--c1----c2----c3---+--c5----c5--
n1|  1     .     .    |  .     .   }
n2|  .     1     .    |  .     .   }digit 1 = number of the row occupied by digits 1, 2, 3 in r-c space
n3|  .     .     1    |  .     .   }
  +-------------------+------------
n4|  .     .     .    |  .     .   
n5|  .     .     .    |  .     .

Obviously, there are three digits 1 on the mini-diagonal of box 1, which is a violation of valid sudoku grids.
No such violation exists in row n1 of n-c space: there must be one digit 1 per column, each in a different row. Likewise, no such violation exists in column c1 of n-c space: each column must contain digits 1 to 9, one per row.

What Denis Berthier meant is that n-c and n-r spaces are not sudoku grids, they are only Latin squares. Some sudoku methods of resolution may be used in such spaces (notably naked and hidden sets, ALSs, AICs...), but searches of strong and weak links shall be limited to rows and columns. Weak links are nonsense in "boxes"; actually, boxes do not exist in n-c and n-r spaces. Of course, boxes can be drawn, but it's useless.

[SpAce]

In fact, I'd love to have a physical cube like that with which to play The fun bit is that it's actually playable no matter which side you're looking at. I've solved a couple of sudokus completely with only the nr or nc space, and I'm conjecturing that anything that can be done in one space can be done in the others (it just looks different). Interestingly enough, I think Denis Berthier has said (somewhere) that it shouldn't be possible because supposedly only Latin Squares rules can be used in the nr or nc spaces, i.e. box constraints aren't usable. Either I misunderstood what he meant, or it's obviously crap, because the box constraints are almost easier to use in those spaces.

Here is mini-row 1, in box 1, of a (solved) sudoku grid in canonical form, written in its r-c space:

Code: Select all

  +--c1----c2----c3---+--c5----c5--
r1|  1     2     3    |  .     .   
r2|  .     .     .    |  .     .   
r3|  .     .     .    |  .     .   
  +-------------------+------------
r4|  .     .     .    |  .     .   
r5|  .     .     .    |  .     .

The corresponding box 1 of the same grid, written in its n-c space:

Code: Select all

  +--c1----c2----c3---+--c5----c5--
n1|  1     .     .    |  .     .   }
n2|  .     1     .    |  .     .   }digit 1 = number of the row occupied by digits 1, 2, 3 in r-c space
n3|  .     .     1    |  .     .   }
  +-------------------+------------
n4|  .     .     .    |  .     .   
n5|  .     .     .    |  .     .

Obviously, there are three digits 1 on the mini-diagonal of box 1, which is a violation of valid sudoku grids.

The most obvious thing is that the latter box is drawn incorrectly, because we're looking at a different side of the sudoku cube! If you do it like that, it seems a bit like a straw man argument -- why would anyone even attempt to use boxes like that in other than rc-space? I certainly didn't mean it. In the nc-space only the vertical box lines are both valid and useful, and the same is true about the nr-space (in the rn-space they would be horizontal, which makes it work differently and thus a less useful companion to the nc-space).

So, it should be self-evident that we can't draw the boxes normally in the nr or nc spaces, but it doesn't mean that the boxes and their constraints don't exist and can't be used! Of course they do because it's the same cube, just viewed from a different angle. The boxes are still there and quite usable in manual solving once you figure out how they're mapped to the nr and nc projections (or rn and cn, but they seem more awkward to me). To me it was obvious the first time I translated an rc grid into nr and nc. Using box constraints wasn't just possible -- it was easy. That was my whole point earlier.

What Denis Berthier meant is that n-c and n-r spaces are not sudoku grids, they are only Latin squares.

That's obviously true. However, it's only true if their relationship to the underlying 3D cube is forgotten and they're seen as independent 2D entities. From that point of view those spaces are clearly just Latin squares, but leaving it at that is not very helpful for any practical purpose. If the hidden box-constraints are left out of any consideration, I think the whole concept of the nr and nc spaces becomes quite useless, because then those grids aren't independently solvable at all. Of course the other option is not quite as trivial to understand, but it's very easy to use once you do. As far as I know, Denis never even mentioned that other option, but I haven't read his books so I don't know for sure. In general, it seems to me that his interest in sudoku was/is more theoretical than practical.

Some sudoku methods of resolution may be used in such spaces (notably naked and hidden sets, ALSs, AICs...), but searches of strong and weak links shall be limited to rows and columns. Weak links are nonsense in "boxes"; actually, boxes do not exist in n-c and n-r spaces.

I presume you're still referring to Denis' limited theoretical reality. The boxes surely exist, as you must know, but they don't look like the familiar squares from the nr or nc perspectives because we're not looking at them from the top (like in rc). They're partly hidden, but still very usable. When that is taken into account, I conjecture that every valid resolution method is equally available in those spaces, and also that every sudoku solvable in one space is solvable in the others. I lack the skills to prove those conjectures, but I haven't seen anyone prove them wrong either.

Of course, boxes can be drawn, but it's useless.

No, they specifically can't be (fully) drawn, but their constraints can still be used very easily. That's exactly what I did with yesterday's puzzle, when I included the nr-space solution: c(7=1)n1r6 - c(1=8|9)n1r8 => -c7 n1r7; stte. That conclusion wouldn't make any sense without the hidden box constraint. Here's what the full grid would look like (with only the first two rows filled, because I'm too lazy to manually convert the whole grid):

Code: Select all

  r  1     2     3       4      5      6    7       8      9
n .-------------------.-------------------.-------------------.
1 | 89    <6>   <2>   | <5>    38    1(7) | 49-7  1(89)  1348 |
  '-------------------'-------------------'-------------------'
2 | 46    <7>    1    | 89     2     <5>  | 49    <3>    468  |
  '-------------------'-------------------'-------------------'
3 |                   |                   |                   |
  '-------------------'-------------------'-------------------'
4 |                   |                   |                   |
  '-------------------'-------------------'-------------------'
5 |                   |                   |                   |
  '-------------------'-------------------'-------------------'
6 |                   |                   |                   |
  '-------------------'-------------------'-------------------'
7 |                   |                   |                   |
  '-------------------'-------------------'-------------------'
8 |                   |                   |                   |
  '-------------------'-------------------'-------------------'
9 |                   |                   |                   |
  '-------------------'-------------------'-------------------'

There are no boxes as we're used to seeing them, but they're still there and quite visible and usable when you know how. The vertical box lines still depict one of the two box boundaries (in this case related to the r-coordinate), but the horizontal lines are only there to separate the n-rows more clearly. The second box boundary is hidden in the candidate values (because they're columns). It's not obvious in this flat representation, but it's very clear and easy to use if the candidates are placed in the 3x3 way in their cells, as normally used in manual solving. In that case all micro-rows {123} {456} {789} in those cells are in their own boxes, and when that information is combined with the vertical box lines we can use the box constraints. With that information my nr-solution makes sense, because we know that (8|9) can't coexist in the same mini-row with a 7:

c(7=1)n1r6 - c(1=8|9)n1r8 => -c7 n1r7

Quite surprisingly, I have to presume that Denis hadn't figured that out or he hadn't drawn his extended grids without any box boundaries. If he had, he would have also noticed that it's much more natural to use the nr-space instead of rn (because the boxes can be used the same way in both nr and nc, but not in rn and nc). I figured it out the first time I converted an rc grid into these extra spaces. After that I could solve in those spaces just as easily as in the rc-space, or in some cases more easily. Seems to me that Denis had a great idea but he didn't fully understand how it would really work in manual solving (which I think he's admitted is not his strong suit).

Edit: Partly rewritten.