The New Sudoku Players' Forum

[SpAce]

But i can repeat the proposal:
- Further use square brackets [] to mark an embedded AIC, i.e. it is true, if one of the endpoints is true.

By that, I assume mean normal almost-AICs of the form b=[c=d-e=f]-g, where b is a spoiler, and c and f both see g? Yeah, that's the normal case, and you might be right that the [] should be reserved for that to avoid confusion.

- other brackets indicate, that it is a subchain, which can be and'ed or or'ed with other terms (used like in implication chains). It works to write (hopefully small) nets.

And how does that translate into a valid AIC? I still don't see any attempt to explain that, nor an admission that it can't be a valid AIC just like that. Should it just be a magical syntax element with no relation to normal AIC rules, and still be considered a valid AIC? That I can't accept.

Did you read my proposal above, about using the {} to mark regions that need preprocessing to make it a valid AIC? That would make your proposal work with an actual explanation, and the syntax could have more general applications for embedding pieces of "foreign notations" or other shortcuts.

Or is that too deep AIC-thinking for a lover of sloppily written implication chains?

[eleven]

To be more concrete:
If you have a net

Code: Select all

      b - c = d       
  //                   \
a                         k ...
  \\                   /
      e -f = g - h = i

you could write it
a = {(b - c = d) & (e -f = g - h = i)} - k ...
(readable from both sides)

[SpAce]

To be more concrete:
If you have a net

Code: Select all

      b - c = d       
  //                   \
a                         k ...
  \\                   /
      e -f = g - h = i

you could write it
a = {(b - c = d) & (e -f = g - h = i)} - k ...
(readable from both sides)

It's the same I suggested, except with the {} on the outside marking the whole node, which I find less logical (though not completely unacceptable -- I thought about that option too). Did you read my post at all?

In any case, I still don't see any actual explanation how you link that syntax with normal AIC rules. I of course explained it for you already, but I guess you can't accept it because it came from me. Or perhaps you'll soon suggest the same exact thing as a new idea.

[eleven]

I don't understand you. Yes, i read your posts, though they are extremely long (opposite to your compressed notation). I saw, that you thought about that "meaning" of brackets in my way, but you still insisted, that i have not answered your question. I answered and you said, that you already have tried that.

Please let me alone with your notation questions. I don't have a problem. If i cannot write it in accepted AIC, i write it with implication chains.

[SpAce]

I don't understand you. Yes, i read your posts, though they are extremely long (opposite to your compressed notation).

You just had to say that, didn't you? So predictable.

I saw, that you thought about that "meaning" of brackets in my way,

Really? You have indicated no such thing until now. If you thought that I captured your idea perfectly, then wouldn't it have been easier to just say so? Instead you explained (the obvious parts of) yours in two different posts without any reference to what I'd written. In fact, I don't think the core idea is the same anyway, even though the syntax almost is (not many options there), and that's what I'm really interested in. Your first reply to my post was:

But i can repeat the proposal:
- Further use square brackets [] to mark an embedded AIC, i.e. it is true, if one of the endpoints is true.
- other brackets indicate, that it is a subchain, which can be and'ed or or'ed with other terms (used like in implication chains). It works to write (hopefully small) nets.

The latter half has no resemblance to what I suggested, or at least I don't see it. As far as I understand it, it doesn't translate to a valid AIC either. That's what I wanted you to explain further, but you never did. Your options were (and are): 1) explain your own way of translating it to a valid AIC, 2) accept my way of translating it to a valid AIC, or 3) accept that it has no connection to a valid AIC. So far you haven't picked any of them. (Besides, "subchain" has an established meaning already. A better term would be "chain fragment" or something.)

but you still insisted, that i have not answered your question.

And I still insist the same. (But that's ok. I already learned last time how this discussion would most likely end, so nothing new here. You just leave all the difficult questions unanswered and claim that you've answered everything.)

I answered

No, you didn't answer my question at all. Instead you drew a diagram to explain what I'd just explained back to me. Duh.

and you said, that you already have tried that.

Wasn't that obvious if you'd read my posts? Why did you waste your time explaining something I clearly understood already, and then leave out the answer to the only question I really asked?

Please let me alone with your notation questions.

Well, I kinda thought I specifically excluded you from this discussion when I started it:

Hi everyone who's interested in notational details

