The New Sudoku Players' Forum

[SpAce]

I have no defendable reason. So I'll try it the standard way.

Ok! Glad to hear that, but I hope you don't feel pressured to do so. I'm sure everyone is fine if you end up preferring to stick to your old way. I can (vaguely) remember that the "standard" way didn't feel natural for me at first -- until it did (and then there was no going back). Anyway, personal preferences aren't a debatable item, so do what you like best!

Is there a standard ordering for the bystanders other than natural order?

I don't think so. I think the natural order is fine for anything but the linking digits. Like I said, I do some reordering for the bystanders too when they get locked in a specific order into specific cells, but that's hardly necessary. It makes the most sense when the ALS is a shorthand for an XY-Chain, allowing for an easier tracking (matching that of the XY-Chain). It's also necessary when using the comma notation (when order actually matters). In non-degenerate ALSs keeping the natural order for bystanders is probably a good idea and most in line with the "standard". (In other words, I'm obviously deviating from the standard as well, so it's a bit hypocritical for me to use it as an argument )

You make a good point here [about loops]. It justifies carrying the bystanders and having the linking digits to the preceding and following nodes at the extreme left and right ends of the list.

Thanks! That's the affirmation I've been looking for There's also an optional separator I like to add in those cases, making the boundary between the linking digit(s) and the bystanders clearer. For example:

Code: Select all

.----------------------------.----------------------.------------------.
| 24579      1579-2   1579-4 | 2468  24789   2489   | 45679  3    5679 |
| 6         b279     b479    | 5     234-79  234-9  | 1      8   b79   |
| 4579       8        3      | 46    1       49     | 45679  2    5679 |
:----------------------------+----------------------+------------------:
| 248-1     a12      a14     | 9     5       7      | 3      46   68-1 |
| 34578-1    6        57-1   | 148   348     1348   | 578    9    2    |
| 345789-1   3579-1   579-14 | 28    2368    123468 | 578    47   1578 |
:----------------------------+----------------------+------------------:
| 37         37       6      | 18    89      189    | 2      5    4    |
| 59         4        8      | 7     26      256    | 69     1    3    |
| 159        159      2      | 3     46      456    | 6789   67   6789 |
'----------------------------'----------------------'------------------'

(2=1'4)r4c23 - (4=79'2)r2c392 - loop => -2 r1c2, -4 r16c3, -1 r4c9,b4p146789, -7 r2c5, -9 r2c56

variants: Show

(2=1'4)r4c23 - (4'79=2)r2c392 - loop

(2'1=4)r4c23 - (4=79'2)r2c392 - loop

(2'1=4)r4c23 - (4'79=2)r2c392 - loop

(4=1'2)r4c32 - (2=79'4)r2c293 - loop

(4=1'2)r4c32 - (2'79=4)r2c293 - loop

(4'1=2)r4c32 - (2=79'4)r2c293 - loop

(4'1=2)r4c32 - (2'79=4)r2c293 - loop

I've also seen brackets used for the same purpose (by blue, if I remember correctly):

(2=[1]4)r4c23 - (4=[79]2)r2c392 - loop

I originally did that too, but the hyphen does the job with fewer characters and better readability, I think.

Another example from the same source (all but one of the eliminations is due to the bystanders):

Code: Select all

.----------------------------.-----------------------.--------------------.
| 3469-178   346-178   69-78 |  246-7   1468-7  1247 | 158   157    1578  |
| 2         b1678     b678   | a67      158-67  15-7 | 3     4      9     |
| 5         b1478     b78    | a47      3       9    | 2     6      178   |
:----------------------------+-----------------------+--------------------:
| 13678      9         25678 |  2346-7  467     2347 | 156   12357  12357 |
| 367        23567     4     |  1       67      237  | 9     8      2357  |
| 1367       2367-1    267   |  5       9       8    | 16    1237   4     |
:----------------------------+-----------------------+--------------------:
| 479        457       1     |  8       2       3457 | 45    359    6     |
| 4689       24568     25689 |  349     145     1345 | 7     12359  12358 |
| 4789       24578     3     |  49-7    1457    6    | 1458  1259   1258  |
'----------------------------'-----------------------'--------------------'

