The New Sudoku Players' Forum

[denis_berthier]

A simple question that is nonsense! There are three candidates in r6c5 ...

OK. Read 3 candidates instead of 2 in my question. It doesn't change anything in the fact that they are mutually exclusive.

and we're talking about how to express two of them being false and forcing the third true. The expansion -( 5 OR 6 ) -> =3 works from l-to-r, but -( 5 XOR 6) -> =3 doesn't.

No, this is not was I was talking about.
What we have indeed in your example is a convergence point in a net: (NOT 5) AND (NOT 6) ==> 3. Your (logically equivalent) transcription as an OR is an artificial step. A better transcription should be XOR(5, 6, 3) AND (NOT 5) AND (NOT 6) ==> 3
Of course, OR(5, 6, 3) would work also, but this is not the point. The fact is, XOR is true in this case.

What I was talking about in a general way is what I wrote in my answer to Blue. All the OR you ever have to consider in a chain are XOR.

[daj95376]

[Withdrawn:]

_

[blue]

<snip>
An AIC alternates between strong and weak links.[...]Thus an AIC is an OR/NAND chain.
In practice, most strong links are also weak, and thus correspond to XOR. However this is not always true, and is not required for the logic of an AIC to work.

Until now, I haven't seen any convincing example.
If an OR link is not XOR, it means the two candidates it relates are related only by indirect OR. Which is very likely to mean that the pattern is not fully or not correctly defined.

The pattern based strong-only link I was trying to remember is between two possible disrupting candidates for a deadly pattern that would result in a contradiction (or – under my breath - two possible solutions).David

An example that doesn't involve contradicting a uniqueness assumption, is disruptors for "oddagon" patterns.
There you have that at least one of the disruptors must be true (in a solution) -- an OR relationship.
In the general case, two or more of them being true is not impossible ... making it an ordinary/non-exclusive OR relationship.

It turns out that oddagons were a poor example. If there are guardians in only two legs of the oddagon, then they end up being weakly linked by the legs of the oddagon anyway. In the "big picture" they actually do satisfy an XOR relationship.

Three guardians in 3 legs of an oddagon is a different story. All 3 can be true, or just one.
Since it's 3 candidates, though ... it doesn't have an obvious tie in with normal AICs.
With NRCZ-like "chains" though ? ... sure, why not ?

[denis_berthier]

Three guardians in 3 legs of an oddagon is a different story. All 3 can be true, or just one.
Since it's 3 candidates, though ... it doesn't have an obvious tie in with normal AICs.
With NRCZ-like "chains" though ? ... sure, why not ?

I don't know what an oddagon is, let alone what its legs are. Is it some kind of generalized leggy fish?
As far as I know, a guardian is a just z-candidate (i.e. linked to the target).

daj95376,
Another way of stating my general point is:
Any PRIMARY relation is either (binary) NAND or (multi-ary) XOR.
That's why any pattern can be described using only NAND and XOR.
I think my above rudimentary example: XOR(5, 6, 3) AND (NOT 5) AND (NOT 6) ==> 3 illustrates a general guiding principle for how patterns should be written (and BTW, it doesn't have anything to do with such or such notation).

Now, there may exist indirect OR but not XOR relations appearing in some exotic patterns. However, they can only be the result of indirect inferences and I haven't yet seen any example where this could be of any use (or couldn't be written otherwise, using only direct relations).

[sultan vinegar]

[lesson]
Anyone who uses XOR instead of OR obviously doesn't understand the connection between counting, truths, chains, fish and rank.

As JasonLion said, weak inferences are a NAND relationship; strong inferences are an OR relationship. If a strong inference happens to satisfy the XOR relationship then that's a nice side fact, but it doesn't make a lick of difference to the chain. To use XOR represents a lack of understanding between the left to right versus right to left reading of the chain and the concept of the contra-positive. This lack of understanding as to the bi-directional symmetry also exposes a weakness in the understanding of how and why we construct chains: they are useful to humans because you can start anywhere and expand in either direction, without needing any knowledge of where you came from. It is the bi-directionality that allows this.

To my knowledge, the only time XOR comes into play is in continuous nice loops; all strong inferences become weak and vice-versa. I'm happy to be corrected on that if someone comes up with a clever counter-example.

[/lesson]

In order to actually achieve something out of this discussion, perhaps all we need is a sticky topic at the head of this sub-forum containing the common notation, i.e. = is a strong inference and - is a weak inference, rc and bp notation and a link to MJs AIC tutorial. Then beginners can get up to speed quicker.

