The New Sudoku Players' Forum

by **ArkieTech** » Sat Jul 27, 2019 1:52 pm

Code: Select all: *-----------* |...|..3|.2.| |..9|2..|.8.| |.2.|..1|9.6| |---+---+---| |...|..4|3..| |5..|9.7|..8| |..1|8..|...| |---+---+---| |2.5|3..|.6.| |.3.|..2|1..| |.4.|7..|...| *-----------*

by **SpAce** » Sat Jul 27, 2019 7:44 pm

I couldn't find an stte solution manually in a reasonable time, so this is just my AIC translation of a kraken found by Hodoku. In other words, it doesn't count. What pisses me off is that I should have found it without any cheating but gave up too easily. Too hot weather for solving, I guess. Hopefully someone finds something nicer.

Code: Select all: .----------------------.-------------.-------------------. | 6 1578 478 | 45 9 3 | f457 2 1457 | | a[34]1 b15 9 | 2 7 6 | c45 8 1345 | | h(7)-34 2 fg347 | 45 8 1 | 9 g3457 6 | :----------------------+-------------+-------------------: | 789 789 2 | 1 6 4 | 3 579 579 | | 5 6 e34 | 9 23 7 | d24 1 8 | | a[34] 79 1 | 8 23 5 | 6 479 2479 | :----------------------+-------------+-------------------: | 2 179 5 | 3 14 89 | e478 6 479 | | 789 3 78 | 6 45 2 | 1 4579 4579 | | b19 4 6 | 7 15 c89 | d258 359 2359 | '----------------------'-------------'-------------------'

(34=1)r62c1 - (1=59)r2c2,r9c1 - (5|9=48)r2c7,r9c6 - (4|8)r59c7 = (48-3|7)r5c3,r7c7 = (37)r3c3,r1c7 - r3c38 = (7)r3c1 => -34 r3c1; stte

as Kraken Row 7R3: Show

as 10x10 TM: Show

by **eleven** » Sat Jul 27, 2019 10:27 pm

SpAce wrote:Too hot weather for solving, I guess.

I always disliked the winter. Now i dislike the summer too (if not on holiday).
I did not even find a kraken stte.
I think, your last link needs to remember the 3 in r3c3.

by **SpAce** » Sat Jul 27, 2019 11:28 pm

eleven wrote:I think, your last link needs to remember the 3 in r3c3.

What do you mean? I can't spot the problem:

(37)r3c3,r1c7 - r3c38 = (7)r3c1

There's only one way (3&7) can be in r3c3,r1c7: 3r3c3&7r1c7. With that combo neither 7r3c3 nor 7r3c8 can be true, which leaves just 7r3c1. Or vice versa, if one of 7r3c3|8 is true then (3&7)r3c3,r1c7 can't be. To me it seems that every link works, both ways. Do you see something else?

Does the lack of explicit 7 in r3c38 cause confusion? In my style it's implied by the rightmost digit of the previous node (and in this case even more clearly by the next node). I definitely want the (7) in the last node, so it would seem redundant and cluttered to have it twice. However, I admit that in this case it's a bit tricky because both candidates of (37) have a weak link to the same digit (7). In any case, this is the fully expanded form of what the above chain fragment was supposed to depict:

(3)r3c3&(7)r1c7 - (7)r3c3|(7)r3c8 = (7)r3c1

by **SteveG48** » Sun Jul 28, 2019 1:05 am

Code: Select all: *--------------------------------------------------------------* | 6 g1578 g478 | 45 9 3 | af457 2 1457 | |cg134 g15 9 | 2 7 6 | b5-4 8 1345 | | 347 2 347 | 45 8 1 | 9 3457 6 | *--------------------+-------------------+---------------------| | 789 789 2 | 1 6 4 | 3 579 579 | | 5 6 bi34 | 9 23 7 | aj24 1 8 | |ch34 79 1 | 8 23 5 | 6 479 2479 | *--------------------+-------------------+---------------------| | 2 179 5 | 3 14 89 | af478 6 479 | | 789 3 78 | 6 45 2 | 1 4579 4579 | | c19 4 6 | 7 15 d89 | e258 359 2359 | *--------------------------------------------------------------*

