Another one Trick SE 9.0 Puzzle

Post puzzles for others to solve here.

Re: Another one Trick SE 9.0 Puzzle

Postby eleven » Mon Jun 08, 2020 8:36 am

SpAce wrote:
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.
eleven
 
Posts: 2414
Joined: 10 February 2008

Re: Another one Trick SE 9.0 Puzzle

Postby SpAce » Mon Jun 08, 2020 9:29 am

eleven wrote: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.

Funny.

If you were a decent and honorable person, you'd be drafting your concession speech, deepest apologies, and unconditional surrender right now. But of course you can't do that. It's just not in you. That's ok, though. It doesn't change the fact that my tanks are rolling in your capital, and there's nothing you can do about it. You really should have seen that coming if you'd been paying attention at all. Your unrelenting arrogance has made you blind and deaf. And a total ..... too.

Make no mistake, you brought this on yourself, totally. When I sensed that the last discussion was turning onto familiar tracks, I begged you to help me avoid the deadly spirals of our past discussions. I didn't want any kind of conflict, much less a full war, with you. Yet you just kept pushing like you were on a mission to destroy me.

Well, you didn't beat me then (though you never conceded), and you didn't beat me now (though you never conceded). But go on, keep trying, if that really is your current mission in life like it seems. Perhaps you'll hit the jackpot eventually. I'm curious, though. What will you win if that happens? Would it make you happy if you could embarrass me in front of everyone? Or get me kicked out?

You know what? This may surprise you, but I'm not happy at all for having to embarrass you like this. It saddens me. Actually I didn't even do it. You did it all by yourself, like arrogant people tend to do.
User avatar
SpAce
 
Posts: 2321
Joined: 22 May 2017

Re: Another one Trick SE 9.0 Puzzle

Postby eleven » Mon Jun 08, 2020 10:49 am

Hidden Text: Show
@Steve:
You are mixing the terms correct and Boolean true. A part of a chain is correct (some say "it is true") or not, but it cannot have a Boolean value true or false.
If you translate the chain a = (b & (c - d = e)) - f into a Boolean expression, you get
a OR (b AND c) AND (c NAND d) AND (d OR e)) AND (b AND e) NAND f
That whole term is correct, if all Boolean expressions are correct,
and true,
if a is true, or
b=true and c = true and d is false and e is true and f is false

[Edit:] Corrected the Boolean expresion.
I see now, that you can misinterpret it because of the double function of c.
You both have the link a=c and the links (c - b = e). If you ignore the first, it is not valid.
Last edited by eleven on Wed Jun 10, 2020 8:59 am, edited 4 times in total.
eleven
 
Posts: 2414
Joined: 10 February 2008

Re: Another one Trick SE 9.0 Puzzle

Postby SpAce » Mon Jun 08, 2020 11:37 am

eleven wrote:If you translate the chain a = (b & (c - d = e)) - f into a Boolean expression, you get
a OR (b AND (c NAND d OR e)) NAND f

Not even close. Try:

