eleven wrote:I have to apologise to Steve and SpAce.
What a surprising turn of events. You actually proved me wrong about something! But wait, what did you actually apologize for? It would be kind of nice if you specified it, because otherwise it has a pretty hollow ring to it. See, I'm expecting apologies for:
- falsely calling my writings "lies" (that would be a slandering term even if I'd made mistakes, but I hadn't -- and I rarely do, so it's pretty presumptuous to even assume so without a huge pile of evidence)
- falsely calling my chain "ambiguous" (in a previous discussion) without never proving nor retracting it (it wasn't)
- continuing your baseless aggression (in that same discussion) even after I called for peace to avoid any conflicts
- blatantly and repeatedly disrespecting my notational skills, even though (or because) they're clearly superior to yours (this discussion has made it painfully obvious)
- constantly whining about my ways of building those skills (if I'd listened to you I wouldn't be at this level)
- generally provoking me repeatedly, so that when I finally responded in a way it deserved, I got banned (though this time it was an expected consequence for what I wrote, unlike last year's warning -- also provoked by you -- which was never explained to me even when I asked)
There are probably insults I forget to mention, but that list should suffice for now. Are you apologizing for any of those offenses or not? Can I expect anything to ever change? This has been going on for a long time, and the latest events have just made it more obvious. That's why my patience has grown extremely thin. Next time I snap, I'll probably get kicked out for good. If that happens, it's on you. While some would undoubtedly hail you as a hero, a select few might not. Besides, it would be pretty funny if you won the game with a referee decision, even though I've scored all the goals.
If your apology wasn't meant to cover any of those things, then it was obviously just for optics. It's the most likely scenario anyway since, based on what you wrote after it, nothing of consequence has changed in your thinking. You really should have left it at that, instead of opting for more of the same. The ugly truth is that you wrote pure garbage, again. That's not a personal attack. There's just no other honest way to describe the content, especially without any incentive to be extra nice.
Thanks to my forced absence, your follow-up nonsense got to stay unchallenged for a full week. You should have used that time to get your facts straight on your own, but you didn't. Seems like you haven't learned a damn thing from this discussion. I'm not sure how that's even possible. Looks like I, and apparently Steve too, have completely failed to
communicate. Shame on us.
--
Anyway, let's get back to business (for the final time, I really hope), though I don't understand why we're still talking about this. I solved the problem a long time ago, but apparently you just can't accept it. There are probably no other valid solutions even available, at least ones that would make practical sense. In any case, you haven't presented any at all. I'm not expecting you will either, but feel free to shock me.
my detailed responses to your irrelevant and flawed implication chain "arguments": Show While my implication chain was correct
49r61c5 => (-9r1c7 -> 13r13c7) & (-9r2c4 -> 1r2c4 -> -r2c12 -> 1r3c1) => -(1|3)r7c17
While that might be correct as a
sudoku implication chain (let's call it 'sic' for now), it's definitely not correct as a standard boolean expression (or rather, it doesn't work as expected). Not even close. Either way, it's my turn to ask: where's the 'sic' syntax and its relationship to standard boolean logic defined? Sure, it's pretty obvious for trivial examples, but not necessarily for more complex things like these.
One way to write that as a standard boolean expression with implications:
(49r61c5 -> (-9r1c7 & -9r2c4)) & (-9r1c7 -> 13r13c7) & (13r13c7 -> -(1|3)r7c7) & (-9r2c4 -> 1r2c4) & (1r2c4 -> -1r2c12) & (-1r2c12 -> 1r3c1) & (1r3c1 -> -1r7c1)
Your expression above is not equivalent to it at all, if both are interpreted as standard boolean logic.
the translation to AIC should be
49r61c5 - ((9r1c7 = 13r13c7) & (9r2c4 = 1r2c4 -r2c12 = 1r3c1)) - (1|3)r7c17
No, it really, really shouldn't. Did you happen to notice that your middle (top-level) node has weak inferences on both sides, and for the same reason the '&' in the middle makes no sense either? Your first version had at least those things correct, and it was your best version anyway. Since then, things have only deteriorated. This is the worst of all.
This cannot be written shorter as
49r61c5 - 9r1c7|r2c4 = (13r13c7 & (1r2c4 -r2c12 = 1r3c1)) - (1|3)r7c17
because the link 9r2c4 = 1r2c4 gets lost !
Oh, you finally figured that one out. Good job. Then again, I've already shown three completely valid ways to fix that very simply. I don't really understand why we're still even talking about this. I've already solved the problem, while you haven't brought any valid options to the table, and I don't expect you will.
Like I said, that's still the best version of your chains. All it needs is one of my simple fixes to make it valid. I guess you simply can't accept any of them, because they're my inventions. That's a bit of a dilemma for you, as I might have emptied the slot machine. By all means surprise me. However, it simply can't happen until you fix your fundamental misunderstandings about AICs, which have become evident during this discussion.
The reason is, that implications (being Boolean expressions) are not associative,
Wrong. Many boolean expressions are fully associative (AND, OR, etc). Implications aren't fully, but even they are right-associative.
That said, it has nothing to do with the problem anyway. No matter how many implication chains you write to confuse everyone and to obscure the problem, it will not change anything, because you obviously don't get why your AICs with this new feature are all invalid. That's pretty shocking, but it's the only conclusion based on the evidence.
i.e. a => b =>c (which means (a=>b) and (b=>c), proving a=>c)
No, it most certainly doesn't mean that under standard boolean logic. Two completely different things, and only the latter actually proves a->c. If and when the first form is used as a shortcut in
sudoku implication chains ('sic'), it must be understood that it's not a standard boolean logic expression. You should specify that when you talk about implication chains to avoid ambiguity. (If you disagree, please look it up before you open your virtual mouth. I really don't want to argue about this too.)
The latter style is the only correct way to write standard implication expressions that are equivalent to AICs. These are all equivalent:
a=b-c=d <-> (a|b)&(-b|-c)&(c|d) <-> (-a->b)&(b->-c)&(-c->d) <-> (-d->c)&(c->-b)&(-b->a)
All of those produce the same truth table, which has 5 true rows (and 11 false ones):
- Code: Select all
abcd
----
FTFT
TFFT
TFTF
TFTT *
TTFT *
Those represent the only valid inputs for that AIC, and it's easy to see that they satisfy all links as well as prove (a|d). Of course, the last two inputs are valid in a real grid only if the TT strong link is non-conjugate (i.e. strong-only, non-native). The AIC logic doesn't know or care, because it only uses OR (and never XOR).
Any notation that claims to be equivalent to that AIC should produce the same truth table. It's not enough that it proves the OR-relationship between the end points. It also needs to validate every link between them, meaning that no invalid combination of input produces a true row in the truth table.
Note that this is not equivalent at all, and it doesn't even prove (-a -> d):
-a -> b -> -c -> d
In fact, it's only false with a single combo of abcd: FTFF. The other fifteen rows in the truth table are true, and they obviously include many that have both a and d false. Thus, that is not a correct way to write an AIC as a standard implication chain, and it certainly doesn't get any more correct with more complex examples. It only makes sense as a sudoku-specific shortcut (i.e. it also requires "pre-processing" to make it a valid boolean expression).
i.e. a => b =>c is not the same as (a=>b)=>c
True.
or a=>(b=>c).
False. It's exactly that, if we're talking about standard implication chains. Right-associative, like I said. That is in fact the least ambiguous way to write it, though it's correct and equal without the parentheses too. Similarly: a->b->c->d <-> a->(b->(c->d))
You must not set braces in an implication chain.
That doesn't make any sense. With standard implication chains it's always a good idea to use parentheses because it disambiguates the logic. That said, no combination of parentheses (alone) makes a standard ic equal to an AIC. It has to be written as (-a->b)&(b->-c)&(-c->d)
These standard boolean expressions are all equivalent:
(a->b->c) <-> (a->(b->c)) <-> (a&b->c) <-> ((a->b)->(a->c)) <-> (b->(a->c)) <-> (-c->(b->-a)) <-> (-a|-b|c)
None of them implies a->c. Also, they're NOT equivalent to these (which are not equivalent to each other either):
((a->b)->c) <-/-> (-c->-b->-a) <-/-> (a->(b&c)) <-/-> ((a->b)&(b->c))
Of any of those, only the last two prove (a->c).
[Edit: This is not the end ...]
Too bad.
So, if you have the implications
-x => a&b and a=>-g and b=>-c=>d=>-g,
you have to write
(-x=>a & (-x=>b=>-c=>d)) => -g, which definitely is correct
Maybe as a 'sic'. It definitely is not correct as a standard boolean expression, as explained above. Your example makes little sense anyway, because you don't need both a and d to prove -g. Switching '&' to '|' fixes that. Written as a standard expression:
(-x->a|b) & (a->-g) & (b->-c) & (-c->d) & (d->-g) => -g (if x sees g)
As a valid AIC:
x = (a | [! = b - c = d]) - g => -g (if x sees g)
while
-x => (a & (b=>-c=>d)) => -g
is wrong, because -x=>(b=>-c=>d) misses (-x=>b)
How does it miss it any more than the previous version? Neither works as a standard boolean expression, so those rules can't be used to judge anything (except to disqualify both). I don't see why they both wouldn't work as
sics, though I guess it depends on the exact syntax definition which I haven't seen anywhere. In fact, I've thought that 'sic' users don't really care about such exact details at all, so are they even defined anywhere?
In any case, no 'sic' will help you here, so you might just as well drop that line of "argumentation".
All of that implication stuff is completely irrelevant. It won't fix your AIC problem, because it totally misses the point.
In fact, your implication chain thinking is quite obviously the root of your problems. You keep making the same fundamental mistake again and again, because you seem to think AICs are just a different syntax to write implication chains. Sure, in simple cases the mapping is trivial, but not here. Not even close. AICs are fundamentally different with a hierarchical node-based structure, but you seem to have missed that totally. Quite incredible, really. I can't believe you've managed to hide such a huge flaw this long. It's no wonder you've had trouble understanding my AICs.
Same with AIC
There's nothing same with AICs. You should not try to apply your 'sic' logic with them. Instead, you should learn to think natively in AICs, and you might see what's actually wrong with your chains. It should also explain to you why mine are (probably) the only correct options here. If you don't bother to learn that, you should tone down your arrogance when talking about AICs and their validity (or ambiguity, for that matter). Some of us actually know what we're doing with them. You've now demonstrated conclusively that you don't.
my responses to your AIC stuff: Show if you have
x=a&b and a-g and b-c=d-g
then
x = (a & (b-c=d)) - g
is wrong
Glad you've accepted that, though quite apparently for the wrong reasons. Either way, the chain is very easy to fix, as I've shown many times. Why don't you simply accept any of my three methods to make it valid, or even the fourth {semi-valid way} which is the simplest of all? None of your new suggestions make it any more valid, just uglier. Is it physically impossible for you to admit that I'm right? It's your loss if you can't.
But if you write (x=a & (x=b-c=d))-g
What about reading it from the right side ??
That's the least of your problems. Once again, that chain doesn't have alternating links, and the '&' makes no sense. You should stick to the previous version (with one of my fixes).
more of completely irrelevant implication chains: Show (-x=>a & (-x=>b=>-c=>d)) => -g
is NOT equivalent to
g => (-a=>x | (-d=>c=>-b=>x) )
but to
(g=>-a=>x | (g=>-d=>c=>-b=>x), shortly
(g=>-a) | (g=>-d=>c=>-b) => x
So the correct AIC should be
(x=a-g & (x=b-c=d-g))
No, it shouldn't, and it isn't. It doesn't fix the fundamental problem in any way, and it's unnecessarily duplicating both x and g within the embedded chains. It's not only invalid, but horrible in every way.
One of the three valid ways to write that:
x = (a | [! = b - c = d]) - g
It's not that hard. When are you going to accept that there's no way around the problem without one of my three fixes, or something equivalent (if exists)? The sooner the better, for everyone involved. I'd really like to drop this stupid debate as soon as possible. You simply can't win it, unless you get me kicked out (again). You're just delaying the inevitable.
Then my original chain would look this way
4r6c3 = 49r61c5 - ((9r1c7 = 13r13c7 - (1|3)r7c7) & (9r2c4 = 1r2c4 -r2c12 = 1r3c1 - 1r7c1)) = (13-4)r7c28 = 4r7c1 => -4r7c3,r4c1
How is that different from your original in any fundamental way? How does it address the reasons that made the original invalid in the first place???
The answers: it isn't, and it doesn't. Not in the slightest. The only difference is that the middle node has more stuff inside, and it has the strong and weak links on different sides of it. It also has a new mistake (common in this post), as the '&' should be '|'.
There's absolutely nothing that even attempts to fix the core problem that was in your original and in every other example since then. Consequently, it's not a valid AIC any more than any of them. I can't believe that you're still insisting something else.
valid options to write that: Show 1) This would be valid:
4r6c3 = 49r61c5 - ([9r1c7 = 13r13c7 - (1|3=!)r7c7] | [(9=1)r2c4 - r2c12 = 1r3c1 - (1=!)r7c1]) = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1
2) And this (though the +notation is a bit awkward in this orientation, and not exactly standard):
4r6c3 = 49r61c5 - ([9r1c7 = 13r13c7 - (1|3)r7c7+] | [(9=1)r2c4 - r2c12 = 1r3c1 - 1r7c1+]) = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1
3) And this (though it makes it considerably longer):
4r6c3 = 49r61c5 - (([9r1c7 = 13r13c7 - (1|3)r7c7] & (1|3)r7c7) | ([(9=1)r2c4 - r2c12 = 1r3c1 - 1r7c1] & 1r7c1)) = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1
4) And this is semi-valid from the pre-processor pov (but when expanded it's one of the above):
4r6c3 = 49r61c5 - ({9r1c7 = 13r13c7 - (1|3)r7c7} | {(9=1)r2c4 - r2c12 = 1r3c1 - 1r7c1}) = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1
I still haven't seen a single valid AIC from you in this discussion, and it looks like I won't. You should give up and accept the truth in the hidden AIC of my previous post. If you want to add any real value, you should find a fourth valid way to write your chain, preferably one that is clearly different from mine and makes practical sense too. I don't see it happening.
--
To get anywhere, you should first figure out why your AICs aren't valid, since it still doesn't seem to be clear to you at all. The first step is to understand how many top-level nodes and links the above chain has. The answers are 6 and 5. In other words, the bird's eye view of that chain is this:
a = b - c = (d-e) = f
The critical node is c, the one that contains the embedded chains. Once you figure out what it takes to make its links work with b and d, you're on the right track. Otherwise you remain lost.
In your version above, the c node is constantly true, so it's incapable of linking (just like in any of your versions). Apparently you still don't understand that, or its significance, probably because you keep staring at its internal details through your flawed implication chain perspective and think the links work fine. They don't.
The truth value of the top-level node itself must be able to switch, or it can't link. If any node can't link, the chain obviously can't be a valid AIC. Period. It makes no difference whatsoever if the internal details (in this case the embedded chains) of the node seem to link properly, if the node itself can't. That's what you still don't get. AICs are not just a different syntax for
sudoku implication chains ('sic').
--
PS. I don't know if this analogy helps you, but the difference between implication chains and AICs is kind of like the difference between procedural and object-oriented programming. Those two programming paradigms are very different both philosophically and in practice, and the same is true about 'sics' and AICs. For a pure procedural programmer OO isn't typically easy to learn, but for an OO programmer procedural programming is trivial (though distasteful). The same seems quite true about 'sic' users and AIC users.
The analogy works in practice too. For an experienced OO programmer, AICs feel natural because the nodes can be seen as "objects". They have a single attribute (state: true|false|unknown), well-defined relationships (links) with other objects (nodes), and an event-driven mechanism (OR, NAND) to switch their states depending on the states of their linked partners. A node that can't switch states is obviously useless because it can't link or trigger events, causing a discontinuity.
Most importantly for this discussion, AIC nodes can contain sub-nodes forming a composite hierarchy (as in our example), which is a very common
design pattern in OO programming. Anyone who's ever built OO user interfaces knows that pattern very well, and thus can see naturally how it works in AICs. I would guess OO isn't your thing, since this seems so difficult for you. (There's no shame in that. The only shame is in not admitting it. Until you do that, you can't fix it either.)
--
The End. (I sincerely hope.)
