smcroberts wrote:My aha! moment from this was the quote

Glad it helped!

You're right: I am currently doing exactly what you caution against: trying to cram my head with all the specific techniques. But I have been wondering if there are broader principles at work that could be learned and applied with less likelihood of going astray.

Good! There's nothing wrong with starting with specific techniques and building up from there. It's the bottom-up approach I mentioned, and it can work just fine. Almost everyone starts like that and it gets you going quickly. However, at some point you should start seeing similarities in those techniques and wondering if there are some underlying principles that make the patterns work -- and that's exactly where you seem to be right now!

Personally I aimed for that point very quickly when I started studying advanced sudoku techniques because I hate memorization. It's not because I have bad memory (I don't) but because I think it's stupid when there's probably a simple overarching logic to be discovered (and there is).

You indicate that the broader principles reside in some patterns I have not yet come across.

Glad you asked. It might come as a surprise that there are only two major paradigms that can explain almost all existing sudoku techniques: chaining and fishing. Chaining can exist as if-then-else type of implication chains or as static boolean logic in the form of

AICs, and it includes not only linear chains (simple) but also branching nets (complicated). By fishing I mean not only the common single-digit fishes but the omnipotent multi-digit

set logic developed by Allan Barker.

Every chain/net can be represented as a fish, and every fish can be represented as a chain/net, so theoretically they have equal powers and one could choose to learn just one. In practice, chaining is much simpler and it's the bread and butter of advanced solving, at least for most people. However, some heavily branching patterns are very poorly suited for chaining, and they're much easier to express and think in terms of set logic. Even basic fishes larger than X-Wing fall into that category, as something like a full Jellyfish would be very hard to express with chains. Some much bigger and more complicated patterns like MSLS would be almost impossible. In those cases, set logic is invaluable, but it can simplify other situations too. So, both is best, but I'd definitely start with chaining and concentrate on that for a long time before dwelling deeply into set logic.

So, do you have any recommendations as to where one could go to learn such things as Rank 1 Set Logic and Multi-Sector Locked Sets, etc.?

Above I gave the link to Allan Barker's set logic (and his excellent XSudo solver which, unfortunately, I haven't tried personally).

Here's also a brief intro to set logic and Rank 0 patterns I wrote some time ago. But, like I said, it's not where I would start. Most definitely I wouldn't start with something like

MSLS In fact, it was the last well-known technique that I learned myself, and a pretty good understanding of set logic was a prerequisite for that (imho).

(J)Exocets are even more complicated but they have better documentation and don't require set logic (though originally found through that). Both of those techniques are needed only in very difficult puzzles, so learning them can be safely delayed (possibly indefinitely, depending on one's ambitions).

I do know of AIC's and ALS's, but have considered them last-resort techniques due to their complexity.

Well, someone's basic techniques are another's last resort techniques. For me, and most other solvers here, AICs and ALSs are the bread and butter of almost any non-basic solving. They're not complex at all once you understand them and know how to look for them. Of course it might take a while to get to that point. For me it took a few months to get from a mediocre basic solver into a decent AIC/ALS solver, but it was because I skipped studying all those zillions of named patterns and concentrated on what I recognized as fundamental. It worked. After that it was trivial to learn all the named patterns as well because they were so easy to understand.

(Why did I bother to learn learn those patterns if I didn't really need them for solving? Well, it's fun, and knowing them is pretty much a necessity for effective communication. Spotting common patterns also makes solving faster and provides new opportunities for advanced solving when you learn to spot their almost-forms that can be used as nodes in chains. So, it's not like patterns are useless. Generic methods are just more important.)

The number of possible paths of an AIC, for instance, seems so overwhelming that learning to spot specific patterns seems more comfortable.

Seeing useful chains directly is not easy but there's an almost unfair tool to find them: coloring. It's the easiest way to find chains and nets, and it was another thing I recognized as a fundamental skill very early on. These days I can find chains without it (

a recent example) but I rarely bother if I'm in a hurry. My coloring technique is mostly explained

here. It's not the simplest, but I pretty much guarantee that it's the most powerful humanly-applicable coloring technique there is.

But I'm willing to alter my approach and expand my mind; learning this stuff is what makes Sudoku fun for me.

That's a good attitude. Either way, there's nothing wrong if you want to stick to the pattern-based methods, or go for something like TDP. I can't guarantee that my approach works for everyone, but I know it's worked for me.

So, I have begun looking into the TDP system of Robert Mauriès...

It's one way to do it if you really don't want to learn

any patterns. Robert's method is an example of a very general approach to solving, and in fact it can probably solve pretty much everything if taken to the extremes. Many of the same concepts most of us here use can be found in TDP as well, with just different names and notations. For example, his "anti-track" is basically a replacement for an AIC. Similarly his "conjugated tracks" is similar to what we call Krakens. One major philosophical difference is that his approach automatically accepts branching nets (which we try to avoid until really needed) and contradictions (which we really try to avoid). Both of them make solving easier and faster, but the question is: are they elegant and do they make it more fun? Another downside is that such approaches are really difficult to notate in an understandable way.

The biggest selling point of TDP is simplicity, although it's not reflected in the über-complicated documentation (I've given feedback on that, and Robert has listened). However, not everyone is interested in such extreme simplicity because it takes away a lot of the fun of learning and solving with more interesting techniques. For someone like me there's no point in switching to TDP because I'd consider it downgrading. On the other hand, it could be very helpful for someone who doesn't yet know any advanced techniques. On my part I can also freely admit that I've learned some new tricks and perspectives from Robert, so I'm glad he joined the forum and introduced his approach.

I really hope I'm giving a fair assessment of TDP. Even though it's not for me, it might be a perfect fit for you or someone else. I like Robert and I have no reason to badmouth his technique. I think variety is good, and TDP is a welcome addition to the zoo of techniques to choose from.

--

Edit. Added a link to a set logic intro.