So, did I really ask your opinion at all? No, because I'm not really interested in discussing anything, the least of all notational details, with you after last time. You still have unanswered questions there too. (That doesn't mean I'm not interested in your opinions. Your input was in fact valuable now too. It's just the discussing part that I'm not interested in, because it follows the same deadly patterns every time.)

But, as usual you got involved anyway. And as usual you blame me for that. Déjà vu, like everything else.

I don't have a problem.

Yes, you do.

If i cannot write it in accepted AIC, i write it with implication chains.

I'm still not convinced that they're any more correct, but a good thing is that no one cares.

[SpAce]

Btw, this might be a pretty clean (though a bit longer) way to write it without any tricks or special syntaxes:

4r6c3 = 49r61c5 - 9r1c7|r2c4 = (13r13c7 & 1r2c4 & (1r2c4 - r2c12 = 1r3c1)) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1

The critical weak link works because it's not possible that all three of these are true at the same time:

1r2c4, (1r2c4 - r2c12 = 1r3c1), 1r7c1

In other words, these links work:

9r2c4 = (1r2c4 & (1r2c4 - r2c12 = 1r3c1)) - 1r7c1

In this variant the chain fragment is never false, nor does it have its own links at all, but it's ok because it works with its ANDed partner 1r2c4. The latter provides the strong link and their combo provides the weak link.

I chose to use the normal brackets () around the chain fragment to differentiate from a fully linkable nested chain. That tells the reader that they shouldn't even try to look for weak links (*) for it, unlike with real nested chains marked with []. On the other hand, the contradiction variant should be written with [], because it actually is a fully linkable nested AIC, though a bit special kind. Neither choice is strictly incorrect either way, but I think that would be the clearest division.

(*) Even this variant could have a strong link, but it would be a pretty special case. I'm not sure which bracket type would be better in that case. Maybe () still.

The only sure thing is that {} is not correct here, since it seems to be on its way to a special meaning. This is perfectly normal AIC syntax, just like the contradiction variant, so they don't need any preprocessing or special interpretations.

[SpAce]

Here's another option I just came up with. It might actually be my favorite, and the syntax is applicable elsewhere too:

[+1r2c4 - r2c12 = 1r3c1]

It's basically a cleaner replacement for the reversed contradiction chain, because it starts directly with a truth instead of a contradiction. The logic is the same. The only downside is that it requires a (kind of) new syntax element, though its meaning should be pretty intuitive.

The '+' indicates that the 1r2c4 is assumed true, which is exactly what the contradiction chain did indirectly. It's the key that makes the outer links of the full node work. The +1r2c4 can also be considered a sole guardian of a very simple DP (empty cell in this case), and guardians are traditionally marked with a '+' as well. So, either way you look at it, the syntax should make sense. The full chain:

4r6c3 = 49r61c5 - 9r1c7|r2c4 = (13r13c7 & [+1r2c4 - r2c12 = 1r3c1]) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1

The [] is the correct bracket option, because it's a fully linkable nested chain just like the contradiction chain.

Thus, so far we have four options to write it, incidentally with three different kinds of brackets:

[+1r2c4 - r2c12 = 1r3c1] <=> [(!=1)r2c4 - r2c12 = 1r3c1] <=> (1r2c4 & (1r2c4 - r2c12 = 1r3c1)) <~> {1r2c4 - r2c12 = 1r3c1}

The rightmost version is not valid per se, but in this context the {} implies preprocessing that generates one of the valid options to the left. Of course the +option is not technically valid either until the symbol is accepted, but I think its meaning is so self-explanatory that it should be. It's probably the one that I would actually use, but we'll see.

With the neat and valid +option I don't really see much of a reason to use the {} kludge, except maybe in some very complicated situations that might need memory markers for clarity (not really a great idea anyway).

[SteveG48]

I don't like

4r6c3 = 49r61c5 - 9r1c7|r2c4 = (13r13c7 & 1r2c4 & (1r2c4 - r2c12 = 1r3c1)) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1

because (1r2c4 - r2c12 = 1r3c1) is always boolean true in this puzzle, so why write it?

I also don't like this variant

4r6c3 = 49r61c5 - 9r1c7|r2c4 = (13r13c7 & [+1r2c4 - r2c12 = 1r3c1]) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1

because adding the + sign doesn't change the boolean interpretation (at least in my mind).