(a OR (b AND ((c NAND d) AND (d OR e))) AND ((b AND ((c NAND d) AND (d OR e))) NAND f)

--

Added.

You are mixing the terms correct and Boolean true. A part of a chain is correct (some say "it is true") or not, but it cannot have a Boolean value true or false.

I get the point, but that's a very confusing way to say it. Something being correct is a boolean that can be true or false. A piece of chain existing in the grid is a boolean (synonym to correctness, really), etc. Most properties can be expressed as a boolean, and any boolean can be used as a term in an AIC. Thus it makes no sense to talk about a "Boolean value" of a chain as if it were a single thing. What is actually meant is something like a "logic value", which is just one of the possible boolean values of a chain pattern, and it's only relevant with these new chain fragments anyway.

It's indeed a bit ambiguous to talk about a truth value with an embedded chain, because it can be at least two things. With any normal nested almost-AICs of the form (a = b - c = d) and other normal almost-patterns it actually means correctness only, because no input is assumed. That's what their strong links are about: if a spoiler is false, the pattern must be true (i.e. correct, exist) with an active weak link based on the pattern itself, and vice versa. Thus, in almost all cases of nested chains correctness is their one and only truth value. (At least it's the simplest way to see it.)

With these new chain fragments of the form (c - d = e) the situation is different because their patterns alone don't provide any weak links. Thus they do need input as well to function at all. That gives us another component to the truth value. Correctness is still a necessary part (an incorrect chain is always false), but now also the "logic value" of the chain itself counts, and it's calculated based on the input. It's false, if the input produces a contradiction, and true otherwise.

The only way to provide any input to an embedded chain is if it comes from within the containing node (as an ANDed endpoint) or if it's hardcoded into the chain itself (!=, +). There's no valid way to provide any input directly to the chain from outside of the top-level node. I hope such mirages can finally be put to rest.

What about a chain fragment of that form that doesn't have any input? Well, the only defining value then is correctness. If it's correct, it's true, and that's that. Problem is, such a chain fragment can't have any weak links without input, which makes it totally useless, so it could just as well be considered undefined.

just an AIC example: Show
(eleven is wrong) = (moon is made of cheese) - (eleven is right) = (SpAce is right)
User avatar
SpAce
 
Posts: 2321
Joined: 22 May 2017

Re: Another one Trick SE 9.0 Puzzle

Postby eleven » Wed Jun 10, 2020 12:30 pm

I have to apologise to Steve and SpAce.

While my implication chain was correct
49r61c5 => (-9r1c7 -> 13r13c7) & (-9r2c4 -> 1r2c4 -> -r2c12 -> 1r3c1) => (1|3)r7c17

the translation to AIC should be
49r61c5 - ((9r1c7 = 13r13c7 & (9r2c4 = 1r2c4 -r2c12 = 1r3c1)) - (1|3)r7c17

This cannot be written shorter as
49r61c5 - 9r1c7|r2c4 = (13r13c7 & (1r2c4 -r2c12 = 1r3c1)) - (1|3)r7c17
because the link 9r2c4 = 1r2c4 gets lost !

The reason is, that implications (being Boolean expressions) are not associative, i.e. a => b =>c (which means (a=>b) and (b=>c), proving a=>c), is not the same as (a=>b)=>c or a=>(b=>c). You must not set braces in an implication chain.

[Edit: This is not the end ...]
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
while
-x => (a & (b=>-c=>d)) => -g
is wrong, because -x=>(b=>-c=>d) misses (-x=>b)

Same with AIC, if you have
x=a&b and a-g and b-c=d-g
then
x = (a & (b-c=d)) - g
is wrong

But if you write
(x=a & (x=b-c=d))-g
What about reading it from the right side ??

(-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))

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

[Edit: corrected typo - thanks to SpAce]
Last edited by eleven on Tue Jun 16, 2020 8:28 pm, edited 1 time in total.
eleven
 
Posts: 2414
Joined: 10 February 2008

Re: Another one Trick SE 9.0 Puzzle

Postby SpAce » Tue Jun 16, 2020 7:42 am

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:

  1. 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)
  2. falsely calling my chain "ambiguous" (in a previous discussion) without never proving nor retracting it (it wasn't)
  3. continuing your baseless aggression (in that same discussion) even after I called for peace to avoid any conflicts
  4. blatantly and repeatedly disrespecting my notational skills, even though (or because) they're clearly superior to yours (this discussion has made it painfully obvious)
  5. constantly whining about my ways of building those skills (if I'd listened to you I wouldn't be at this level)
  6. 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.)
User avatar
SpAce
 
Posts: 2321
Joined: 22 May 2017

Re: Another one Trick SE 9.0 Puzzle

Postby eleven » Tue Jun 16, 2020 8:27 pm

Thanks for pointing out the typo.

In the moment i am short of time, and it seems, that i would need some time to explain to you, why my AIC now is logically correct.
Maybe it is not necessary, if you would try to explain, why not (leaving out unnecessary personal and historical comments and other digressions).
eleven
 
Posts: 2414
Joined: 10 February 2008

Re: Another one Trick SE 9.0 Puzzle

Postby SpAce » Tue Jun 16, 2020 11:23 pm

eleven wrote:In the moment i am short of time, and it seems, that i would need some time to explain to you, why my AIC now is logically correct.

There's about 10^100 years till the heat death of the universe. I don't think that's enough.

Maybe it is not necessary

You're right, it really isn't. I'm not wasting any more time with your nonsense. It's now obvious that you simply can't admit being wrong. Just like I predicted.

if you would try to explain, why not

I've already done that in as many ways as I can. Repeating myself for the nth time won't help if you still don't get it.

(leaving out unnecessary personal and historical comments and other digressions).

I was just interested in what exactly you pretended to apologize for, and it looks like I was right about that too. 'Nothing' was the right answer, just as I thought. Thanks for confirming it.
User avatar
SpAce
 
Posts: 2321
Joined: 22 May 2017

Re: Another one Trick SE 9.0 Puzzle

Postby SpAce » Sun Jul 12, 2020 2:54 pm

So, eleven seems to have surfaced but I still see no admittance of anything. I get it. It must be so hard to break out of the denial phase after such monumental hubris and mocking. Well, let me show an example of how to admit being wrong.

SpAce wrote:
eleven wrote:In the moment i am short of time, and it seems, that i would need some time to explain to you, why my AIC now is logically correct. Maybe it is not necessary, if you would try to explain, why not

I've already done that in as many ways as I can. Repeating myself for the nth time won't help if you still don't get it.

I was wrong about that. (See how easy that was?) There's still one simple way I haven't tried to make my point. It should be compelling enough for most, though of course nothing helps if someone's convictions are as strong as those of flat-earthers. Let's try anyway.

Rule: a nested chain should work just as well if reversed, like any AIC. (Any chain fragment within brackets of any kind is a nested chain.)

Thus, if you claim this is correct:

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

...then you should be able to claim that this is equivalent and thus correct just as well:

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

Do you?

On the other hand, written my way (any of them) the reversals work just fine:

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

Of course it's much harder to read if those parts are reversed, but that's not the point. It's still valid and works as intended. The same can't be said about yours, either way it's written. QED.

PS. I think I'll drop both the {}-kludge as well as the '+'-syntax. The minimal shortening and apparent simplification they yield is probably not worth the added complexity of new syntax elements with very little other use. That leaves two valid ways to do it, and both of them have their places.
User avatar
SpAce
 
Posts: 2321
Joined: 22 May 2017

Re: Another one Trick SE 9.0 Puzzle

Postby eleven » Sun Jul 12, 2020 11:15 pm

Sorry, i still don't have time enough to discuss things with you.
eleven
 
Posts: 2414
Joined: 10 February 2008

Re: Another one Trick SE 9.0 Puzzle

Postby SpAce » Mon Jul 13, 2020 1:17 am

eleven wrote:Sorry, i still don't have time enough to discuss things with you.

You think I still want to discuss this? With you? Lol. There's nothing to discuss. I'm just trying to help you cope with reality. The sooner you accept the truth, the better for everyone. The longer you delay, the deeper hole you dig for yourself.

The only respectable thing to do is to admit that you stumbled pretty badly, make amends, and get over it. I'm not interested in any other discussion at this point.
User avatar
SpAce
 
Posts: 2321
Joined: 22 May 2017

Previous

Return to Puzzles