The New Sudoku Players' Forum

[yzfwsf]

Code: Select all

3.......2..7..65.....5...6...3.....8.7....4..89.2.37..........79...1.8....53.4...

[SpAce]

I'm guessing you had something else in mind, but...

Code: Select all

.--------------------.--------------------------.----------------------.
|  3     5       6   |   1489       49     189  | 19     7       2     |
|  124   124     7   |   19         23     6    | 5      8       1349  |
|  124   8       9   |   5          237    27   | 13     6       134   |
:--------------------+--------------------------+----------------------:
| c2456  246     3   | bc16(7)9-4   45679  1579 | 1269   1259    8     |
| C256*  7      A12* |   1689       569    1589 | 4     B12359*  13569 |
|  8     9     ab14  |   2       ab(4)56   3    | 7      15      156   |
:--------------------+--------------------------+----------------------:
| c1246  12346   8   |  c69       bc2569  b259  | 1236  b12345   7     |
|  9     2346  ab24  | bc67         1     b257* | 8     b2345    356   |
|  7     126     5   |   3          8      4    | 1269   129     169   |
'--------------------'--------------------------'----------------------'

Double-Kraken 2R5 & 8N6

Code: Select all

A (2)r5c3 - (2=4)r8c3 - r6c3 = (4)r6c5
  ||      /
  ||     (_________________________ (2)r8c6
  ||                                ||
B (2-3)r5c8 = (34-5)r78c8 = r7c56 - (5)r8c6
  ||                            ___ ||
  ||                           (    (7)r8c6
  ||                            \
C (25-6)r54c1 = r7c1 - r7c45 = (6-7)r8c4 = (7)r4c4

=> -4 r4c4; btte

11x11 TM: Show

Code: Select all

 4r6c5 4r6c3
       4r8c3 2r8c3
 7r4c4             7r8c4
             2r8c6 7r8c6 5r8c6
                         5r7c56 5r7c8
                                4r7c8 4r8c8
                                3r7c8 3r8c8 3r5c8
             2r5c3                          2r5c8 2r5c1
                                                  5r5c1 5r4c1
                                                  6r5c1 6r4c1 6r7c1
                   6r8c4                                      6r7c45
--------------------------------------------------------------------
-4r4c4

--
Edit. Corrected a typo in the C branch: r7c56 -> r7c45.

[eleven]

Needed 2 steps:

Code: Select all

 *--------------------------------------------------------------------------*
 |  3      5       6    |  1489   b49      189    | c19     7       2       |
 | e124   e124     7    | d19      23      6      |  5      8       1349    |
 | f124    8       9    |  5       237     27     | c13     6       134     |
 |----------------------+-------------------------+-------------------------|
 |  256-4  246     3    |  14679   45679   1579   |  1269   1259    8       |
 |  256    7       12   |  1689    569     1589   |  4      12359   13569   |
 |  8      9      a14   |  2      b456     3      |  7      15      156     |
 |----------------------+-------------------------+-------------------------|
 | g1246  h12346   8    |  69      2569    259    | g1236  h12345   7       |
 |  9      2346    2-4  |  67      1       257    |  8      2345    356     |
 |  7      126     5    |  3       8       4      |  1269   129     169     |
 *--------------------------------------------------------------------------*

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

Code: Select all

 *-----------------------------------------------------------------*
 |  3     5      6  |  1489   49     189   | a19     7      2      |
 |  124   124    7  | b19     23     6     |  5      8     b1349   |
 |  124   8      9  |  5      237    27    | a13     6      134    |
 |------------------+----------------------+-----------------------|
 |  256   26     3  |  147    47     17    |  269    259    8      |
 |  256   7      1  |  689    569    589   |  4      235    356    |
 |  8     9      4  |  2      56     3     |  7      15     156    |
 |------------------+----------------------+-----------------------|
 |  14-6  134-6  8  | c69     259-6  259   | a136    1345   7      |
 |  9     346    2  |  67     1      57    |  8      345    356    |
 |  7     16     5  |  3      8      4     |  1269   129    169    |
 *-----------------------------------------------------------------*

(6=139)r731c7 - r2c9 = r2c4 - (9=6)r7c4 => -6r7c125, btte

[SpAce]

Hi everyone who's interested in notational details, and especially Steve since this is related to a very old discussion of ours. I'll use eleven's chain as an example because it has something I tried to suggest back then. In short, my quest was to find a linear notation that would allow to write a bit more complicated or explicit branches than split-nodes, without resorting to memory. Even better if it were a valid AIC, though I didn't think it was mandatory (now I'd strongly prefer it).

My original suggestions were understandably pretty terrible, since I was a complete newbie. Once I realized their failures, thanks to Steve's good arguments, I promptly buried the idea. However, now that I hopefully understand things a little bit better, I think I was onto something after all. With a better implementation it might have actually worked. As eleven's example shows, it can be very intuitive and sometimes (like here) quite likely more readable than any alternative. That's why I still think it's worth pursuing.

That said, even with eleven's better implementation the node in question is not a valid AIC node, or rather, its links aren't valid:

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

It's definitely more correct than my ancient suggestions, because it does have alternating links around it and () instead of [] as the outer brackets. It thus looks more like an AIC node but isn't, which some might think is even worse. Yet I'm not here to criticize but to save it, because it would salvage my original idea too. It just needs to be made either correct or a known shortcut first, since I'm utterly incapable of writing incorrect AICs despite some people having the audacity to suggest otherwise

Well, that's not quite true, since I recently did just that very knowingly, and incidentally the error was exactly the same as here. It's not an actual error if you know what you're doing, is it? I'm suggesting the same fix here. The nice thing is, once known and accepted, it might be just assumed instead of written explicitly unless there's a real chance of confusion. With that amendment, eleven's chain can be considered a valid AIC. Otherwise not.

PART 1. WHY IS IT NOT A VALID AIC?

Let's see. If we forget the internal details, eleven's chain has a normal split-node situation:

- (a|b) = (c & d) - (e|f) =

That, of course, is valid with perfectly alternating links and everything. It's one of the things I screwed up in most of my original suggestions, because I didn't see my "branch container" as a node per se, so the links around it weren't necessarily alternating. Anyway, the real question here is whether the middle node is still valid if d is replaced with a nested chain of the form [g - h = i]:

- (a|b) = (c & [g - h = i]) - (e|f) =

Again, that is written perfectly correctly as far as nested chain syntax goes. Does the logic work, though? That's the real question. It's easiest to work out if we isolate the right side branch:

- b = [g - h = i] - f =

Is that logically and functionally equivalent to what was probably intended, i.e. this:

- b = g - h = i - f =

? It's tempting to see it that way, isn't it? Yet the answer is NO. In the first form the nested chain is a single boolean node in the outer chain. Thus the outer links are attached to the chain node itself, and its truth value, instead of its internal nodes. Does that make a difference? It sure does.

The first version simply doesn't work, because a nested chain of that form (different link types at the ends) can't generally link in any meaningful way, thus causing a discontinuity in the outer chain. In particular, it can't normally weak link to anything because it can't eliminate anything external. The only way a chain of that form (nested or top level) can eliminate anything by itself is if (g) and (i) see each other, in which case (g) gets eliminated. Otherwise it would need to know that either (g) is considered true or (i) false, which it doesn't because that information is not transmitted by the links. The same is true with the actual example:

9r2c4 = [1r2c4 - r2c12 = 1r3c1] - 1r7c1

The outer strong link is meaningless because in this case the nested chain is already true in the grid. In some other situation it might work, but it wouldn't matter. A bigger problem is that the outer weak link doesn't work because the chain couldn't eliminate 1r7c1 without knowing that 1r2c4 (and consequently 1r3c1) is considered true (and it doesn't). That's always the case with chains of this form.

Similarly, though a bit less intuitively, a true 1r7c1 couldn't make the chain false even though it would bite one of its end points. The chain would still be valid and true, only with a known truth value (false) at one of its nodes. The chain itself is not in conflict with 1r7c1. A conflict would mean that both couldn't true without causing a contradiction, and that's not the case here. It would only happen if the chain somehow forced 1r3c1 to be true. In that case a true 1r7c1 would cause a conflict, and either we'd have a contradiction or either the chain or 1r7c1 would have to be false.

PART 2. HOW TO MAKE IT CORRECT?

I'm glad you asked. Indeed there's a simple way to make it work. It's the same I've suggested elsewhere for writing reversed contradiction chains that force one end to be true. In this case it would look like this:

9r2c4 = [(!=1)r2c4 - r2c12 = 1r3c1] - 1r7c1

That's it. Adding a strongly linked contradiction '!' to the other end of the nested chain makes it a normal AIC, which both works and is easy to understand. If the chain node is true, at least one of its internal end points must be true as well, which gives it weak link capabilities. Since one end is a contradiction, a known false, the other (1r3c1) must be true (as well as any other right side nodes). That simplifies things a lot, because the chain inherits all weak links 1r3c1 has.

That way the chain node can have a valid weak link to 1r7c1, because we now know that if the chain is true, then 1r3c1 is true as well. That was not the case with the original version. It also works the other way. If 1r7c1 is true, then 1r3c1 is false, and so is the chain because it would otherwise cause a contradiction.

The strong link now works too. If 9r2c4 is false, it makes the first link and the rest of the nested chain true, because having neither 1 nor 9 in r2c4 would be a contradiction. Similarly, if the nested chain is false, then 9r2c4 must be true, because there can't be a contradiction in r2c4 in that case.

PART 3. HOW SHOULD WE ACTUALLY WRITE IT?

Well, if one wants to be fully correct, my version above should work, unless I've seriously overlooked something. In practice, I would accept and possibly even write eleven's version too. I think it's the most readable and intuitively understandable form. For me the important part is to understand that it's not strictly speaking correct as written. As long as that's known and it's used and interpreted with the assumption that it implies the strongly linked contradiction, I'm fine with the abbreviated form as a prettier shortcut.

In fact, I recently used it myself with a nested chain that also starts with a weak link. The contradiction is shown in the hidden explicit version, though, so it was a consciously made error.

4. SHOULD WE USE IT IN THE FIRST PLACE?

Well, since I've wanted something like that since the start of my branching days, I'm of course all for accepting it as a possibility, with the mentioned caveats. Personally I don't have nearly as much incentive to use that style as in the early days, but it would still be a nice addition to the notational tool box.

Like I originally argued, there are middling cases of branching when a net diagram would be an overkill, but neither split-nodes nor normal nested chains nor memory chains would work optimally as a linear notation. This might be a decent compromise in those situations.

Problem is, if this style starts to proliferate, I'm sure we will eventually see some pretty horrible versions that have no resemblance whatsoever to valid AICs. Maybe that's ok. See below.

5. A QUOTE FROM THE LINKED DISCUSSION...

I also happen to think that "higher standards" are sometimes just artificial rules and constraints for bored people to keep things interesting for themselves. They may have nothing to do with practical reasons. Elegance is always preferable, but it's also subjective, and sometimes a hindrance.

Well... I think I can confirm at this point that I was quite right back then

[eleven]

You are right, that i should not have used the square brackets, which have the meaning to be nested AIC's.
As obvious, i wanted to translate this simple implication to an AIC:
49r61c5 => (-9r1c7 -> 13r13c7) & (-9r2c4 -> 1r2c4 -> -r2c12 -> 1r3c1) => (1|3)r7c17
But i don't like the expression with the contradiction sign (!), which for me makes it harder to read than it is.
So why not just use other brackets () or {} ?

[SteveG48]

Hi everyone who's interested in notational details, and especially Steve since this is related to a very old discussion of ours. I'll use eleven's chain as an example because it has something I tried to suggest back then.

First, thanks to Eleven for a very pretty solution, regardless of notational imperfection. Then to SpAce for a great discussion.

Without repeating everything, I like SpAce's proposed notation, with the usual caveat that it would be confusing to people just joining the group. I would want to include something for them warning of the added complexity. It would be nice to be able to direct them to a full discussion of the notation we use, identifying both the commonplace and more complex features that we use.

The reason that I like the proposal is that it gives us a proper way to embed a chain in an AIC while preserving the AIC as a proper one. How often we would actually use it remains to be seen. That said, I don't believe that I would use it in this instance. Eleven's chain was:

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

I would simply modify it just a touch to:

4r6c3 = 4r6c5 - (4)r1c5 = (19)b2p24 - (9)r1c7|1r2c12 = (13)r13c7&1r3c1 - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r7c3,r4c1

I think that follows the rules, albeit with a slightly longer chain.

[SpAce]

You are right, that i should not have used the square brackets, which have the meaning to be nested AIC's.

I thought it was really good you used them, because it is a nested AIC, and I don't see how else it could be interpreted no matter how you wrote it (even as an embedded implication chain). In particular, I don't see how a different choice of brackets would have changed anything. The only problem is that it's a totally useless nested AIC unless tweaked or interpreted the way I mentioned. However, since that tweak could be assumed to be implied without introducing practical ambiguity (I think), I don't see much of a problem writing it exactly like you did.

In fact, I think your way of writing it is probably the best for most practical purposes, unless one wants to be strictly correct, in which case it's mine. Those two are the only reasonable options, I think, and anything else would just make it worse. As far as I'm concerned, your way could be accepted as an idiom despite its literal incorrectness. What makes it acceptable to me is that it's very easy to understand and to convert into its correct form (for those who know it), and it has no other obvious interpretations that would make sense.

As I said, I've used the same shortcut myself (in a bit different context), fully knowing its literal incorrectness. I'd be a hypocrite to say it couldn't be used for this (or otherwise both should be banned). I think it's an example where demanding strict correctness would get in the way of readability, or at least prettiness. I bet that's true for most casual readers because they'd never even realize it has any errors. For a chaining expert who expects strict correctness the opposite could be true, however. It might also be a bit confusing for someone who wants to learn to write chains correctly. Other than that, it's equally readable and writable for both those who know what they're doing and for those who don't. The former can easily do a mental conversion into the correct form, and the latter never see any problem in the first place.

As obvious, i wanted to translate this simple implication to an AIC:
49r61c5 => (-9r1c7 -> 13r13c7) & (-9r2c4 -> 1r2c4 -> -r2c12 -> 1r3c1) => (1|3)r7c17

Yes, it was obvious. That's why I like the idea in the first place. It's very intuitive and easy to read.

But i don't like the expression with the contradiction sign (!), which for me makes it harder to read than it is.

It surely makes it uglier, but as far as I know, it's not just the simplest but the only way to make it correct without using completely different branching tricks. You can't have both, so which one do you value more? Or do you really have another way to make it correct?

If you don't like the '!' symbol, I'm open for better suggestions. I do think we need a symbol for the FALSE literal, which can be used to represent contradictions and DPs (the same thing). I hate every piece of text that is mixed up with an otherwise symbolic notation, especially if it's an awfully long word like "contradiction". I can't really think of anything better than '!' to replace that. It has no other established meanings (that I know) in this context, it's found on any standard keyboard, and its purpose should be pretty intuitive to understand.

The only major drawback I see is that '!' looks a bit too much like '1'. To make it stand out more, you could double '!!' or triple '!!!' it, or enclose it in brackets (!) or [!]. I think a mere doubling would work nicely because I don't see any valid use for a combination '11' without a comma between them. (Also, FALSE is FALSE no matter how many times you AND it.)

Can you suggest anything better? Many symbols have established meanings already, and can't be as intuitively associated with a contradiction anyway. The only alternative that comes to mind immediately is 'F'. The other obvious choice, '0', is not good if we need a matching symbol for TRUE. In fact, I think it might be useful as well. What would be a good symbol for that, except the obvious 'T'?

(Btw, if someone wants to be really explicit, I wouldn't really mind using the actual words TRUE and FALSE for this. They're not too long, and everyone would understand them.)

So why not just use other brackets () or {} ?

How would they help? What special meaning are you suggesting for them that would make the chain any more correct? Would learning and remembering that special meaning be easier than understanding the relatively intuitive and more generally applicable contradiction option, which follows perfectly normal AIC rules? For someone who knows AICs, the only thing to learn in my approach is that '!' is a symbol for the boolean literal FALSE, but even that could be written out. I don't understand what you're after.

As far as I know, there's no difference in how different kinds of brackets work in an AIC, and I don't think there should be. That would be a real complication to remember. The [] has an established association with nested chains to make them more recognizable, but they would work the same way if the normal () or even {} were used. Thus, it's just a convention. The {} are not generally used in an AIC context, unless one wants to embed an Almost-Alien-Fish (i.e. a generic set of truths and links) but I've never seen (i.e. done) that. The {} are also used in Denis' chains, which makes me think they should probably be avoided in AICs to avoid any confusion.

[Cenoman]

Just a small contribution.

4r6c3 = 4r6c5 - (4)r1c5 = (19)b2p24 - (9)r1c7|1r2c12 = (13)r13c7&1r3c1 - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4r8c3,r4c1

From this chain, it is easy to draw a 9x9 BTM of eleven's solution:

Code: Select all

4r6c3 4r6c5
      4r1c5 9r1c5
            9r2c4  1r2c4
            9r1c7         1r1c7
                          1r3c7 3r3c7
                   1r2c12             1r3c1
                          1r7c7       1r7c1 1r7c2 1r7c8
                                3r7c7       3r7c2 3r7c8
4r7c1                                       4r7c2 4r7c8
-------------------------------------------------------

=> -4r8c3,r4c1
Note: a typo in the original chain has been copied-pasted in every following posts

[SpAce]

As obvious, i wanted to translate this simple implication to an AIC:
49r61c5 => (-9r1c7 -> 13r13c7) & (-9r2c4 -> 1r2c4 -> -r2c12 -> 1r3c1) => (1|3)r7c17

I don't know about the conventions of writing and interpreting implication chains, but if interpreted as strict boolean logic, that's actually more incorrect than your AIC. In fact, it has two nested chains instead of just one, and they both need the same trick I used for the AIC to make the logic actually flow. You can't escape the problem so easily by simply switching notations.

I'm no implication chain expert, but here's how I think it should be written as correct boolean logic:

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

Or its reversal:

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

That can't be directly translated into an AIC because the node containing the two nested chains would have weak links on both sides. That's not a problem for the implication chain.

This chain has a direct mapping with your AIC+my tweak:

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

Or its reversal:

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

The AIC:

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

[SpAce]

Hi Steve,

Then to SpAce for a great discussion.

Well, thank you for the original one! It played a big part in my development, as it opened my eyes to many things I hadn't even considered. You might be to blame for my obsession with correctness

Without repeating everything, I like SpAce's proposed notation,

Glad to hear that. It's open for improvement, so I take suggestions too. As I said in a previous post, we need standard literal symbols for at least FALSE but possibly TRUE as well, unless they're used as words or letters (which are also acceptable options to me). If both are given symbols, they should preferably match somewhat intuitively. I've suggested '!' for FALSE but I haven't considered what it could be for TRUE. I'm not sure if the latter is even needed except for balance; at least I haven't yet figured out a use case for it.

with the usual caveat that it would be confusing to people just joining the group.

Quite a lot of things are already confusing to newbies, starting with Eureka itself I'm not sure how much confusion this particular feature would add, though. It might even have the opposite effect. Like I originally argued, writing and reading branching chains written in that style would probably be quite intuitive for a newcomer (as it was for me, as compared to regular split nodes or normal nested chains, for example). Btw, I wrote this in that same discussion, when my first encounters with Eureka were fresh in my mind:

Also, if you think about basic Eureka itself, how easy is it for a casual reader to understand its intent? We're all used to it so it seems natural to us, but truth be told, it's awful for a newcomer! It's hard to imagine anything more ridiculous than using "=" to mean OR. It's about as far from intuitive as can be. Its only defense is that it's well defined, so it's learnable as long as you find the documentation.

But I digress Besides, even though I still agree with the above, I don't really have better alternatives in mind. Denis' notation is an option that doesn't abuse '=', but from my point of view it doesn't have many other benefits over Eureka (while the opposite is true in several ways).

I would want to include something for them warning of the added complexity.

Do you mean adding something to the syntax, or as an external text-based warning when that feature is used? I'm fine with the latter, of course, but I wouldn't want to clutter the chain itself with anything. It doesn't really need that, as it's actually using perfectly standard features of the language without adding any new syntax rules. Only the combination is new. It's not like a memory chain which actually needs special markers, not only for their primary purpose but to warn that it's not a normal AIC. This is a valid AIC, unless the abbreviated form is used.

All it really does is that it combines split nodes and nested chains in a way that might have never been done before, at least correctly. Even then, it's just an advanced application of existing syntax rules. Everything it uses has been around for a long time, except for the contradiction symbol, and its special use case to make an otherwise useless piece of chain linkable. Btw, I should thank you for inspiring that invention. It all started when you recently mentioned your desire to replace a long AIC with a contradiction chain. It made me think about those kinds of unconventional weapons more.

It would be nice to be able to direct them to a full discussion of the notation we use, identifying both the commonplace and more complex features that we use.

Yes, a modern Eureka language reference would be nice. I could consider writing at least some parts of it.

The reason that I like the proposal is that it gives us a proper way to embed a chain in an AIC while preserving the AIC as a proper one.

Yes, though we've of course had that for a long time with normal nested AICs, like Cenoman's fine example here. The difference is that those are proper almost-AICs to begin with, so they're easy to embed in other chains because they have very distinct strong and weak links.

The actually new feature is the ability to embed almost any chain fragment as a linkable node. That hasn't been possible before. That said, this is a brand new feature for me too, so I can't really make predictions about its general applicability and usefulness.

How often we would actually use it remains to be seen.

Indeed. I'll be looking out for opportunities to test this feature, but I'm not sure how often it would be my primary choice even if applicable. I'd imagine the clearest use case would be when a split-node chain would need redundant balancing acts just to keep the branches in sync. Even though those needs can be minimized by choosing different routes and combos, it can still be unavoidable, and I hate when that happens. This feature might help then by allowing unbalanced branches. Sometimes it might also be the most readable option, especially if the branches travel very far away from each other, which makes them hard to track simultaneously. We'll see.

[SteveG48]

Do you mean adding something to the syntax, or as an external text-based warning when that feature is used? I'm fine with the latter, of course, but I wouldn't want to clutter the chain itself with anything.

Agreed. I meant external text.

[eleven]

As obvious, i wanted to translate this simple implication to an AIC:
49r61c5 => (-9r1c7 -> 13r13c7) & (-9r2c4 -> 1r2c4 -> -r2c12 -> 1r3c1) => -(1|3)r7c17

I don't know about the conventions of writing and interpreting implication chains, but if interpreted as strict boolean logic, that's actually more incorrect than your AIC. In fact, it has two nested chains instead of just one, and they both need the same trick I used for the AIC to make the logic actually flow. You can't escape the problem so easily by simply switching notations.

Crazy, from your complex AIC thinking you are getting problems with simple implication chains.
If you want it in boolean terms, it does not become simpler, but ok. Instead of x => y you write (!x | y).

Let's use shortcuts a-h:
a => (b=>c) & (d=>e=>f=>g) => h
This becomes
(!a | b&d) & ((!b|c) & ((!d|e) & (!e|f) & (!f|g)) & (!(c&g) | h)
Either a is false, or
b = true and d= true,
!b = false, c =true and
!d = false, e is true, !e=false, f=true, !f=false, g=true,
c&g=true, !(c&g) = false, h is true.
So we have !a | h, as expected.

[SpAce]

You are right, that i should not have used the square brackets, which have the meaning to be nested AIC's.
...
But i don't like the expression with the contradiction sign (!), which for me makes it harder to read than it is.
So why not just use other brackets () or {} ?

You haven't answered my question about what you actually meant by other brackets. The only interpretation I see that might make sense is if we dedicated one type of brackets ( {} is the only available possibility) to mean that the contents need some kind of preprocessing before the chain validates as a pure Eureka-based AIC. It could be used to mark any piece of syntax that is not standard Eureka but could be translated into that with known rules.

With that generalized idea, it wouldn't conflict with (the hypothesized use of) embedded Alien Fishes for which {} is already a part of the syntax. It could also be extended to surround UFG fishes similarly, which might satisfy those who've complained that they're otherwise confusing when used as nodes.

In other words, with that new syntax element, we could write your chain like this:

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

That should warn the reader that the chain fragment within {} doesn't translate directly into a linkable nested AIC, but there's a known way to expand it into a valid form. With that allowance we could avoid the ugly and possibly more confusing '!' syntax, even though it would always be a correct variant (and the implied effect of the {} preprocessing in this case).

What do you guys think of that?

--

Of course, allowing that syntax would open a can of worms, as it could be used to write the above chain like this:

(4)r6c3 = r6c5 - (4=9)r1c5 - ({(9=1)r1c7 - (1r7c7 | {(1=3)r3c7 - 3r7c7})} | {(9=1)r2c4 - r2c12 = r3c1 - 1r7c1}) = (13-4)r7c28 = (4)r7c1 => -4r8c3,r4c1

...which of course is completely unreadable, even though (or because) the internal logic is shown in much deeper detail. If someone wants that level of detail, a net diagram or a matrix are the only reasonable options. Linear formats have their limits, but, in theory, that would be a valid option to write it. It's an almost direct match with Cenoman's matrix, except for the unfolded r7c28 node.

In a way it might even be simpler to understand and to write for a beginner who doesn't understand complex split-nodes, but for an expert it would be a horror to read. Besides, getting the brackets and the |s and &s right would be challenging for anyone. If I were to write it like that, I'd use memory markers for clarity, even though it's not a memory chain and they're not required to keep it correct:

(4)r6c3 = r6c5 - (4=9*)r1c5 - ({(*9=1^)r1c7 - (^1r7c7% | {(^1=3)r3c7 - 3r7c7%})} || {(*9=1)r2c4 - r2c12 = r3c1 - 1r7c1%}) = (%13-4)r7c28 = (4)r7c1 => -4r8c3,r4c1

That would at least give a fighting chance to follow what's going on, even though it's depicting negative memories which I don't normally allow. Either way, it should match this net diagram (a reversed kraken):

Code: Select all

                                  - (1=3)r3c7 - (3)r7c7
                                 /              ||
(4)r6c3 = r6c5 - (4=9)r1c5 - (9=1)r1c7 -------- (1)r7c7 
                     \                          ||
                     (9=1)r2c4 - r2c12 = r3c1 - (1)r7c1
                                                ||
                                                (13-4)r7c28 = (4)r7c1

Anyway, despite such possibilities for abuse, I think it might be a possible compromise between full correctness and a simple syntax for cases when it might actually improve readability. What do you think?

PS. The one thing it would NOT allow is this:

4r6c3 = 49c61 - ({(9=13)r13c7} | {(9=1)r2c4 - r2c12 = 1r3c1}) - (1|3)r7c17 = (13-4)r7c28 = 4r7c1 => -4 r8c3,r4c1

Alternating links around any node are still a must, including the top-level split node itself. Even though the above may seem like a valid variant because all internal links seem to alternate, including the edge links if you only look at the small nodes, the outer links of the big split-node do not (both weak). While that would still yield correct logic with some interpretation, it doesn't have a direct AIC translation, so it must be banned.

(I actually wrote most of my ancient suggestions like that, and it took me a while to understand why Steve didn't accept my attempts to defend them. We had different perspectives, as he was expecting a valid AIC node, while my idea was a much less restricted branch container. I guess our views are more aligned this time.)

[SpAce]

Crazy, from your complex AIC thinking you are getting problems with simple implication chains.

Might well be. Like I said, I don't claim to be an expert with them. It's completely irrelevant to the main point of this discussion anyway, which is about AICs.

[eleven]

You haven't answered my question about what you actually meant by other brackets.

Since you strictly argued against the proposal to use other brackets, i didn't want to discuss it anymore. I don't see it as my job to expand that notation.

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.