I liked the original idea because the use of ! clearly indicates that something special is going on. What that is can be explained in the hypothetical Eudora
explanation that we hope will someday exist.

[SpAce]

Hi Steve,

Thanks for your honest feedback! Not exactly what I expected, but that makes it even more valuable!

I don't like

4r6c3 = 49r61c5 - 9r1c7|r2c4 = (13r13c7 & 1r2c4 & (1r2c4 - r2c12 = 1r3c1)) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1

Interesting! I actually thought you'd like that variant best, as it has the most normal syntax (though the most verbose too). Then again, it looks like I failed to communicate how it works, so maybe there's still a chance:

because (1r2c4 - r2c12 = 1r3c1) is always boolean true in this puzzle, so why write it?

Because if you don't write it, the weak link doesn't work. As I tried to explain, in this variant it doesn't matter if the chain fragment is permanently true or not, as long as it's true when needed. That's why it doesn't need its own strong link, though in a different situation it could have one (but no independent weak link, or it would be a real nested chain).

You can have any number of permanently true members in an ANDed node, as long as there's at least one variable (because if it's false, it would make the whole node false regardless of any other members). Similarly you could have just as many permanently false members in an ORed node, as long as at least one could be true. The only useless cases are if you have even one permanently false member in an ANDed node, or a permanently true member in an ORed node. Those nodes have constant truth values. Not this one.

What matters is that the combo (1r2c4 & (1r2c4 - r2c12 = 1r3c1)) is not always true, because of the variable 1r2c4. That gives us both the strong link (through 1r2c4) and the weak link (through 1r3c1) for that half of the full split node. Neither can work alone, because 1r2c4 has no direct weak link, and the chain fragment has no links at all by itself. That's why only their ANDed combo is a fully linkable unit.

Let's look at the simplified version:

9r2c4 = (1r2c4 & (1r2c4 - r2c12 = 1r3c1)) - 1r7c1

The combo node in the middle is TRUE only when both 1r2c4 AND (1r2c4 - r2c12 = 1r3c1) are true. Since the latter is always true, the truth value of the whole node is the same as that of 1r2c4.

Strong link: If 9r2c4 is false, then 1r2c4 is true and so is the combo node because the chain is always true. If the node is false, then 1r2c4 must be false, and 9r2c4 must be true. Thus there's a strong link between the combo node and 9r2c4.

Weak link: If 1r7c1 is true, then 1r3c1 must be false, and since the chain is always true, 1r2c4 must be false, which makes the combo node false (activating the strong link). If the node is true, then 1r2c4 is true and so is 1r3c1 because the chain is always true, which means 1r7c1 must be false. Thus there's a weak link between the combo node and 1r7c1.

How the truth values are distributed:

-9r2c4 +(+1r2c4 & +(+1r2c4 -1r2c12 +1r3c1)) -1r7c1 (going right)

+9r2c4 -(-1r2c4 & +(-1r2c4 +1r2c12 -1r3c1)) +1r7c1 (going left)

In both cases the chain node is true, and it actually needs to be.

Try getting the same results by taking out either 1r2c4 or the chain fragment, and without any of the other tricks.

--

I also don't like this variant

4r6c3 = 49r61c5 - 9r1c7|r2c4 = (13r13c7 & [+1r2c4 - r2c12 = 1r3c1]) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1

because adding the + sign doesn't change the boolean interpretation (at least in my mind).

You surprised me with that too! I don't see any problem myself, because as far as I know, the '+' has no pre-existing meaning inside an AIC. Yet, I think I (finally) understand what you mean, which is why I deleted what I originally wrote. Perhaps it's a bit ambiguous, but I see little room for actual confusion if the intended semantics are explained, since no one uses the '+' for anything else inside a chain. It probably only makes sense in this particular situation anyway, by fixing one endpoint true in a chain that wouldn't otherwise lead to any conclusion.

In this case that syntax should be equivalent to this:

9r2c4 = (1r2c4 & -1r2c12 & 1r3c1) - 1r7c1

Anyway, here's how I see the difference in truth distributions. First without the '+' and then with it:

9r2c4 = (1r2c4 - r2c12 = 1r3c1) - 1r7c1

-9r2c4 +(?1r2c4 ?1r2c12 ?1r3c1) ?1r7c1 (going right)