My view is that the variety in notation is actually a positive thing. We all speak the sudoku language but have our personal dialects. Handling AICs with native inferences seems to be done fairly consistently, the variety comes when trying to notate the various grouped inferences, be they grouped native, ALS, AUR, split node, fish, exocet or whatever else. A beginner should be able to learn the basic groupings (up to ALS and AUR) very quickly, and this would cover over 90% of the example solutions given in this sub-forum.

[David P Bird]

People have suggested some elements of a criteria for judging notation: easy to read, east to write, easy to learn, containing a logical proof of the step notated, brief, well documented, elegant, suitable for manual solvers, suitable for machine solvers, and so on. But we don't seem to agree on how to judge the individual elements, let alone prioritize them relative to each other and resolve their mutual contradictions.

This is a well thought out list and demonstrates that a single notation trying to satisfy all these conditions will be a compromise.

As there are generally about 10 readers for every solution posted, so 3 seconds saved per reader in digesting the notation is worth 30 seconds extra effort by the writer. The emphasis should therefore be biased towards the reader not so much on saving space/writing effort/a few minutes computer coding.

The two basic checks for a reader to make in validating a chain are a) do the link types alternate & b) do the digit and cell counts tally properly. I Therefore I consider that no inferred inferences should be allowed and that the full candidate lists should be given for nodes containing strong links. These redundancies help considerably in determining if a chain's logic is flawed or if it just contains a typo.

It has been noticeable that the advocates for change were remarkably silent over the first few days of this discussion, but now two Blue, and DAJ, are contributing. What I'd like to know from them (and the others) is do they accept that a compromise standard is sensible or do they want to proceed with one customised to their specific needs?

If we can establish that we will at least know how to continue the discussion.

DPB

[sultan vinegar]

I Therefore I consider that no inferred inferences should be allowed and that the full candidate lists should be given for nodes containing string links. These redundancies help considerably in determining if a chain's logic is flawed or if it just contains a typo.
DPB

As you know my preference is the opposite. Passenger digits disrupt me when trying to see how the chain flows from link to link. But given how you think then your preference does makes logical sense.

I don't find it hard when I see a derived strong inference across cells that share a house to think "that's probably an ALS". Provided all of the ALS cells are listed as a grouping then I don't need anyone to tell me all of the candidates in the ALS because I can look myself when verifying the inference.

If I see a derived strong inference across four cells in two rows, columns and boxes, then I think "that's probably an AUR". Provided all of the AUR cells are listed as a grouping then I don't need anyone to tell me all of the candidates in the AUR because I can look myself when verifying the inference.

[SteveG48]

... do the digit and cell counts tally properly. I Therefore I consider that no inferred inferences should be allowed and that the full candidate lists should be given for nodes containing strong links. These redundancies help considerably in determining if a chain's logic is flawed or if it just contains a typo.

It has been noticeable that the advocates for change were remarkably silent over the first few days of this discussion, but now two Blue, and DAJ, are contributing. What I'd like to know from them (and the others) is do they accept that a compromise standard is sensible or do they want to proceed with one customised to their specific needs?

If we can establish that we will at least know how to continue the discussion.

I was an early user of the "abbreviated" notation in which digit and cell counts did not tally. After an earlier discussion in which concern about this was expressed, I switched back. One habit I have developed, however, is to list the candidates most relevant to the solution last, so that the tally matches but the emphasis on the relevant candidate is still there. Perhaps that would be a reasonable compromise.

[eleven]

