StrmCkr wrote:The sue de coq has 4 restricted commons 1256 which leaves the overlaping r4c23 cells as not able to contain digit 9 which locks it to 2 sectors. Sue de coqs technically are also aals rules see ronks comments in previous provayed links 2sectordds and als. Thread)

If you refer to someone's specific comments you could simply link to them directly. Vague references are really annoying. In any case, I guess you meant ronk's examples here:

ronk wrote:Here are three examples where both sets B (CB) and C (CR) contain the same digit.

...and hobiwan's attempt at an extended definition allowing such cases here:

hobiwan wrote:Crucially, no candidate from V is allowed to appear in VB and VR.

Do you see how hobiwan's extension and ronk's examples are different from yours? The answer: the 9s in your example are part of V, i.e. digits in the intersection. That's not what ronk or hobiwan had in mind, at least in those posts. The intersection digits can't exist in multiple sectors even with the extended rule which allows other digits to be repeated (which by the way is implemented in Hodoku). Personally I don't really like even that lesser extension because it breaks the purity of a "disjoint subset" which should have exactly N digits in N cells. Any duplication of digits results in fewer digits than cells in the solution, which is not my idea of a disjoint subset (distributed or not). It's just a generic locked set, i.e. MSLS.

In any case, your further extension is a clear violation of even the extended rule, and it completely destroys the distinction between DDS and MSLS. Such distinctions should be preserved because they allow more exact names and hierarchies for patterns and thus more accurate communication. Every DDS is an MSLS, but not every MSLS is a DDS. Whenever you muddy those boundaries you're increasing local entropy, which is never a good thing. For some reason you have a habit of doing exactly that, which makes unambiguous communication harder and harder because every term can mean just about anything. I'd rather sharpen those boundaries to decrease local entropy.

It's a very good idea to generalize concepts, but it's not a good idea to refer to those generalizations with names that should be reserved for specific subtypes of them. If you do that, there's no longer any way to point to those specific patterns without ambiguity. It's the Turbot Fish problem all over again. If you want to use a single name for all of these types of patterns regardless of their exact subtypes, use MSLS. It's higher up in the hierarchy so it covers Sue de Coqs and other DDS too. You're doing it wrong if you're instead calling generic MSLS patterns Sue de Coqs.

I think your extension is probably what Obi-Wahn called multiplicities:

Obi-Wahn wrote:I have added Multiplicities now to DDS, but it's very slow for puzzles with many empty cells. One thing is that the calculation of multiplicities isn't trivial.

The question is, how many times can the same digit be placed within a given set of cells without violating the Sudoku rules. Or in other terms, what is the least number of sectors that is needed to cover all cells of the set. And this is equivalent to the Minimal Set Cover problem which is NP hard.

The other thing is, that I couldn't find a way for an early search termination. For DDS there can't be more than 9 cells within the set, because every digit is allowed only once. With multiplicities the number of cells is unlimited, so for an exhaustive search all available empty cells must be added. This leads to millions of nodes in the search tree for which multiplicities must be calculated.

It seems pretty clear to me that Obi-Wahn understood and wanted to maintain the distinction between basic DDS and patterns with multiplicities. I do too. In modern times, the proper name for the latter is MSLS.

Eliminations code removes the overlap cells from sets a and b so box 5 eliminations are justified

Exactly, but just like you wrote, it's two separate steps that must happen sequentially in a specific order. Thus they are not justified by the ALS-XZ directly. In other words, it's not a single move but two, and pretending something else is extremely confusing. With your ALSs, the bundled box 5 eliminations are a side-effect that can only happen after the 9s in r4c23 are eliminated. As a programmer you should know that side-effects are generally a bad idea, especially if they're totally unexpected like here. You should only list eliminations that can happen in parallel (in any order) and are directly justified by the logic of the presented move.

If your ALSs are (12569)r4c2346 and (169)r45c1, with candidates of 9 in every cell of the pattern, there's no way that the 9s can get locked in such a way that they could directly eliminate 9r6c46. It's simply impossible. If you instead use ALSs (12569)b4p2347 and (259)r4c46 the 9s get locked in r4c46 which can eliminate 9r6c46. Thus, even though the underlying pattern of cells and candidates is the same and can indeed justify the box 5 eliminations, the logic of your presented move can't. They're two distinct things.

Same thing happens in the als... But im not going to list nuances of solving code.

This has nothing to do with coding. The logic should be the same whether it's coded or done in the brain. To get the box 5 eliminations with those ALSs, your code must be doing sequential eliminations within the move, or otherwise there's something more seriously wrong with it. Either way, it shouldn't.

Following them blindly no, just using more thorough elimination code then hodoku.

Nothing wrong with that as long as the additional eliminations are justified by the presented move. An example of that would be the valid cannibal eliminations which your solver sees but Hodoku doesn't. That's good. However, the box 5 eliminations are not valid as presented, so you appear to be overdoing it. (As usual, I keep an open mind to the possibility that I'm just blind to something, but in that case you should show what it is.)

Canabolistic als moves probably not the correct thread mostly investigated by paul

http://forum.enjoysudoku.com/als-chains-with-overlap-cannibalism-t6580.html?hilit=Paul

Ok, thanks. I'll check it out at some point.