?9r2c4 +(?1r2c4 ?1r2c12 ?1r3c1) +1r7c1 (going left)

In that variant neither outer link works because the middle node (the chain) is permanently true. On the other hand:

9r2c4 = (+1r2c4 - r2c12 = 1r3c1) - 1r7c1

-9r2c4 +(+1r2c4 -1r2c12 +1r3c1) -1r7c1 (going right)

+9r2c4 -(-1r2c4 +1r2c12 -1r3c1) +1r7c1 (going left)

This variant works because the middle node can actually switch truth states. The chain itself is the same, and thus permanently true, but the containing node is now true only if the chain's leftmost node 1r2c4 is true (implying +1r3c1), which makes both links work.

I liked the original idea because the use of ! clearly indicates that something special is going on. What that is can be explained in the hypothetical Eudora
explanation that we hope will someday exist.

Well, I'm glad you liked even one of them! Do my counterarguments change your mind at all about the other two?

[SteveG48]

OK, I see where you're coming from now, and you're right. I prefer (and very much so)

4r6c3 = 49r61c5 - 9r1c7|r2c4 = (13r13c7 & 1r2c4 & (1r2c4 - r2c12 = 1r3c1)) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1 .

Sorry I was slow on the uptake.

I'm still curious to see how often we use it. I've already shown one simple re-write for Eleven's solution that keeps it a pure AIC, and I can come up with at least one more that works. Let's be on the lookout for opportunities.

[SpAce]

Hi Steve,

OK, I see where you're coming from now, and you're right. I prefer (and very much so) ...

I'm glad to hear my prediction wasn't totally wrong! Btw, I tried some more complex examples with that approach, and against my earlier recommendation, I think I'd rather use the [] brackets with that too. If all brackets are of the same type (), they get really hard to keep track of, and the readability suffers. Perhaps it's best to enclose any (valid) embedded chain in [] to avoid that, at least in more complicated cases.

What about the +option? I understand if you don't personally like it, but would it be an acceptable syntax to you if others used it?

I'm still curious to see how often we use it. I've already shown one simple re-write for Eleven's solution that keeps it a pure AIC, and I can come up with at least one more that works. Let's be on the lookout for opportunities.

Well, you and I both are probably among those that would see the least actual need for it. However, I think it might be an easier way to write simple nets for those who don't want to invest in learning and finding pure split-node chains every time. Besides, there are cases when the latter aren't optimal and the most readable notations anyway, and this might offer a way out. Maybe. In any case, I would think and hope that this is a last resort notation. I really don't want to start seeing complicated nets written with this style. (I might practice writing those too, just to find the limits of this, but they're not to be taken as good examples).

Like I said earlier, with some split-node chains it's really hard to sync the branches in any reasonable way, so that would be an obvious use case. One example of that is my pet peeve with the 'unbalanced split nodes' where one half is depending on the other happening first. Could this offer another solution to that? I think it might sometimes be more readable than the ones we've discussed before.

[eleven]

No, this time i have not read your creative new proposals and comments.

But to call my chain invalid, is a pure lie, which you like to repeat.
Before you call something valid or not, you should define the AIC rules.

The rules i use are:
- an AIC starts with a strong inference, has alternating strong and weak inferences and ends with a strong inference
- all used inferences can directly be validated (in the candidates grid) without using any other properties or inferences in the chain or grid

With these 2 rules an AIC can easiliy be verified: just verify one link after the other.
And they give the AIC these essential properties:
- for any 2 terms, where the one is on the left and the other on the right side of '=', at least one must be true
- if the chain is a loop, i.e. there is a weak inference between the last and the first term, then all weak inferences become strong ones

To allow more complex deductions, nested strong pattern inferences have been introduced, like x-a=UR=b-y. They seem to be commonly accepted. To verify it, the nested inference (a=b) has to be checked.
Also or's (|) and and's (&) have been allowed in terms, e.g. (a|b) = c&d
Since AIC's like [a=c-d= ... -x=b] imply a=b, (a|b) then could be replaced by such a nested AIC, indicated by square brackets, e.g. [a=c-d=b] = y.
This seems to be widely accepted. The validation is simple and clear: first validate the nested AIC, then the link (a|b) = y.

But what, if -(a|b) does not directly imply y ? E.g. if a=c is only correct, if y is false,"[a=c-d=b] = y" as a whole would be logical correct, but in my eyes this is no valid AIC, because you cannot verify a=c without the outside assumption, that y is false, i.e. it conflicts with the second rule.

