The New Sudoku Players' Forum

[SpAce]

http://forum.enjoysudoku.com/als-chains-a-tutorial-asi-3-t6443-30.html rcc predates hodoku and was used extensively on this forum, albeit a very overtly worded acronym.

Thanks for that link. I don't know who initiated that RCC fiasco, or how extensively it was used elsewhere, but if you read that whole thread you see that it was only used by ronk there (and by aran in his first response to ronk, after which he switched to RC and then to RCD).

So, you see three different acronyms in that thread (ordered by frequency and the number of users): RCD, RC, and (as a distant third) RCC -- all meaning the same thing. The one used most frequently and by the most participants is RCD -- which is exactly what I just suggested (without knowing it had ever been used for this purpose). One of its users was Allan Barker, who we all know is a genius. That's a pretty strong precedent, I think.

There probably was a discussion dropping the extra "c" at some point as it could lead to ambiguity which you have brought up.

Well, I hope so. There were smarter people than me in those discussions, so I'm sure someone else must have seen the problem just as clearly. In fact, I'm kind of curious how RCC could have become popular in the first place, and why RCD didn't win the day. It should have been a no-brainer given those options.

I can and am willing to edit my post to remove the extra "C" if you would prefer and shorten it to restricted common.

Actually, based on your link, I might suggest using RCD because it makes the most sense and it has a precedent. It's the least ambiguous of all. If it's just RC, then someone can still read it as "Restricted Candidate". (But, I'm perfectly fine with RC as well.)

In fact, I'm now speculating (without any evidence) that RC was possibly chosen as a poor compromise, being acceptable to both RCD and RCC users. That would be an example of the logical fallacy argumentum ad temperantiam because only one of the options was good in the first place (and thus the middle ground is non-optimal). Nevertheless, even RC is way better than RCC which makes absolutely no sense, not the least because it's an oxymoron: a candidate (normal definition) can't be both restricted (i.e. usable in a weak link) and common (implying shared in an overlapping cell) between two ALSs.

PS. I've never paid attention to this problem before because I've never thought in terms of "restricted commons". To me they're just weak links (or cover sets).
--

Added.

As candidates represents the potential quantifiers for a space used by sudoku technique these are:
digits/numbers in the case of the Almost Naked set
Cells in the case of the Almost Hidden set.
So, yes it makes sense to a degree.

I understand what you mean, and you're right, but it requires a much more generic concept of "candidate" than how it's normally used in the rc-space. Thus confusion is inevitable if its definition is suddenly widened to mean any possibility without specifically defining what possibilities are meant. If none is specified, this should be the default: Sudopedia definition.

Thus a normal candidate is a possible digit in a specific cell, not a "possible digit in an ALS". If the latter is meant, it should be specified. In other words, I guess the most accurate (and least practical) term would be something like: "restricted common digit candidate". Since that digit isn't locked in either ALS, it is indeed a digit candidate that both share. Yet, that would be a poor defense for RCC -- with that point of view it should have been RCDC (or RC/DC ).

[Wepwawet]

Have just got round to reading the latter posts and I fully understand the scenarios in this thread. I now must read the thread that the HoDoKu website refers to

ALS Chain
ALS Chains are a series of ALS connected by RCCs. The first and the last ALS must contain a common digit, that digit is eliminated from all cells that see all instances of the digit in both ends of the ALS Chain. Some restrictions are put on the RCCs: No two adjacent RCCs may be the same. In fact when building ALS Chains which contain doubly linked ALS, choosing the correct RCCs is a bit more complicated than that. A discussion of all possibilities with doubly linked ALS is beyond the scope of that guide, see Restricted Common Adjacency Rules in the Player's Forum.

Now a question, well,what do you expect? Are there any examples (if they exist) of there being 3 RCD's in chained ALS's?

I have now got to get my head around Eureka notation in complex scenarios (more research). Though, I have used regular chaining; AIC (type 1 and 2) with/without Nice Loops, to solve puzzles for quite a time now, but only visually using bold and pallid colours to indicate strong and weak links, I had never bothered with the notation side of things until recently, and SpAce has advised me to adopt Eureka, so I will endeavour to do that.

[SpAce]

Hi Wepwawet,

Now a question, well,what do you expect? Are there any examples (if they exist) of there being 3 RCD's in chained ALS's?

It depends on what exactly you mean by that. If your chain has four connected ALSs then there are obviously three RCDs (one between each ALS). I guess that's not what you meant, though.

If you meant three RCDs between just two ALSs, it's not possible because one of them would be left with too few digits to fill the cells. So, two is the maximum and that makes it a loop (doubly-linked ALS-XZ) giving possibly lots of extra eliminations because all the bystander digits (i.e. the ones not used for linking) get locked either way.

So, to have more RCDs between just two linked elements, you need AA*LS patterns that have more than one extra digit. For example:

Code: Select all

.--------------------------.---------------.---------.
|  .        .       .      | .   .       . | .  .  . |
| a123     a123'8  a123    | .  -123     . | .  .  . |
|  .        .       .      | .   .       . | .  .  . |
:--------------------------+---------------+---------:
|  .        .       .      | .  c123     . | .  .  . |
| b79'456  b8'456  b79'456 | .  c456'123 . | .  .  . |
| b79      b8'79    .      | .  c123     . | .  .  . |
:--------------------------+---------------+---------:
| .         .       .      | .   .       . | .  .  . |
| .         .       .      | .   .       . | .  .  . |
| .         .       .      | .   .       . | .  .  . |
'--------------------------'---------------'---------'

ALS a: (1238)r2c123
ALS b: (456789)b4p45678
AAALS c: (123456)r456c5

RCDs: a-8-b, b-456-c

(123=8)r2c132 - (8=79'456)b4p45678 - (4|5|6=123)r456c5 => -123 r2c5

That pattern has three RCDs between ALS b and AAALS c. Stuff like that is relatively advanced, though.

I had never bothered with the notation side of things until recently, and SpAce has advised me to adopt Eureka, so I will endeavour to do that.

Excellent! We're happy to help with that too. A good place for examples is the forum Puzzles section as almost everyone describes their solutions with Eureka (with minor variations in style).

PS. About that thread you mentioned...

A discussion of all possibilities with doubly linked ALS is beyond the scope of that guide, see Restricted Common Adjacency Rules in the Player's Forum.

It's interesting that everyone, including hobiwan, use either RCD or RC at the beginning of that thread. Then, all of a sudden they start using RCC. It happens right here for no apparent reason.

[StrmCkr]

http://forum.enjoysudoku.com/post20956.html?hilit=restricted%20common%20candidate#p20956
RCC goes back pretty far into 2006

not a clue why:
RCC, RC,RCD was used interchangeable for so long even then the three exists.

this post is interesting as it also leads up to the last question asked for help on:

Now a question, well,what do you expect? Are there any examples (if they exist) of there being 3 RCD's in chained ALS's?

http://forum.enjoysudoku.com/almost-locked-rules-for-now-t2510.html

yes
als N cells with (n+1) digits attached to another als of N cells with (n+1) digits
may have at most 2 RC {ie the +1 cells added together}

any more then that then the set will not have enough digits to solve and will result in a contradiction.

multiple sets together:
you have to consider each part of the chain as " pairs" because of the RC they share,

the start and the end may also loop together as a "Pair" this is the part that makes chaining difficult back tracking the eliminations:

for example:
an als-xy: has 3 different als parts. {a,b,c}
you may have up to
3 sets of double linked als-xz sub-parts ie { ab,bc,ca each with 2 RC}

as a group:
if they loop and all three chains are linked with different digits we can create the same effects as the double linked als-xz via 3 different RC digits when adding the RC's together.
{again its the +1 cells added together = 3}
meaning each part of the chain is a locked set individually same as the double linked als.

repeat for each new chain part added.

all you really have to remember once you get the basics building blocks i described earlier down is this:
the RC must be a different digit between each new link added.

now when we move into the next realm of complexity it gets even more daunting.

Almost^ Almost locked sets
N cells with N+M digits
{^ where almost is repeated M times}

at max we can have 1 cell with 9 digits
these types of als needs M different RC's to accomplish anything

basically
1 als with 8 attachments to its self. then the group as a whole may eliminate peers cells for a digit that common to all the als's {must be in all of them}

in reverse view they are known as { reverse as it find a group of N als's with +1 then adds it to an als that has freedom of N)
C.o.a.L.s
http://forum.enjoysudoku.com/combined-overlapping-almost-locked-sets-rule-coals-t4863.html?hilit=coals

i don't even want to talk about chaining these with other types as that's just going to be a headache - it is possible.

[Wepwawet]

Thanks guys, for the main, I will be sticking to regular ALS. My main area of interest (at this moment in time) is the implementation of complexes/objects/sets etc as intermediate nodes to further concatenate an AIC (irrespective of whether or not there are eliminations of candidates) though of course, any propagation or elimination rules need to be understood.

In due course I will be posting further threads on similar themes, if I can not find the relevant info elsewhere, one that springs to mind is one that SpAce mentioned,regarding the strength of links

In an AHS (almost hidden subset) it's the other way around

[SpAce]

Thanks guys, for the main, I will be sticking to regular ALS.

Good idea. Once you really understand those, it's easy to add more complexity such as overlapping ALS, AHS, AA*LS, and other almost-patterns.

My main area of interest (at this moment in time) is the implementation of complexes/objects/sets etc as intermediate nodes to further concatenate an AIC (irrespective of whether or not there are eliminations of candidates) though of course, any propagation or elimination rules need to be understood.

The same rules apply to any almost-patterns. In an ALS you have an extra digit that prevents it from being a naked subset, but you have a strong link between those two so you can build chains from each, and if both chains agree on something that must be true. All other almost-patterns have a similar strong link you can exploit: either the pattern is true (with its eliminations or weak links) or its "spoiler" or "obstacle" is true with the same on its side. The pattern can be anything, such as as fish or a wing or even a generic AIC (or even much more complex objects). The same logic works anyhow and they can all be embedded in chains.

You can find lots of examples of those in the Puzzles section. For example, my today's solution uses an almost-S-Wing. If you don't know what an S-Wing is you can just view it as an almost-AIC (because it's written as such within the [bracketed chain fragment]). Similarly, Cenoman's solution yesterday is an almost-Skyscraper, and my second solution there displays a couple more examples as well.

In due course I will be posting further threads on similar themes, if I can not find the relevant info elsewhere, one that springs to mind is one that SpAce mentioned,regarding the strength of links

In an AHS (almost hidden subset) it's the other way around

Let's take a quick example of an AHS, because what I said earlier wasn't entirely accurate. Let's assume that your row 1 looks like this (only relevant bits shown):

Code: Select all

| 12+  12+  /  |  /  2+  /  |  /  /  /  |

It depicts that the first two cells have 12 and some extra digits as candidates, and there are no more 1s and 2s in that row except 2r1c5. Without that spoiler 2r1c5 you'd have a hidden pair (12) in r1c12 and you could eliminate all other candidates from there (as well as 2s from box1/r23). Thus you have an almost-hidden-pair: (12)r1c12 = (2)r1c5. It could be used in a chain like this (presuming there's a candidate 3 in r1c1 that has a strong link in its column):

... = (2)r5c5 - (2)r1c5 = (21-3)r1c21 = (3)r8c1 - ...

Strictly speaking, what I said about the links being the other way around is not exactly true. The full AHS (colored) actually includes the strong link, like any other almost-pattern. So, from that point of view its internal link is still strong and external links are weak. What I meant earlier was that usually at least one of its weak links is internal to the locked cells and the strong link is always external to them, like above, which is clearly the opposite of ANS. It was poorly worded.

[StrmCkr]

In an AHS (almost hidden subset)

http://forum.enjoysudoku.com/post34826.html#p34826
is a interesting beast the ahs is compromised of N Digits in N+1 cells

that means that the following is an ahs

Code: Select all

| / 1 / | / / / | / 1 / |

1 digit in 2 cells
or

Code: Select all

| 1* 1 1 | / / / | / 1 / |

1 digit in 4 cells { n digits in N+m } almost^ almost hidden als
{* as one can be missing}
or

Code: Select all

| 1* 1 1 | / / / | 1* 1 1 |

1 digit in 6 cells { n digits in N+m } almost^ almost hidden als
{ * as both or one could be missing}

adding more then * missing cells and it becomes the previous case.

these three are the building blocks as strong/grouped strong links for chains

it should be noted that adding extra digits {increasing N size, turns them to a group of digits thus weakly linked to themselves hence the weak set}

aic chains use both Naked sets and their interactions of hidden set as building blocks. {in essence cell sharing for digits}

similar to how
ahs xzwould function
{hint its identical to als-xz but RC = cells, and the eliminations are also cells. }

since aics can use both als/ahs set types they bridge the gap to where these techniques as individuals fall off.

[SpAce]

ahs xzwould function

Regarding your question at the end of that thread, I have no idea how to turn it into AHS-XZ (or if something like that really even exists in a pure form), but here's my funny translation into hidden sets anyhow:

Code: Select all

.----------------------------.-------------------------.-------------------.
|  124579   *1579-2  *1579-4 | 2468    246789   24689  | 45679   3    5679 |
|  6        *279     *479    | 5      *234-79  *234-9  | 1       8    79   |
|  4579      8        3      | 46      1        469    | 45679   2    5679 |
:----------------------------+-------------------------+-------------------:
| *248-1    *12      *14     | 9       5        7      | 3      *46  *68-1 |
|  134578    6       *157-4  | 148     348      1348   | 578     9    2    |
|  1345789  *13579   *1579-4 | 12468   23468    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 |
'----------------------------'-------------------------'-------------------'

MSHS: {234R2 2468R4 13579C2 1579C3 \ 2n2356 4n12389 1679n2 156n3} => -1 r4c19, -2 r1c2, -4 r156c3, -79 r2c5, -9 r2c6

As a purely hidden loop:

(2)r2c2 = (23-4)r2c56 = (4-7|9)r2c3 = (795-1)r156c3 = (1-4)r4c3 = (468-2)r4c189 = (2-1)r4c2 = (13579)r12679c2 - loop => -79 r2c56, -4 r156c3, -1 r4c19, -2 r1c2

Doing it like that doesn't make any sense of course, because the corresponding doubly-linked ALS-XZ (or MSNS/DDS) is waaayyy simpler in this case (5 cells vs 16). Yet both should produce the same eliminations (the missing 1s in box4 get eliminated due to claiming right after).

Lesson learned: AHS works best if the corresponding ANSs have lots of cells and digits because then the AHS is simpler. Here it's the other way around.

[StrmCkr]

Lesson learned: AHS works best if the corresponding ANSs have lots of cells and digits because then the AHS is simpler. Here it's the other way around.

yup, learned a lot attempting to get ahs-xz to work.... i should update that programing thread simply couldn't tiddle the data set in my language set-wise setup.
compared to others and directly use the same data sets. for "off" values.

the lessons learned:
a size 4 set has a size 5 in the opposite

meaning that searching for als/ahs xz size 4 has less cycles then searching for size 1-9 in als or ahs.

[StrmCkr]

once you have digested all the stuff me and space posted:

the next things to grasp are the RCC rules for chain building:
For programing exclusively, as machinencode cant disginguies stored rc senarios (edit added) .

http://forum.enjoysudoku.com/restricted-common-adjacency-rules-t6642.html
the basic principle is that they cannot repeat between each ALS

however it must be accounted that there can be two different digits at each link stage

generating 4 scenarios to account for when chain building :

Current - previous <> empty { new set has a unique number not previously used}
[3] - [1,2] <> []

current * previous = current & previous { digit count = 2 each} {and they use the same RC}
[1,2] * [1,2] = [1,2]

Current < previous & previous previous <> Current {current step has less digits then the previous however, its digit wasn't used by the previous previous step}
[1] - [12] & [2] <> [1]
Current < previous & previous previous = previous where { previous * previous previous = previous & previous previous } {digit counts of previous and previous previous = 2} {back to back identical numbers for the RC in pairs}
[1] - [12] & [12] = [12]

if this is confusing...... see hobiwans and pauls explanation in the linked document.

[SpAce]

once you have digested all the stuff me and space posted...

...you're done

the next things to grasp are the RCC rules for chain building

I think we pretty much covered everything, and better than what those old discussions and rule lists would ever do. They're interesting history lessons and foundations to what we know now, but a lot of the information is obsolete and just plain confusing. Unlike what they (and you) would suggest, there are no rules that need to be memorized. A*LS things are very easy to grasp if one understands chaining fundamentals. Like I said, I've never thought in terms of RCDs at all, because it's not necessary. Chaining is a fundamental skill, RCD rules are not (because they're self-explanatory if you know how chaining works).

if this is confusing......

It isn't unless made so. I don't think it's especially helpful to bring up those old discussions because it's obvious that many of the participants (including hobiwan) didn't yet truly understand the issues. That's why they make everything look much more complicated than it is. Let's keep things simple -- because they are.

[StrmCkr]

.you're done

Probably, lol

The stuff in the last post is applicable for machine code when building an als chain egine.

Probably should have said that first.

Sure people can see how they work and keep track easy enough so it appears obsolete and unnessesary
Machine code dosen't have that insight it cant tell me why something dosent work without senario coverage Rules

Like this : the first link is 1 and the second used [1or2] and the third [2] = not valid
Machine code cant tell me the middle link actually used 2. (when it saves the rcs between nodes)

Found out the senarios are important when i programed my own als chain engine over the last few days offically working bug free this morning: (hence my post)

First rule especially as it stopped repeating digits, (most important )
2,3,4 rule are for 2rc between links which the first rule skips ( sorted out why stuff was missed) .

[SpAce]

The stuff in the last post is applicable for machine code when building an als chain egine.

That's what I thought you meant, and I have no comment about it because I haven't coded any sudoku engine (besides basics, years ago). I only see things from the human solving point of view, at least for now.

Probably should have said that first.

Well, obviously the same logic works for both machines and humans, but some details are more relevant in one or the other context. So yeah, it's probably a good idea to mention if something is mainly applicable in the machine context.

[SpAce]

Hi StrmCkr,

In yesterday's puzzle eleven used a neat AALS move. Now I'm wondering how to classify it. It's almost like an AALS-XZ (if there's such a thing) but not quite because all RCD instances don't see each other. It works anyhow because the digits can only be arranged one way in the ALS cells when the Z candidate is removed, and then the active RCD candidates end up seeing each other:

Code: Select all

.-----------------------.----------------------.----------------------------.
| 35789   1      356789 |   2359   789   4     | 23689   b8'39      b2'369  |
| 2       3478   3789   |   39-1   6     379   | 5       b8'349(1)  b349    |
| 34589   34568  35689  |   12359  189   2359  | 123689   7         b2'3469 |
:-----------------------+----------------------+----------------------------:
| 34578   34578  3578   |   3469   2     369   | 3789     3589       1      |
| 1345    9      1235   |   7      14    8     | 23       6          235    |
| 6      a38'7   12378  | a[1]39   5    a39    | 4       a39'8      a379'2  |
:-----------------------+----------------------+----------------------------:
| 35789   2      356789 |   4569   479   1     | 3679     3459       345679 |
| 1579    567    4      |   2569   3     25679 | 1679     159        8      |
| 13579   3567   135679 |   8      479   5679  | 13679    2          345679 |
'-----------------------'----------------------'----------------------------'

(1=739,82)r6c24689 - (8|2=3469'1)b3p23695 => -1 r2c4

Thus we have almost something like this:

AALS-XZ: ALS a (123789)r6c24689, AALS b (1234689)b3p23569, X={2,8} Z=1

Problem is, all instances of the RCD (8) don't see each other. Specifically 'ALS a' in row 6 has a candidate 8 in r6c2 which has no line of sight to the 8s of 'AALS b' in box 3. Yet it works because if 1r6c4 is not true then 8r6c8 gets locked and 8r6c2 is irrelevant. That's why I added the comma to the node (739,82)r6c24689 to indicate how the digits get fixed in the cells (otherwise the AIC link doesn't work properly either). That, however, is not part of basic A*ALS logic. I guess one way to do it would be to use two separate ALSs with just one RCD each, (1'39'8)r6c468 and (1'7398'2)r6c24689, but that's pretty redundant.

So, what would you call a situation like that? I don't think it can happen with basic ALSs that are linked with just one RCD, but it seems that with larger AA*LSs we can have these kinds of scenarios where the rule "all RCD instances must see each other" doesn't quite hold.

[StrmCkr]

Code: Select all

+----------------------+-------------------+--------------------------+
| 35789  1      356789 | 2359   789  4     | 23689   (389)    (2369)  |
| 2      3478   3789   | 39(1)  6    379   | 5       3489(1)  (349)   |
| 34589  34568  35689  | 12359  189  2359  | 123689  7        (23469) |
+----------------------+-------------------+--------------------------+
| 34578  34578  3578   | 3469   2    369   | 3789    3589     1       |
| 1345   9      1235   | 7      14   8     | 23      6        235     |
| 6      (378)  12378  | (139)  5    (39)  | 4       (389)    (2379)  |
+----------------------+-------------------+--------------------------+
| 35789  2      356789 | 4569   479  1     | 3679    3459     345679  |
| 1579   567    4      | 2569   3    25679 | 1679    159      8       |
| 13579  3567   135679 | 8      479  5679  | 13679   2        345679  |
+----------------------+-------------------+--------------------------+

id chalk that one up to a chain technique. {for now}

for me i see:
AAls a) 234689 @ R1C89,R23C9 ( 6 digits in 4 cells)
ALS B) 23789 @ R6C24689
Transport Digit 1 @ R2C47

R2C7 = 1 or <> 4389 from the aals being reduced to a locked set when ALs is reduced by 1 digit from placement of 1 @ R2C4

yes i know i missed adding cell R2C8
- was trying to figure out why xsudoku kept putting links to the bi-local digit 1