Yuck.
4r157c7 = (4*)r5c3&(4#)r2c7 - (4=139)r269c1 - (9=8)r9c6 - r9c7 = (78)r17c7 - (7|*4|#4=1358)b1p2345 - (3=4)r6c1 - r5c3 = 4r5c7 => -4 r2c7 ; stte

by **SpAce** » Sun Jul 28, 2019 4:13 am

SteveG48 wrote:Yuck.
4r157c7 = (4*)r5c3&(4#)r2c7 - (4=139)r269c1 - (9=8)r9c6 - r9c7 = (78)r17c7 - (7|*4|#4=1358)b1p2345 - (3=4)r6c1 - r5c3 = 4r5c7 => -4 r2c7 ; stte

Nice

The same in matrix form (I think):

9x9 TM: Show

Here's a variant of the theme:

Code: Select all: .---------------------.-------------.--------------------. | 6 c1578 c478 | 45 9 3 | d457 2 1457 | | f13(4) c15 9 | 2 7 6 | 5-4 8 1345 | | 347 2 347 | 45 8 1 | 9 3457 6 | :---------------------+-------------+--------------------: | 789 789 2 | 1 6 4 | 3 579 579 | | 5 6 bh34 | 9 23 7 | ah2[4] 1 8 | | g34 79 1 | 8 23 5 | 6 479 2479 | :---------------------+-------------+--------------------: | 2 179 5 | 3 14 89 | d478 6 479 | | 789 3 78 | 6 45 2 | 1 4579 4579 | | e19 4 6 | 7 15 e89 | d258 359 2359 | '---------------------'-------------'--------------------'

(4)r5c7 = r5c3 - (4=1*|7)b1p235 - r1c7 = (78)r79c7 - (8=91)r9c61 - (*1=4@|3)r1c2 - r6c1 = (34)r5c37 => -4 r2c7; stte

Perhaps better as an honest kraken:

Code: Select all: Double Kraken AALS (58+147)b1p235 & AALS (134)r2c1 (1)r12c2 -------------------------------- || \ (7)r1c23 - r1c7 = (78)r79c7 - (8=91)r9c61 - (1)r2c1 || || || (3)r2c1 - r6c1 = (3-4)r5c3 = (4)r5c7 || || || (4)r2c1 (4)r1c3 - r5c3 = (4)r5c7 => -4 r2c7; stte

8x8 TM: Show

Edit: simplified the chain a bit.

by **SteveG48** » Sun Jul 28, 2019 7:40 pm

Code: Select all: *-------------------------------------------------------------* | 6 e1578 e478 | 45 9 3 |af457 2 1457 | |cd134 e15 9 | 2 7 6 | b5-4 8 1345 | | d347 2 347 | 45 8 1 | 9 3457 6 | *--------------------+-------------------+--------------------| | 789 789 2 | 1 6 4 | 3 579 579 | | 5 6 b34 | 9 23 7 |af24 1 8 | |cd34 79 1 | 8 23 5 | 6 479 2479 | *--------------------+-------------------+--------------------| | 2 179 5 | 3 14 89 | a478 6 479 | | 789 3 78 | 6 45 2 | 1 4579 4579 | | e19 4 6 | 7 15 e89 | f258 359 2359 | *-------------------------------------------------------------*

I like this variant on mine better than my original:

4r157c7 = r2c7&r5c3 - 4r26c1 = 4r3c1&(13)r26c1 - (1|4=578)b1p235&(89)r9c26 - (7|8=245)r159c7 = -4 r2c7 ; stte

by **SpAce** » Mon Jul 29, 2019 12:34 am

SteveG48 wrote:I like this variant on mine better than my original:

4r157c7 = r2c7&r5c3 - 4r26c1 = 4r3c1&(13)r26c1 - (1|4=578)b1p235&(89)r9c26 - (7|8=245)r159c7 = -4 r2c7 ; stte

Me too, but you can't write the colored part like that (and I'm not talking about the minor typo -> r9c16). A valid counter-argument is that you just did, but as previously discussed (and I think you agreed), it's ambiguous. Should be:

... - (1|4)b1p235,r9c1 = (578)b1p235&(89)r9c16

As a side note, I'd personally change the digit orders too to match the links, but I'm the last one to argue about personal preferences. Having taken quite a bit of flak in that department myself, I guess I'm entitled to voice an opinion however

I'm just saying that since you like complex chains with big and often split ALS nodes, sticking to the Eureka standard of placing the linking digits to the proper sides might make your chains easier to track for most people. At least it seems to me that these days everyone else (who is not omitting the bystanders) is adhering to that standard, so it's probably not just me who'd like that.

Incidentally I recently ran into an old discussion about writing ALS nodes, where you stated:

SteveG48 wrote:I personally prefer to just list the candidates in numerical order, but I don't think it's important one way or the other. I think my preference came from a discussion with David P Bird, but I'm not sure of that.

It would be interesting to know what David's argument for that style might have been. To me it's the hardest to read of all possibilities (including omitted bystanders, though I don't like that either). While not critical (as in making anything incorrect), I don't quite agree that it's totally unimportant. Having the linking digits on the proper sides keeps the chain flowing more naturally both ways, imho. That being said, you're of course most welcome to stick to your own preference. I won't stop reading your chains because of it

PS. David wasn't right about everything. For example:

David P Bird wrote:As you have discovered, tying to read memory chains in the reverse direction requires fortune foretelling abilities!

Wrong. A properly written memory chain is readable both ways. It's just not an AIC and can't be read like an AIC.

That being said, the example in question was not properly written or even needed, but that's irrelevant. Instead of bashing the whole practice -- which is sometimes quite useful if not elegant -- David should have guided to a better way to write it, imho. Then again, if someone has a total personal ban on something out of principle, they can hardly tell the difference between a good and a bad way of doing it. That's why I'm not a big fan of locked principles as they're a hindrance to a more complete understanding and flexible options. In other words, I rather take my guidance from: "If one is to understand the great mystery, one must study all its aspects, not just the dogmatic narrow view of the Jedi."

by **SteveG48** » Mon Jul 29, 2019 1:18 am

SpAce wrote:Me too, but you can't write the colored part like that (and I'm not talking about the minor typo -> r9c16). A valid counter-argument is that you just did, but as previously discussed (and I think you agreed), it's ambiguous. Should be:

... - (1|4)b1p235,r9c1 = (578)b1p235&(89)r9c16

You're right of course. I hate it when I let that happen.

It would be interesting to know what David's argument for that style might have been. To me it's the hardest to read of all possibilities (including omitted bystanders, though I don't like that either).

I wonder more and more why I don't prefer the omitted bystander option. Sometimes including the bystanders is downright confusing. In those cases, I'll omit them. The 7/28 puzzle is an example if I recall from earlier today. Cenoman tends to put some bystanders on the left side of the link in situations where I'd put them on the right side. I can't argue for either as being preferable.

The argument that I've seen for including bystanders is based on clarity. It's presumed that including them makes things easier to understand, particularly for newcomers. I just don't know if that's true. I really don't know if leaving them out would have made things easier or harder for me when I was first learning the notation.

While not critical (as in making anything incorrect), I don't quite agree that it's totally unimportant. Having the linking digits on the proper sides keeps the chain flowing more naturally both ways, imho. That being said, you're of course most welcome to stick to your own preference. I won't stop reading your chains because of it

And there's an argument for just leaving the bystanders out. The chain certainly flows naturally when only the relevant things are there.

by **SpAce** » Mon Jul 29, 2019 5:36 am

SteveG48 wrote:I wonder more and more why I don't prefer the omitted bystander option.

Well, that wasn't on my wish list

It's the second worst option, as far as I'm concerned. Or maybe the worst. Depends on the day. It's also much farther from your current style than mine is. Why do you hate "my" way (also the standard Eureka convention, and probable preference of most) so much that you'd rather consider such a drastic move?

I'd really love to hear your reasons for disliking the standard in this case. I'm all for kicking standards and conventions in the face when they don't make sense, but I strongly think this one does. I've still missed seeing your opposing argument. (Not that you need one -- I accept if you simply state that it's your preference, period. I'm just extremely confused if you now start speaking for the omitted-bystanders side. That makes no sense.)

Sometimes including the bystanders is downright confusing. In those cases, I'll omit them.

Yeah, me too, but those cases are rare -- or maybe non-existent. For example, I chose to write the AALS node in my chain above: (4=1*|7)b1p235, because I thought it was simpler that way. However, in hindsight even that would have probably been better with bystanders: (458=1*|7)b1p235. Somehow I thought it would be more complicated, so I didn't bother thinking it through. Such AALS nodes with ORed linking digits are the only case where I've usually left the bystanders out, but I think I'll reconsider that too. Do you have a better example of when bystanders are "downright confusing" (using the standard style)?

The 7/28 puzzle is an example if I recall from earlier today.

I don't see why that would qualify. I see no problem in using bystanders with your solution. The only problem (besides a minor typo) I see is the confusing digit order which is a self-inflicted injury:

SteveG48, July 28 wrote:(3=567)r289c1 - 5r4c1 = (35)b5p1238 => -3 r3c5 ; stte

Both links surrounding the 5r4c1, especially the latter, are hard to read for me. Skipping bystanders wouldn't fix the latter link at all because there's nothing to skip (you obviously can't remove the 5 in the last node). I'd write it:

I wrote:(3=675)r389c1 - r4c1 = (53)b5p1238 => -3 r3c5; stte

Now all links, including the elimination links (3 at both ends), work logically. Sure, they did work before too, but they didn't look logical. Also, there's now no need for (5) in the middle node because it's implied by its neighbors (but it could be added if one prefers). (Btw, I also dislike unbracketed digits in AICs, but that's a different and less pressing issue

I can live with them in the middle of a chain (like here), but they look especially out-of-place as end nodes. Even worse is not having a digit at an end-node at all, like ending a chain (5)r1c2 = ... = r3c3. That practice breaks all AIC symmetry and backwards readability, imho.)

Cenoman tends to put some bystanders on the left side of the link in situations where I'd put them on the right side. I can't argue for either as being preferable.

I can, but I haven't dared to say anything

Truth is, I don't really see the reasoning for Cenoman's practice either. Most people read from left to right, so it seems way more natural to read (1=234) than (123=4), unless there's a good reason to isolate the right-linking candidate(s). I doubt I'm the only one with that preference. But again, that doesn't stop me from reading Cenoman's chains any more than yours. It just looks a bit weird and slows down my chain tracking for a fraction of a second.

Overall I'm not totally against it either. As I've said before (as a defense of my own tricky constructs), I think it's a good thing learners can see lots of different but correct variants, even if arguments can be made against their regular use. If someone doesn't understand Cenoman's ALS style, they also can't understand why ALS chains work both ways or the full scope of ALS logic in the first place. So, getting exposed to such practice on a regular basis might help someone overcome such deficiencies (especially if they dare to ask).

I know I had to ask about this specific issue when I was a newbie, because I didn't see how (normally written) ALS chains could be read from right to left. It was a major revelation to understand that the whole (123) block in (123=4) is a single boolean (1&2&3) and only true if all of those digits are present (so a weak-link with any of those links kills it, making the right-hand side true). I can tell from relatively recent experience that it's not self-explanatory at all.

The argument that I've seen for including bystanders is based on clarity. It's presumed that including them makes things easier to understand, particularly for newcomers. I just don't know if that's true. I really don't know if leaving them out would have made things easier or harder for me when I was first learning the notation.

Well, I'm the latest newcomer here by a large margin. For what it's worth, I remember vividly that seeing ALS nodes without bystanders was totally unintuitive at first. In fact, I had to ask someone explain to me why those links were even valid. The good thing about that was an increased understanding of ALS logic and the nature of AIC links in general. That being said, now that I can probably understand and write any variant of AICs at will, and in general prefer concise notations, I still think omitting bystanders is a bad practice (and it has nothing to do with newbies). However, just like with Cenoman's ALS style, I don't want to drive that practice to extinction because it serves an educational purpose. People should understand all correct AICs, even if some are arguably more preferable than others.

Btw, I find it kind of funny that people repeatedly worry about what's hard for newbies, and then ignore someone who's actually been there very recently. I haven't yet lost my memories of those experiences. If I say that omitted bystanders and Cenoman's reversed style were hard for me to understand as a newbie, shouldn't it count for something (if anyone thinks the whole newbie argument is relevant anyway)? I kind of doubt that my cognitive skills are so much below average that my experience is irrelevant. If something was/is hard for me, it's probably not exactly easy for everyone else either. I know I'm already getting blind to many things that were originally far from obvious, but I bet it's much more true for the veterans who've been around many times longer. At least I can still remember what things were hard to learn and what it took to learn them.

And there's an argument for just leaving the bystanders out. The chain certainly flows naturally when only the relevant things are there.

That would be true if the bystanders weren't relevant at all. They are, in more than one way.

First, with loops they're actually essential, and those who prefer to omit them, usually forget them with loops too -- leading to either missed or unjustified (looking) eliminations. The standard style is the ONLY one that makes sense with loops because both bystanders and linking digits have their own eliminations, and it's practically impossible to depict that with any other digit ordering (and definitely impossible by omitting the bystanders). Can you deny that? It's funny that I've made that loop argument many times but don't remember receiving any response from anyone.

Second, omitting bystanders makes it harder to check the ALS node against the grid, so at least for me the overall time spent tracking the chain is still longer negating the better flow. Also, such ALS nodes are harder to spot within a chain at a glance, because they look like bivalues until you look more closely. Last but not least, it makes complex chains look simpler than they are, which is a bit misleading -- bystanders keep mammoth ALS nodes honest.

I prefer having the best of both worlds: included bystanders (for easy grid-checking etc) and the linking digits at their logical places (for an easy flow). To me it's clearly the sweet spot, and both the standard and most of the other players seem to agree. Obviously you must have some real reason for avoiding it, but it's still very much unclear to me what it is.

PS. Note: I'm not trying to be argumentative! I'm just curious. I'm especially curious why my loop argument has been ignored by everyone thus far. I really don't see how you'd write an understandable ALS loop (with bystander eliminations) with either your style or with omitted bystanders.

by **SteveG48** » Mon Jul 29, 2019 2:13 pm

SpAce wrote:
SteveG48 wrote:I wonder more and more why I don't prefer the omitted bystander option.

Well, that wasn't on my wish list It's the second worst option, as far as I'm concerned. Or maybe the worst. Depends on the day. It's also much farther from your current style than mine is. Why do you hate "my" way (also the standard Eureka convention, and probable preference of most) so much that you'd rather consider such a drastic move?

I'd really love to hear your reasons for disliking the standard in this case. I'm all for kicking standards and conventions in the face when they don't make sense, but I strongly think this one does. I've still missed seeing your opposing argument. (Not that you need one -- I accept if you simply state that it's your preference, period. I'm just extremely confused if you now start speaking for the omitted-bystanders side. That makes no sense.)

I really don't dislike the standard. Obviously, it's what I use now and have used for a long time. I just question my own preferences from time to time. Leaving the bystanders out clearly makes for a shorter notation. People here were calling it "abbreviated" notation for awhile. The reaction against it was based on clarity.

The clarity argument is important to me, but I began wondering whether the standard was really clearer to most people than the abbreviated. Apparently it is to you, and that's a good data point for me. I don't anticipate changing.

by **SpAce** » Tue Jul 30, 2019 5:04 am

Hi Steve,

I already posted one reply earlier, but deleted it because I was sleep-deprived and at least partly misread your message. Sorry about that. Let's try again. Before I even begin, I want to stress that whatever you prefer and choose is your own business. I can read pretty much any format, so none of this is a huge deal to me. Some just take a bit more effort or bother my sense of aesthetics more than others, but they're not show-stoppers. In fact, I like that there's some variance in dialects, as I've stated before. I just think that there should be a reason for every choice, and I'm interested in yours.

SteveG48 wrote:I really don't dislike the standard. Obviously, it's what I use now and have used for a long time.

Part of the problem is that there's no current official Eureka standard, as far as I know, so I can't really dispute that claim because I don't know what standard you're referring to. However, when I use that term in this context, I mean the old and tiny Sudopedia reference. Parts of it are clearly obsolete, and it's far from complete, but it does say something about writing ALS nodes very clearly:

Sudopedia wrote: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.

(1)r5c4-(1=264)r5c789-(4)r4c8

Taken literally, that's in direct conflict with both your style and Cenoman's. The abbreviated notation is not mentioned anywhere. So, all of them are clearly deviations from this particular "standard". As far as I'm concerned, none of them are improvements either. Also, whether that part of the documentation is considered official standard or not, it seems to me that most players actually abide by that convention making it de facto standard. Either way, it's what I mean when I say "standard", because it's the only one I know with any semblance of official status.

I just question my own preferences from time to time.

That's good. So do I. In fact, when I started writing ALS chains I used your style because it seemed easiest to write the digits in their natural order. Only later did I see the above Eureka reference and some abiding examples, and after a while it started making more sense to me. So here we are. (Btw, one personal addition in my style, picked from someone I can't remember, is that I also try to order the other digits and cells in a way that corresponds with the internal logic flow, but that's not nearly as important as having the linking digits on the sides. In fact, I sometimes question if it's a good idea at all, especially when it doesn't completely work. So, I'm not even trying to sell that part -- only the linking digits, as depicted in the above "standard".)

Leaving the bystanders out clearly makes for a shorter notation. People here were calling it "abbreviated" notation for awhile. The reaction against it was based on clarity.

Yeah, if a shorter notation were the only goal, it would make sense to add my 3D notation to the mix as well

Not so popular, was it? Some people here have thought that my notational goal is to abbreviate as much as possible, and it's partly true, but not for the sake of itself. If it were so, I would have adopted the abbreviated ALS notation a long time ago, but I haven't. The simple reason is that it makes chains harder to read for me (plus some other reasons I listed earlier). I ultimately dropped the 3D notation for the same reason -- not because so many people complained about it, but because I never learned to read it quickly enough myself.

All the compacting I do is such that it's also easy to read -- for me. For me a properly written compact notation is actually easier (or at least more enjoyable) to read than a long-winding simple chain, which is one (not the only) reason why I try to find shortest possible expressions without compromising correctness or losing relevant information. The abbreviated ALS notation loses some relevant information, imho, so it doesn't work for me. Besides, there's usually a natural work-around with fewer digits and cells with the complementary AHS.

The clarity argument is important to me, but I began wondering whether the standard was really clearer to most people than the abbreviated. Apparently it is to you, and that's a good data point for me. I don't anticipate changing.

So, I take it that you're not seriously considering switching to the abbreviated notation after all? Good. However, my original point wasn't about the abbreviated notation at all. I didn't think it was in the cards for you in the first place, but you brought it up yourself, which kind of surprised me. It's a different discussion, and I think we've now covered that. My real question was about your current style and why you prefer it over the "standard" digit ordering. I'm still missing your reasons.

PS. I'm also still missing any comment about my loop question, so let me repeat that once again:

SpAce wrote:The standard style is the ONLY one that makes sense with loops because both bystanders and linking digits have their own eliminations, and it's practically impossible to depict that with any other digit ordering (and definitely impossible by omitting the bystanders). Can you deny that? It's funny that I've made that loop argument many times but don't remember receiving any response from anyone.
...
I'm especially curious why my loop argument has been ignored by everyone thus far. I really don't see how you'd write an understandable ALS loop (with bystander eliminations) with either your style or with omitted bystanders.

Again, by "standard" I mean the Sudopedia ALS style depicted above, i.e. the one I've adopted. In other words, not (exactly) your standard

(Btw, please share if you know of a more modern Eureka reference.)

by **SteveG48** » Tue Jul 30, 2019 12:39 pm

SpAce wrote:My real question was about your current style and why you prefer it over the "standard" digit ordering. I'm still missing your reasons.

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

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

by **Cenoman** » Tue Jul 30, 2019 9:32 pm

Having not so much time left for sudoku in these weeks, I had a quick look to the puzzle above, and having nothing useful to say, I forgot it. 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.

by **SteveG48** » Tue Jul 30, 2019 11:26 pm

SpAce wrote:The standard style is the ONLY one that makes sense with loops because both bystanders and linking digits have their own eliminations, and it's practically impossible to depict that with any other digit ordering (and definitely impossible by omitting the bystanders). Can you deny that? It's funny that I've made that loop argument many times but don't remember receiving any response from anyone.

You make a good point here. 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. 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 =.

The New Sudoku Players' Forum

July 27, 2019

July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019

Re: July 27, 2019