Eleven please see the last but one paragraph in my post < in my post of Aug 9th> giving you the link I mentioned.
There you will see that I was able to put each link into words (reading backwards, but that's not so important) over a section of the chain taking them in exactly the same order.
I would like to see how you do the same for your 'intuitive chain' as it would help me understand your conventions.

Code: Select all

    +-----------------+-----------------+-------------------+
    | 6   59    8     | 3      7      4 | 1      59     2   |
    | 4   179   179   | 2      (16)   5 | 6789   789    3   |
    | 3   2     157   | (16)   9      8 | (567)  4      57  |
    +-----------------+-----------------+-------------------+
    | 9   8     (157) | (15)   (135)  2 | 3-57   6      4   |
    | 17  1567  3     | 14568  1456   9 | 2      578    578 |
    | 2   4     56    | 568    (356)  7 | 358    1      9   |
    +-----------------+-----------------+-------------------+
    | 17  1379  1479  | 45     2      6 | 5789   35789  578 |
    | 8   67    467   | 9      45     3 | (57)   2      1   |
    | 5   39    2     | 7      8      1 | 4      39     6   |
    +-----------------+-----------------+-------------------+

(7=153)r4c345 - (3=56#1)r6c5 - (56=1#1)r4c4,r2c5 - (1=6)r3c4 - (6=57)r38c7 => r4c7 <> 7

ALS 1357r4c345: triple 157r4c345 or 3r4c5
3r4c5 (-> r6c5=56) -> xy-wing (56r6c5,51r3c4,61r2c5) -> r3c4<>1 -> 6r3c4 (-> r3c7=57) -> pair 57r38c7
=> r4c7 <> 57

Other direction (just invert everything from right to left):
ALS 567r38c7: pair 57r38c7 or 6r3c7
6r3c7 -> 1r3c4 -> 6r2c5 and 5r3c4 (->r6c5<>56) -> r6c5=3 (-> r4c5=15) -> triple 157r4c345
=> r4c7 <> 57
[Instead of "6r2c5 and 5r3c4 (->r6c5<>56)" i could have written "not xy-wing (56r6c5,51r3c4,61r2c5)", which implies that the extra candidate 3 must be true]

I leave out the obvious things like 6r3c7 (-> r3c4<>6) and 1r3c4 (-> r2c5<>1 and r4c4<>1)
If you want, add them and you can formulate easily the implication chain in words as perfect as you did for your links. (Sorry, that i'm too lazy for that, but tell me, if you encounter a problem).

While your complaint that there is no up to date reference on how to notate the Booleans in Eureka AICs is justified, why is it that there is no equivalent reference for your notation style?

This is a feature ! It is a FREE notation, which, as i claim, can be read by a newcomer without any definitions (as long as he is familiar with subsets and other patterns, which are used).

[David P Bird]

Eleven please see the last but one paragraph in my post < in my post of Aug 9th> giving you the link I mentioned.
There you will see that I was able to put each link into words (reading backwards, but that's not so important) over a section of the chain taking them in exactly the same order.
I would like to see how you do the same for your 'intuitive chain' as it would help me understand your conventions.

Code: Select all

    +-----------------+-----------------+-------------------+
    | 6   59    8     | 3      7      4 | 1      59     2   |
    | 4   179   179   | 2      (16)   5 | 6789   789    3   |
    | 3   2     157   | (16)   9      8 | (567)  4      57  |
    +-----------------+-----------------+-------------------+
    | 9   8     (157) | (15)   (135)  2 | 3-57   6      4   |
    | 17  1567  3     | 14568  1456   9 | 2      578    578 |
    | 2   4     56    | 568    (356)  7 | 358    1      9   |
    +-----------------+-----------------+-------------------+
    | 17  1379  1479  | 45     2      6 | 5789   35789  578 |
    | 8   67    467   | 9      45     3 | (57)   2      1   |
    | 5   39    2     | 7      8      1 | 4      39     6   |
    +-----------------+-----------------+-------------------+

(7=153)r4c345 - (3=56#1)r6c5 - (56=1#1)r4c4,r2c5 - (1=6)r3c4 - (6=57)r38c7 => r4c7 <> 7

ALS 1357r4c345: triple 157r4c345 or 3r4c5
3r4c5 (-> r6c5=56) -> xy-wing (56r6c5,51r3c4,61r2c5) -> r3c4<>1 -> 6r3c4 (-> r3c7=57) -> pair 57r38c7
=> r4c7 <> 57

Other direction (just invert everything from right to left):
ALS 567r38c7: pair 57r38c7 or 6r3c7
6r3c7 -> 1r3c4 -> 6r2c5 and 5r3c4 (->r6c5<>56) -> r6c5=3 (-> r4c5=15) -> triple 157r4c345
=> r4c7 <> 57
[Instead of "6r2c5 and 5r3c4 (->r6c5<>56)" i could have written "not xy-wing (56r6c5,51r3c4,61r2c5)", which implies that the extra candidate 3 must be true]

I leave out the obvious things like 6r3c7 (-> r3c4<>6) and 1r3c4 (-> r2c5<>1 and r4c4<>1)
If you want, add them and you can formulate easily the implication chain in words as perfect as you did for your links. (Sorry, that i'm too lazy for that, but tell me, if you encounter a problem).

Hurray! We finally got there! We are agreed your implication 'stream' is not a stream but is disjointed and has gaps in it - and that's from my efforts to put your first example into words.

Because you were clever enough to 'ski off-piste' in your first week, you wrongly believe all beginners should be able to. But they need nursery slopes first which is what Eureka AICs gives them.

While your complaint that there is no up to date reference on how to notate the Booleans in Eureka AICs is justified, why is it that there is no equivalent reference for your notation style?

This is a feature ! It is a FREE notation, which, as i claim, can be read by a newcomer without any definitions (as long as he is familiar with subsets and other patterns, which are used).

But Eureka AICs are just the same! Just keep to the framework of alternating links and plug-in the Booleans as you find them. You are free to express the Booleans as you like provided the reader is able to make sense of them – after all, like you, they are all intelligent. So why is it that you need any further explanation?

All this time you have been a (lazy) mischief maker haven't you? So can we call a stop to it now?

Finally let me admit I'm not as smart as you. I need the discipline of AICs and rigorous checking they allow to help me analyse patterns such as Junior Exocets to find the eliminations they provide. That's is what I meant when I said they would take users on a longer journey.

David

[ArkieTech]

Another free notation:

Code: Select all

    +-----------------+-----------------+-------------------+
    | 6   59    8     | 3      7      4 | 1      59     2   |
    | 4   179   179   | 2      (16)   5 | 6789   789    3   |
    | 3   2     157   | (16)   9      8 | (567)  4      57  |
    +-----------------+-----------------+-------------------+
    | 9   8     (157) | (15)   (135)  2 | 3-57   6      4   |
    | 17  1567  3     | 14568  1456   9 | 2      578    578 |
    | 2   4     56    | 568    (356)  7 | 358    1      9   |
    +-----------------+-----------------+-------------------+
    | 17  1379  1479  | 45     2      6 | 5789   35789  578 |
    | 8   67    467   | 9      45     3 | (57)   2      1   |
    | 5   39    2     | 7      8      1 | 4      39     6   |
    +-----------------+-----------------+-------------------+
    [(57=3)r4c345-(3=5)r6c5-(5=6)r34c4----------(6=57)r38c7]-57r4c7
                    =6)r6c5-(6=1)r2c5-(1=6)r3c4-

[DonM]

Just for giggles and/or if anyone needs a reason to fill an empty few minutes, have a read of the 2 or 3 pages of this thread, starting at the link below, to see how far back a segment (or what I would call agenda) of this 'discussion' goes back. At the very least, it might explain to those who are not familiar with past events why one's patience can sometimes be very thin.

http://forum.enjoysudoku.com/abominable-trial-and-error-and-lovely-braids-t6390-30.html

If your time is limited just read this page:
http://forum.enjoysudoku.com/abominable-trial-and-error-and-lovely-braids-t6390-60.html

[ronk]

Code: Select all

    +-----------------+-----------------+-------------------+
    | 6   59    8     | 3      7      4 | 1      59     2   |
    | 4   179   179   | 2      (16)   5 | 6789   789    3   |
    | 3   2     157   | (16)   9      8 | (567)  4      57  |
    +-----------------+-----------------+-------------------+
    | 9   8     (157) | (15)   (135)  2 | 3-57   6      4   |
    | 17  1567  3     | 14568  1456   9 | 2      578    578 |
    | 2   4     56    | 568    (356)  7 | 358    1      9   |
    +-----------------+-----------------+-------------------+
    | 17  1379  1479  | 45     2      6 | 5789   35789  578 |
    | 8   67    467   | 9      45     3 | (57)   2      1   |
    | 5   39    2     | 7      8      1 | 4      39     6   |
    +-----------------+-----------------+-------------------+

(7=153)r4c345 - (3=56#1)r6c5 - (56=1#1)r4c4,r2c5 - (1=6)r3c4 - (6=57)r38c7 => r4c7 <> 7

ALS 1357r4c345: triple 157r4c345 or 3r4c5
3r4c5 (-> r6c5=56) -> xy-wing (56r6c5,51r3c4,61r2c5) -> r3c4<>1 -> 6r3c4 (-> r3c7=57) -> pair 57r38c7
=> r4c7 <> 57

Hurray! We finally got there! We are agreed your implication 'stream' is not a stream but is disjointed and has gaps in it - and that's from my efforts to put your first example into words.
...
All this time you have been a (lazy) mischief maker haven't you? So can we call a stop to it now?

IMO eleven is using the simplified forcing chain notation as documented by Jeff in early 2006 in his Forcing chains: Terminology and Definition thread. Relative to Jeff's simplified notation, I see no gaps in eleven's l-r and r-l notation for the chain discussed above.

See these Implication Stream and Forcing Chain blocks near the beginning of Jeff's post.

Implication Stream - a sequence of nodes and links where strong or weak inferences are made from one node to the other(s) unidirectionally from left to right. (Refer definitions for "node", "link", "strong inference" and "weak inferences" below)

Code: Select all

Example:

Canonical format:
r1c3=9 => r8c3<>9 => r8c3=7 => r8c9<>7 => r8c9=3 => r3c9<>3 => r3c9=2 => r2c8<>2 => r2c8=1

Simplified format:
r1c3=9 => r8c3=7 => r8c9=3 => r3c9=2 => r2c8=1


Forcing Chain - a chain that has 2 or more implication streams that start from one node and end in another node where the outcomes of inferences merge from the 2 implication streams. In a forcing chain, a node can only infer the next successive node downstream.

Code: Select all

Example:

r9c6=7 => r9c1=8 => r9c1<>7
r9c6=8 => r8c5=7 => r3c5<>7 => r3c1=7 => r9c1<>7
Therefore r9c1<>7

r3c9=9 => r3c4<>9 => r2c4=9 => r2c1<>9
r3c9=7 => (r3c1 & r1c2=89) => r2c1<>9
Therefore r2c1<>9

where (r3c1 & r1c2=89) is a node containing 2 grouped cells.


[blue]

It has been noticeable that the advocates for change were remarkably silent over the first few days of this discussion, but now two Blue, and DAJ, are contributing. What I'd like to know from them (and the others) is do they accept that a compromise standard is sensible or do they want to proceed with one customised to their specific needs?

I was away for a few days around the weekend.
When I came back, I was amazed at how long this thread had gotten, and the directions it had taken.
I held my toungue for a few more days ... not wanting to step into the heat.
I have much to say now, and (again) no time to say it.
I'll be back later (today) with time on hand.

I don't like the idea that you (seem to ?) think of me as wanting to customize anything to my own needs.
in retrospect, I suppose I can see where you're coming from.
This was my first post in this thread ... a week ago now ! The colored highlights are new.

Code: Select all

+---------------------+----------+----------------------+
| 4568  9     2458    | 1  36  7 | (456)   2456    235  |
| 46    (37)  (14)    | 5  9   2 | (1467)  8       (13) |
| 56    37    125     | 8  36  4 | 9       2567    1235 |
+---------------------+----------+----------------------+
| 3     2     89      | 4  7   1 | (56)    569     58   |
| 19    5     7       | 6  2   8 | 13      39      4    |
| 18    4     6       | 3  5   9 | 17      27      128  |
+---------------------+----------+----------------------+
| 7     1     (45)*   | 2  8   6 | (345)   (3)45*  9    |
| 2     6     3       | 9  4   5 | 8       1       7    |
| 459   8     (9)-45* | 7  1   3 | 2       45*     6    |
+---------------------+----------+----------------------+

using UR <45>r79c38:

45r27c3 = 137r2c239 - (17=3456)r1247c7 - 3r7c8 =UR= 9r9c3 => -45r9c3; stte

or right/left reversed:

9r9c3 =UR= 3r7c8 - 3456r1247c7 = 137r2c279 - (1=45)r27c3 => -45r9c3; stte

When I made it (and as I mentioned in my next post), my main (unstated) question was about what people thought about the idea of a strong link between two ALS's. Was it a "legal strong link" or not ?

[ BTW: Thank you sultan_vinegar, for offering to discuss it. I wish I had had the time to respond that day. ]

You'll note that I included every digit in every ALS ... doing my best to provide "full transparency".
The only thing I would have done differently (which I also mentioned early on), was used "((1|7)=3456)" in the first chain ... again, in an attempt to make things as unambiguous as possible.
[ (1|7) -vs- 17 was a side issue, IMO ... ]

If it's of any consequence, my opinion on the "legal strong link or not" issue, was that yes it was perfectly legal -- perhaps even new and inovative (although I had my reservations on how new it was) -- and that given that, what I had presented, was a perfectly legal AIC.

While I'm away, I wonder if you have (or anyone else has) any thoughts on that specific issue.

[ For DonM's benifit: I most emphatically did find this manually.
However, I don't consider myself to be a "good" manual solver, or even a "typical" manual solver. ]

[David P Bird]

IMO eleven is using the simplified forcing chain notation as documented by Jeff in early 2006 in his Forcing chains: Terminology and Definition thread. See these Implication Stream and Forcing Chain blocks near the beginning of the post.

Thanks for that information and perhaps eleven will be pleased to know that too.

Relative to Jeff's simplified notation, I see no gaps in eleven's l-r and r-l notation for the chain discussed above.

.. and that's from my efforts to put your first example into words.

You are the best versed person about the various notations that were developed here and on the Eureka site at the same time. I appreciate the loyalty you feel towards your group of pioneers here, but given that our methods have moved on, what in your opinion is the system that is most suited for our purposes nowadays a) for newcomers & b) for more advanced players who embed pattern deductions? It would help us decide (if that's ever possible) the best course of action to take.