The New Sudoku Players' Forum

[SteveG48]

...Should the 4 in the third term be on the other side of the = sign?

As I understand it, the digit placement is correct as shown. The CoALS rule says there is a strong link between the AND'd digits in the overlap cell(s) and the AND'd digits in the non-overlap cells.

I like how it works, but if the parallel move doesn't qualify as a proper AIC, I don't see why the CoALS rule would. The third term involves ALSs in two different houses, which isn't normally allowed.

In the above link Myth carefully defines his CoALS structure as the logical union of two regular ALS to form a Combined ALS. He then proves his rule and provides some good examples of how it can be used in a regular AIC. I think Myth was pretty careful in most everything he did. Plus, I know there's a long history of topics dealing with other aspects of overlapping ALS. Most of that, unfortunately, is pretty much over my head. IOW, even though I've learned a lot in this thread, I'll have to defer to the experts to help out with the hard questions.

SteveC

I don't doubt for a moment that the logic is impeccable. In fact it's quite clear. I guess the question is whether we should call it an AIC or a network solution presented as an AIC.

[David P Bird]

(6=94)b7p67 - (4=91)r5c19 – (14=69)r45c5,r5c1 – (6|9=5)r4c2 - (5=86)r7c27 => -6 r7c1

When AICs get complicated I find it can be quite useful to look at how they could be wrtiten backwards. Here's your chain in reverse and simplified so the reader doesn't have to perform any more mental contortions than necessary.

Code: Select all

 *--------------------*--------------------*--------------------*
 | 35    2589  12589  | 7     39    128    | 4689  489   689    |
 | 36    689   1689   | <4>   39    18     | 7     <5>   <2>    |
 | <7>   <4>   289    | <6>   <5>   28     | <1>   3     89     |
 *--------------------*--------------------*--------------------*
 | <1>   569 b 4569   | 2     46 c  <3>    | 4589  489   <7>    |
 | 49 cf <3>   7      | <8>   14 d  <5>    | 2     <6>   19 e   |
 | <8>   256   2456   | <9>   146   7      | 45    14    <3>    |
 *--------------------*--------------------*--------------------*
 | 56    568 a <3>    | 1     <7>   <9>    | 68 a  <2>   <4>    |
 | <2>   <1>   69 h   | 35    8     <4>    | 369   7     569    |
 | 49 g  7     489    | 35    2     6      | 389   189   1589   |
 *--------------------*--------------------*--------------------*

