I see no answers to questions 4 and 5, so I assume eleven grudgingly agreed. Thus, there should be no more question whether this link is valid or not:
(3,8)r3c6,r7c9 = (3,8)b8p62
Sure, it's not necessarily trivial to see how it works, especially when read from right to left, but it's definitely not ambiguous. The implied logic is also not complicated enough to be considered derived, as far as I'm concerned. One way to see it both ways is by noting that 3r8c6 and 8r7c5 must be true or false together (same parity).
As I said, I'm happy to leave it like that. I can accept that the original link without the latter comma is perhaps a bit too reduced:
(3,8)r3c6,r7c9 = (38)b8p26
Reading it from left to right is no different from the other but reversal is harder:
mith wrote:(The other direction is also correct; NOT((38)b8p26) => 6b8p2 => 8r7c9 AND 8b8p6 => 3r3c6)
In other words, it works but there's no simple way to do it without using the extra candidate 6b8p2. Since 6b8p2 is not written in the strong link, it puts the link (very mildly) into the derived territory, and it also complicates the logic. That's why I've come to the conclusion that what I said before wasn't fully accurate:
SpAce wrote:My link does not depend on any external logic whatsoever. If it did, I would have written it as a derived link with '==' like you should have done above. Yes, there's some implicit logic in my link, but that's commonly accepted if it happens within the nodes and between the candidates that are explicitly written in the link. That's certainly true here.
Well, it's not quite true because of the 6b8p2. Even though that candidate is written in the chain it's in a different role than what's needed for the strong link. (Too bad eleven never presented that argument, because I would have accepted it.) I was more correct in the original thread:
SpAce wrote:The only thing I might agree to change in the link is to mark it '==' since it's more or less derived.
So, I actually agree with eleven that the original link is somewhat derived and might need the '=='. Of course that's a stupid fix, because it's much better to use the comma on both sides. It results in simpler and less obfuscated logic while allowing to keep the direct link:
(3,8)r3c6,r7c9 = (3,8-6)b8p62 = RP(38)r38c6,r7c59 => -38 r3c9; stte
Any objections to that? If not, then I hope this question is finally settled. It only took almost four months.
--
The way we got there wasn't pretty. I'm really, really tired of these kinds of discussions, where one side A) presents terrible arguments, B) ignores any counterarguments, C) is arrogant as hell, D) makes constant insults with impunity, and worst of all, E) is mostly or completely wrong. I can deal with some subsets of those but not all of them in the same package.
Unfortunately that has been lately the norm with a few people here. The most disappointing of them is eleven, as he has so much to give in many aspects of sudoku. That, however, doesn't excuse behavior that ignores all normal rules of engagement. I never wanted any of this crap with him, but he chose that path and left me no choice. I don't really know why, nor do I much care any more. This is not my idea of fun and intelligent conversations.