The same problem i have with "AIC"s, which remember a digit, like
a = *b - c = d - *e = f
[Reformulated] Read from right to left f=e depends on the assumption, that b is false.

The normal way to make complex things easily verifiable is to split them into parts in brackets, which can be verified on their own.
For verifying a combined link with a (correct) term in brackets just use the nearest terms in the brackets, e.g.
x = (a & (b - c = d)) - e = f:
check the links x = a&b, b - c, c = d, a&d - e and e=f. To do that, you never need anything else than the terms you check.

E.g. Steve's chain
4r379c1 = (4*)r1c1&(96@)r79c1 - (6=4)r9c4 - (*44)r19c7 = 4r8c7 - (4|@6=8)r8c2 ...
could be written
4r379c1 = (96r79c1 & ( (4r1c1 & (6r79c1 - (6=4)r9c4) )- 4r19c7 = 4r8c7) - (4|6=8)r8c2 ...

Now i don't say, that i would like this presentation, but different to a memory chain it is a valid AIC, and does not need any more sign than the common brackets and can be verified link after link.
That such things are not easy to write in AIC is a problem of the AIC definition, not my way of doing it.

So for those, who are not blind for elementary logic,
4r6c3 = 49r61c5 - 9r1c7|r2c4 = ( 13r13c7 & (1r2c4 -r2c12 = 1r3c1) ) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r7c3,r4c1
is a perfectly valid AIC, consistent with it's rules.

DON'T CALL IT INVALID again !!

[eleven]

Once you are able to come with a defintion on an AIC, we can continue to discuss it.
If you take mine above (which i think is commonly accepted), both cases should be clear for you.

But of course you don't want a definition. Otherwise you could not spread any nonsense about them.

[SpAce]

eleven, I broke my promise and actually read your post. I regret that.

I can't believe I have to waste time with such complete nonsense from someone of your stature.

Once you are able to come with a defintion on an AIC, we can continue to discuss it.

RTFM. There's nothing to discuss.

If you take mine above (which i think is commonly accepted), both cases should be clear for you.

Lol.

But of course you don't want a definition. Otherwise you could not spread any nonsense about them.

In my experience, people who are losing an argument and can't admit it, start suddenly looking for excuses in definitions. That trick doesn't work here, I'm afraid. I don't think any other expert-level regulars have any trouble knowing the definition of an AIC. Only you seem to be very confused all of a sudden, though that doesn't seem very credible either.

But to call my chain invalid, is a pure lie, which you like to repeat.

It takes guts to call me a liar, I give you that. It's even braver than calling my chain ambiguous.

Before you call something valid or not, you should define the AIC rules.

I can smell your desperation.

irrelevant musings obscuring the real problem: Show

The rules i use are:
- an AIC starts with a strong inference, has alternating strong and weak inferences and ends with a strong inference
- all used inferences can directly be validated (in the candidates grid) without using any other properties or inferences in the chain or grid

With these 2 rules an AIC can easiliy be verified: just verify one link after the other.
And they give the AIC these essential properties:
- for any 2 terms, where the one is on the left and the other on the right side of '=', at least one must be true
- if the chain is a loop, i.e. there is a weak inference between the last and the first term, then all weak inferences become strong ones

To allow more complex deductions, nested strong pattern inferences have been introduced, like x-a=UR=b-y. They seem to be commonly accepted. To verify it, the nested inference (a=b) has to be checked.
Also or's (|) and and's (&) have been allowed in terms, e.g. (a|b) = c&d
Since AIC's like [a=c-d= ... -x=b] imply a=b, (a|b) then could be replaced by such a nested AIC, indicated by square brackets, e.g. [a=c-d=b] = y.
This seems to be widely accepted. The validation is simple and clear: first validate the nested AIC, then the link (a|b) = y.

But what, if -(a|b) does not directly imply y ? E.g. if a=c is only correct, if y is false,"[a=c-d=b] = y" as a whole would be logical correct, but in my eyes this is no valid AIC, because you cannot verify a=c without the outside assumption, that y is false, i.e. it conflicts with the second rule.

The same problem i have with "AIC"s, which remember a digit, like
a = *b - c = d - *e = f
[Reformulated] Read from right to left f=e depends on the assumption, that b is false.

The normal way to make complex things easily verifiable is to split them into parts in brackets, which can be verified on their own.
For verifying a combined link with a (correct) term in brackets just use the nearest terms in the brackets, e.g.
x = (a & (b - c = d)) - e = f:
check the links x = a&b, b - c, c = d, a&d - e and e=f. To do that, you never need anything else than the terms you check.

Funny. That looks like my thinking in January 2018, when I presented pretty much the same idea as a newbie. No worries, you're only coming two years behind me. Unless your implication chain background totally blocks your thinking, you'll eventually figure out why that's complete nonsense in the context of AICs. Steve helped me back then. You should ask him to explain, or maybe take another look at that discussion.

more irrelevant stuff: Show

E.g. Steve's chain
4r379c1 = (4*)r1c1&(96@)r79c1 - (6=4)r9c4 - (*44)r19c7 = 4r8c7 - (4|@6=8)r8c2 ...
could be written
4r379c1 = (96r79c1 & ( (4r1c1 & (6r79c1 - (6=4)r9c4) )- 4r19c7 = 4r8c7) - (4|6=8)r8c2 ...

Now i don't say, that i would like this presentation, but different to a memory chain it is a valid AIC, and does not need any more sign than the common brackets and can be verified link after link.
That such things are not easy to write in AIC is a problem of the AIC definition, not my way of doing it.

So for those, who are not blind for elementary logic,
4r6c3 = 49r61c5 - 9r1c7|r2c4 = ( 13r13c7 & (1r2c4 -r2c12 = 1r3c1) ) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r7c3,r4c1
is a perfectly valid AIC, consistent with it's rules.

You mean your elementary logic with your rules. I'd be very interested (not really) in how they explain the weak link (NAND) between these two top-level nodes (or terms):

( 13r13c7 & (1r2c4 - r2c12 = 1r3c1) ) - (1|3)r7c17

With our rules, I don't see anything that prevents both sides from being true at the same time, which is the definition of a weak link. Do you? Note that with our rules you can't use any information from elsewhere in the chain to validate the link, just the two adjacent nodes and what's in the grid. That's a core part of the normal AIC definition, and adhered to by everyone here as far as I know. It would seem incredible if you've somehow missed that class.

In the left top-level node the only variable is the sub-node 13r13c7, because its ANDed partner (the other sub-node with the chain) is true all the time. If 13r13c7 is true, the left node is true, otherwise not. If the left node is true, i.e. 13r13c7 is true, then (1|3)r7c7 can't be true in the right side node, and vice versa. In other words, there's a partial weak link between the top-level nodes.

That still leaves 1r7c1 unaccounted for in the right side node. What in the left side node is in conflict with that? Clearly not 13r13c7. What about the other sub-node with the chain? If it were, then 1r7c1 would be really dead already, since the chain is permanently true. Thus the answer is: nothing at all is in conflict with 1r7c1. It could be perfectly well true together with the left node. Thus the weak link is not valid, and neither is your chain. Case closed.

If there's still something you don't understand, consider the (permanently true) chain and its possible distributions of internal truths:

Code: Select all

(1r2c4 - 1r2c12 = 1r3c1)

   T       F       T
   F       T       F
   F       F       T

Unfortunately for you, the middle case has 1r3c1 false. Since it's the only thing in the left node that could even be in conflict with 1r7c1 in the right node, it means that 1r7c1 can be true perfectly well when the left node is true. That of course invalidates the weak link, and therefore your chain. Did I forget to mention that?

DON'T CALL IT INVALID again !!

I just did. Twice. Oops.

On a second thought, I technically didn't. Let's fix that quickly: your chain is INVALID.

[eleven]

Code: Select all

(1r2c4 - 1r2c12 = 1r3c1)

   T       F       T
   F       T       F
   F       F       T

Unfortunately for you, the middle case has 1r3c1 false. Since it's the only thing in the left node that could even be in conflict with 1r7c1 in the right node, it means that 1r7c1 can be true perfectly well when the left node is true. That of course invalidates the weak link, and therefore your chain. Did I forget to mention that?

Ok, so it is really simplest logic, you are not capable of.
Your stubbornness paired with that lack definitely makes it impossible to explain it to you, though not much more is needed than to realize, that true is true and false is false.
I forgive you all.