(86=5)r7c27 - (5=69#1)r4c2 - (69=4)r4c5,r5c1 - (4=1)r5c5 - (1=9)r5c9 - (9)r5c1 = (9)r9c1 - (9=6)r8c3 => r7c1 <> 6

The (69=4)r4c5,r5c1 strong link considers both (6) & (9) to be true in the cells as one argument and (4) true in either or both of them as the other and this just gets lost in the mud when, for the sake of brevity, successive terms are condensed into one.

I call nodes where the cells aren't peers in the same house 'split nodes' and am quite happy to accept them in AICs.

David

[sultan vinegar]

Nifty. Do we need (69#1=4)r4c5,r5c1 though?

I.e. (5=x)r4c2 - (x=4)r4c5,r5c1 where x is 'super-candidate' 69.

Or even better consider the AMSLS for candidates (5,6,9,4,1) in 4n25,5n59:

(6=5)ALS12n1 - (5)r7c1 = (5)r7c2 - (5=9)AMSLS4n25,5n59 - (9)r5c1 = (9)r9c1 - (9=6)r8c3 => r7c1 <> 6.

[JC Van Hay]

And what about ...

Code: Select all

+--------------------+---------------+-----------------+
| 35    2589   12589 | 7   39    128 | 4689  489  689  |
| 36    689    1689  | 4   39    18  | 7     5    2    |
| 7     4      28(9) | 6   5     28  | 1     3    8(9) |
+--------------------+---------------+-----------------+
| 1     (569)  45-69 | 2   (46)  3   | 4589  489  7    |
| (49)  3      7     | 8   (14)  5   | 2     6    (19) |
| 8     256    2456  | 9   146   7   | 45    14   3    |
+--------------------+---------------+-----------------+
| 5-6   (568)  3     | 1   7     9   | (68)  2    4    |
| 2     1      (69)  | 35  8     4   | 369   7    569  |
| 49    7      489   | 35  2     6   | 389   189  1589 |
+--------------------+---------------+-----------------+


(68=5)r7c2 - 5r4c2=XYWing(469)r5c1,r4c25 - (4=19)r5c59 - 9r3c9=NP(96)r38c3 :=> - 6r7c1, -(69)r4c3 ?

[David P Bird]

Nifty. Do we need (69#1=4)r4c5,r5c1 though?

I.e. (5=x)r4c2 - (x=4)r4c5,r5c1 where x is 'super-candidate' 69.

There's a subtle difference in the logic between the two notations. Using 'x' to be either (6) or (9) the path will be different depending on which one it is - also known as branching. I consider that using the number of truths the (69) combination represents avoids that and will apply to a wider range of case scenarios.

It's a moot point which one is easier to digest and will perhaps depend on who we're writing for. (I always have the newbie lurker in mind when I write here.)

Finally let me add, the space you save by using 'x' you lose when you define what 'x' is.

David

[sultan vinegar]

JC, your AXYwing is simpler than my AMSLS but I think you need a separate chain for each of your two eliminations as you "get the second one on the way to the first one".

DPB, what I was saying came out all wrong! All I wanted was:

(86=5)r7c27 - (5=69#1)r4c2 - (69#1=4)r4c5,r5c1 - (4=1)r5c5 - (1=9)r5c9 - (9)r5c1 = (9)r9c1 - (9=6)r8c3 => r7c1 <> 6.

I prefer the AMSLS or JCs AXYwing as there is a slight asymmetry with the #1 notation when read from right to left compared with left to right. Speaking of the # notation, does anyone know where Myth Jellies is these days?

[David P Bird]

DPB, what I was saying came out all wrong! All I wanted was:

(86=5)r7c27 - (5=69#1)r4c2 - (69#1=4)r4c5,r5c1 - (4=1)r5c5 - (1=9)r5c9 - (9)r5c1 = (9)r9c1 - (9=6)r8c3 => r7c1 <> 6.

SV you're trying to redefine the meaning of (69#1) from indicating the pair holds one truth to your super-candidate to indicate 'one from this pair' which isn't on!

Running with your idea but using (69%1) instead, your third node is (69%1=4)r4c5,r5c1 which isn't a strong link. The chosen candidate can be true in one cell and the unchosen one can be true in the other so (4) needn't be true in either. To support the strong link the node must be confined to one cell and which one that will be will depend on the choice – ie branching.

Alternatively using truth counts (69#1)r4c2 – (69#1)r4c5,r5c1 now fails to be weak as the two nodes can hold different digits from the pair.
But as I had it (69#1)r4c2 – (69)r4c5,r5c1 works because these terms can't both be true.

For AICs to be unarguably bi-directional each link must be stand alone and independent of the truth state of any candidate elsewhere in the chain, and this is what I work to. (I don't want to re-open any debate on memory chains.)

Regarding Myth Jellies, he dropped out of sight in 2009. Actually the #n notation was his suggestion on another forum.

David

[sultan vinegar]

SV you're trying to redefine the meaning of (69#1) from indicating the pair holds one truth to your super-candidate to indicate 'one from this pair' which isn't on!

, all makes sense now in both directions with the correct definition!

[SteveG48]

Regarding Myth Jellies, he dropped out of sight in 2009. Actually the #n notation was his suggestion on another forum.

David

David, do you have a link to this or to another explanation of the #n (and %n) notation? I believe I'm getting the gist of this, but I don't want to miss the details.

[David P Bird]

Steve,
The other forum Myth contributed to, and where the Eureka notation developed crashed and the discussions lost I'm afraid although some personal copies of individual topics exist.

On this forum a different 'Nice Loop' notation was being used. When the membership of the two forums merged there were therefore two notation systems being used both of which handled basic chains well but the Eureka one has proved more adaptable when it comes to incorporating pattern nodes into AICs.

However in recent times contributors have bucked against using a standard notation and have preferred to use their own dialects. How easy it is for a reader to understand a dialect will depend on how much common ground it has with his own, and over time doubtless a new consensus will emerge.

Nevertheless for an alternating inference chain to be bi-directional the same basic rules must always be followed.
1) Each term in the chain must be a Boolean which will be interpreted as either being true or false
2) The link types must alternate between weak and strong
3) Each link must be stand-alone and independent of the truth states of candidates elsewhere in the chain.

Therefore in choosing the notation for a pattern term it must be clear when it will be considered true or false.
In the Eureka notation by default (ab)r1c12 is considered true when the two digits occupy these cells and (a)r12 is considered true when (a) occupies either of them, and in combination these handle almost locked set nodes such as (ab=c)r1c12.

However this makes it impossible to interpret two digits in one cell such as (ab)r1c1 as a Boolean.
For the term to be true when either digit occupies the cell we can use either (ab#1)r1c1 or (a|b)r1c1 where the "|" symbol signifies 'or'.
My personal choice is #n because in more complex situations I can use (abc#2)r1c12 but many contributors consider the # symbol rather ugly.
(I fabricated (69%1) for the purposes of that response to Sultan Vinegar and is not part of any notation dialect.)

Many of the solutions in this puzzles section aren't pure AICs because they break requirement 3 above and/or involve branching. This doesn't make them wrong but they require more effort to validate and are commonly considered as less elegant.

It's been quicker for me to write this than to conduct a search for a suitable source, but if I fall on one I'll message you.

David

TAGdpbEurekaNotation

[sultan vinegar]

DPB, can I get a quick clarification?

For the term to be true when either digit occupies the cell we can use either (ab#1)r1c1 or (a|b)r1c1 where the "|" symbol signifies 'or'.

Not that it matters for the example chain a few posts above, but in general does the (ab#1) notation require:

For the term to be true when exactly one digit occupies the cell we can use either (ab#1)r1c1 or (a|b)r1c1 where the "|" symbol signifies 'xor'?

Or is at least one sufficient, analogous to a conventional strong link a=b?

[SteveG48]

Thanks, David.

SV, my interpretation of what David has said is that the "or" interpretation is correct, not the "xor". David, is that right?

[David P Bird]

For the term to be true when exactly one digit occupies the cell we can use either (ab#1)r1c1 or (a|b)r1c1 where the "|" symbol signifies 'xor'?

Or is at least one sufficient, analogous to a conventional strong link a=b?

SteveG48 is right.

The "|" symbol is taken to be a simple OR operator so theoretically the term would be true when both digits were true if circumstances permit.
In the same way (ab#1) translates to being true when at least one of the digits is true.

As an artificial example, for a pair of cells with the combined candidates (abcd) this link is possible (ab#1 = cd#1)r1c12

David

[SteveG48]

One more if you don't mind, David.

We frequently use constructs like (12)r1c12 - (12=34)r1c89. Would it be more technically correct to write (1&2)r1c12 - (1|2=3&4)r1c89 ?

[DonM]

One more if you don't mind, David.

We frequently use constructs like (12)r1c12 - (12=34)r1c89. Would it be more technically correct to write (1&2)r1c12 - (1|2=3&4)r1c89 ?

This discussion inspired me to go back to my AIC archives, most of which came from the UK Eureka forum. Myth Jellies introduced the concept of AIC notation in early 2006 and it resulted in many discussions ('chaired' by RUUD) -particularly in the summer of 2006- as to what the best notation was, including the use of operators such as AND and OR. All of this resulted in what came to be the AIC Eureka notation which, incidently, was somewhat different from the first AIC notation Myth Jellies used.

The use of '&' for AND was pretty much accepted right away and, in fact, Myth Jellies used it almost all the time while almost everyone else decided that AND situations were pretty much self-explanatory. So Myth might have notated an ALS as:
(1)r8c3 - als(1=3&7&8)r8c789 instead of just (1)r8c3 - als(1=378)r8c789. (Full disclosure: Myth wouldn't have used the 'als' descriptor- he made a point of saying it was redundant if you were using (1=3&7&8). I just left it in here for clarity since I'm only showing a snippet of a chain. Actually, I still use and support the use of 'als' ).

FWIW: An individual named 'Carcul' (a name probably not known by several on this forum) was IMO the first of the truly ahead-of-his-time gifted manual solvers. He was coming out with solutions that used constructs that were not truly understood and used at the time. In any event, he was probably among the first, if not the first, to use 'I' to designate OR in chains in the first half of 2006. An individual, who will remain nameless, insisted on using 'v' for OR, but his 'OR Chains' notation never was picked up by....anyone.