(4=7'6)r32c4 - (6=178'4)b1p5698 - loop => -6 r2c5, -1 b1p12,r6c2, -78 b1p123, -7 b2p12356,r49c4

or:

(6=7'4)r23c4 - (4=178'6)b1p8956 - loop => (the same)

[SpAce]

Now my ears have been burning ("mes oreilles on sifflé" in French...). My way of writing ALSs is mentionned (and questioned) in posts above. I still miss time for a substanciated reply. So, Steve, SpAce, I put a bookmark on this July 27 discussion, and will come back on the topic later.

Great! We're looking forward to that! Note that I'm only very slightly questioning it (and apparently Steve isn't at all) You're more than welcome to continue using it. It would be great to hear your reasons for it, though. It's perfectly possible, or even likely, that there's some hidden logic that I've missed!

I still don't see the justification for the standard, which you and I both use, in which the linking digit to the preceding node is isolated to the left of the = , over the way that Cenoman does it, isolating the linking digit to the next node on the right side of the =.

I guess it's best to continue this discussion when Cenoman can participate. On my part, I already gave my reasons, but let's recap. Unlike the normal style, it was not intuitively understandable for the newbie me, and more importantly, it's still (very) slightly slower to read for the current me. It's a bit like my 3D notation -- perfectly logical, but takes an extra clock cycle to process when you're used to something else.

It doesn't make the chain any shorter either, so in most cases I just don't see the upside -- except the educational value I already mentioned. Yes, it does make the exit link clearer, but the price is paid on the entry (for those who're used to the other style). So, I can't really see why I'd like to use it everywhere as a replacement for the normal style, but I could see myself using it for a specific purpose, like to isolate multiple exit digits or to make a chain more symmetrical. For an example of the latter use case:

(73=6)r3c15 - (6=5)r9c1 - r4c1 = r6c23 - (53=7)r36c5 => -7 r3c6; ste

If I chose to write the last node like that, I'd still use the normal style on the first (and every other ALS node if there were more, unless I could make it really symmetrical but then it would be just for aesthetics):

(7=36)r3c15 - (6=5)r9c1 - r4c1 = r6c23 - (53=7)r36c5 => -7 r3c6

Now it has an upside: the eliminating digit is isolated on both sides making the conclusion easier to read. However, if the same is done for the first node (and others) too, the upside vanishes (for me the chain is then easier to read backwards). This is a bad example, though, because on the grid the first link is actually easiest to see as (73=6), so writing it that way makes sense. In general, the first node is the least confusing place to use that style because it doesn't have an incoming weak link, but it's usually the least useful one too (killing the mentioned upside). Everywhere else it still requires that extra cycle (for me).

Anyway, like I said, it's possible that I've missed some hidden semantics and value!

PS. Interestingly, it seems that this issue was also discussed here, which I already linked earlier. I think batman999's puzzlement over Cenoman's (75=6)r3c23 kind of proves my point that it's not exactly intuitive. However, I think it also proves my point about its educational value, presuming batman999 learned something from that discussion. So, in that light I would actually vote for Cenoman to keep using it. It might help someone to pick up a valuable insight about ALS logic. I know it did for me. (That being said, I still don't see a reason for everyone else to start using that style regularly.)

[Cenoman]

....this issue was also discussed here...

Thank you SpAce for reminding this old discussion.
I have nothing new to say.

Just a comment on my July 28 solution.

(73=6)r3c15 - (6=5)r9c1 - r4c1 = r6c23 - (53=7)r36c5 => -7 r3c6; ste

As said in the linked thread above, I consider any ALS as an ANS (almost naked set). When the ANS is made of an isolated candidate and a full naked pair, triple or quad, I'd rather write it:
Isolated candidate = Naked set, or Naked set = Isolated candidate (according to the chain linking direction), even for an endpoint ALS. What I did for July 28 puzzle.
To my eyes, the accordance with the PM is better. Do not search any other hidden semantics and value!

(but writing: (37=6)r3c15 - (6=5)r9c1 - r4c1 = r6c23 - (53=7)r36c5 => -7 r3c6; ste would be in a still better accordance with the visual appearance of the PM !!)

I was already warned recently (in a pm) that my ALSs were sometimes out of the Eureka notation. I will try to avoid eccentricities in the future.

[SpAce]

Hi Cenoman,

Just a comment on my July 28 solution.

(73=6)r3c15 - (6=5)r9c1 - r4c1 = r6c23 - (53=7)r36c5 => -7 r3c6; ste

As said in the linked thread above, I consider any ALS as an ANS (almost naked set). When the ANS is made of an isolated candidate and a full naked pair, triple or quad, I'd rather write it:
Isolated candidate = Naked set, or Naked set = Isolated candidate (according to the chain linking direction), even for an endpoint ALS. What I did for July 28 puzzle.
To my eyes, the accordance with the PM is better. Do not search any other hidden semantics and value!

Thanks for explaining! That's exactly the pattern I thought I saw after looking at a number of your solutions more closely. I just wasn't sure because some samples didn't seem to conform, but I guess there were reasons for those exceptions.

I understand the reasoning and accept that the practice has its benefits. Full ANSs with distinct spoiler candidates are the easiest ones to spot as ALSs (besides bivalue cells) and natural to see and write that way. However, for that exact reason I've actually trained myself to avoid highlighting that too much. I remember from my newbie days that those natural ALSs were the only kinds I could spot for a while, which of course was a bit limiting.

For example, if we had two peer cells with digits (12) and (23) I wouldn't have seen it as an an ALS because it didn't contain a full naked pair. (In fact, it's a lot like a finned sashimi fish, turning degenerate if any digit is removed.) Also, even if it were a "full" ALS with digits (123) and (23), I would have only seen the strong link (1=23) because it was the natural pairing. It took a while to learn that also (2=13) and (3=12) work just as well. For those reasons, I trained myself to treat them all equally. As long as it's N+1 digits in N cells within one house it's an ALS, with exactly the same logic no matter how the digits are distributed.

(but writing: (37=6)r3c15 - (6=5)r9c1 - r4c1 = r6c23 - (53=7)r36c5 => -7 r3c6; ste would be in a still better accordance with the visual appearance of the PM !!)

Maybe, but that would be much more in conflict with the Eureka convention, having a linking digit in the wrong place. I don't have much of a problem (if at all) with your current style, but I would with that (for the same reasons as with Steve's (prior) style). An argument can be made for pretty much any digit ordering, but at least for me the linking flow is the most important factor and shouldn't be compromised for any secondary reason. Also, the implicit weak links at the end points are the most important ones, so moving the 7 in the first node to the right would be doubly bad! (The first thing I look at in a chain is the end points to see how its elimination logic works. That's why I kind of liked the one I suggested with the isolated 7s at both ends.)

I was already warned recently (in a pm) that my ALSs were sometimes out of the Eureka notation. I will try to avoid eccentricities in the future.

Interesting. The reversed style currently under discussion is not a significant deviation, so I wouldn't worry about that at all. The only significant deviation I've noticed a couple of times lately is the use of multi-house sets as if they were normal ALSs. That has been quite surprising considering you mostly like uncompressed constructs. I've done that a couple of times too to compress a mundane fragment of an XY-Chain or something, but even I don't think it's a good idea as a general practice.

Of course, even such larger structures are perfectly correct because any booleans can be used as nodes, but I don't think they follow the Eureka spirit or enhance readability in most cases. Most importantly, I don't think they should be used in named patterns that are based on normal ALSs, such as Death Blossom (that's one example I can remember where you used one). People get confused, and names stop having any meaning, if named patterns with well-known definitions are suddenly extended without any warning.