The New Sudoku Players' Forum

[SpAce]

It sure does if you read it as intended.

I don't doubt that. The problem is whether others will understand your intent. I didn't.

That's fair. Like I've said many times, intuitiveness is subjective.

Beyond that, though, the idea is for the notation to be well enough defined so that intent is always understood.

Yes indeed. Where is the standard Eureka-like net notation defined? I'd be very interested in seeing that! You simply can't express all nets as split-node chains, so I'd really like a standardized notation for more complex AIC-like nets as well (and also non-AIC-like nets, while we're at it). I'd also like the ability to express even those simpler split-node chains more explicitly, which I attempted to do here. If my style is wrong, can you show me a better alternative?

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.

Your intent corresponds exactly with my chain.

So I didn't get it all wrong then? I never said your chain was incorrect! I just said it wasn't as explicit as I would like. My whole point here is to find ways to rewrite it just as correctly but with more explicit information. Can you show me how?

Now let's look at your bracketed term, [[(2=8)r4c2] | [(5)r2c1 = (5)r4c1]] . The problem with viewing this as a container for parallel chains is that we need standardised notation to make intent clear.

I whole-heartedly agree with that. Again, do we have a standardized notation for nets that could be expressed as bidirectional AIC-like chains (meaning that the end-nodes have an OR-relationship and can eliminate something, while the middle is a branching split-join chain) but not with just simple split-nodes? If not, then it's guaranteed that everyone will come up with their own solutions that appear intuitive to them. That's not necessarily helpful for the community. I also don't understand why AICs should have such a strict definition that would forbid expressing such AIC-like nets if it could be reasonably done.

In standard boolean (and algebraic) notation, brackets and parentheses are used to set order of evaluation. Here, the term (2=8)r4c2 is in brackets and must be evaluated first. It always evaluates true. Likewise (5)r2c1 = (5)r4c1. Then we evaluate the | (OR). With true on both sides, it always evaluates true. As a standard boolean expression, it simply doesn't convey your intent.

You may be right, but I think it's partly a problem with Eureka. One intrinsic problem of Eureka is that it's a hybrid of forcing chains and boolean logic. As such it does neither very well. I bet the instinct of most newcomers is to see it through the forcing-chain lens, which has the potential to make the other perspective easily incorrect. That's why I'm not sure which one of us is wrong here, because it's not exactly easy for me to translate the whole thing into logic ports. If you can easily do that and show my notation is illogical, I'll buy your argument. Even then, I'd like to see a good alternative to my notation that would show the nodes and links more explicitly than yours. That's what I'm after.

[SteveG48]

Yes indeed. Where is the standard Eureka-like net notation defined? I'd be very interested in seeing that! You simply can't express all nets as split-node chains, so I'd really like a standardized notation for more complex AIC-like nets as well (and also non-AIC-like nets, while we're at it). I'd also like the ability to express even those simpler split-node chains more explicitly, which I attempted to do here. If my style is wrong, can you show me a better alternative?

No, I can't. I don't know of a standard Eureka-like network notation, and it is a problem. It's not unusual for me to abandon a solution that's perfectly good in terms of logic, but which I don't want to post here because I don't know of any way to express it in notation that I find to be satisfying. That wasn't so in my early days here. Several people (I won't name them for fear of forgetting someone) have taught me a higher standard (which I sometimes fail to live up to). However, diagrams like the one you drew are always a way around this.

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.

Just so.

So I didn't get it all wrong then?

Not at all .

I never said your chain was incorrect! I just said it wasn't as explicit as I would like. My whole point here is to find ways to rewrite it just as correctly but with more explicit information. Can you show me how?

Hopefully the discussion to date helps. Basically, even in Eureka standard Boolean notation works, except that "=" and "-" have the specialized Sudoku meanings for strong and weak links. "&" and "|" have the standard meanings.

I also don't understand why AICs should have such a strict definition that would forbid expressing such AIC-like nets if it could be reasonably done.

Let's be clear on that. The rules I quoted above from DPB assure that an AIC is bi-directional. Net-like Eureka chains that are not bi-directional are often posted here using various notations (usually involving asterisks). The important thing is that such chains always include something like the asterisk to clearly indicate a departure from strict Boolean notation.

If you can easily do that and show my notation is illogical, I'll buy your argument. Even then, I'd like to see a good alternative to my notation that would show the nodes and links more explicitly than yours. That's what I'm after.

I didn't mean to suggest that your notation is illogical. What I did say is that it doesn't follow standard Boolean notation, and doesn't give the reader any warning of that- such as by using asterisks or other symbols that will alert the reader that something interesting is going on. Without that, your intent may not be understood.

[SpAce]

I don't know of a standard Eureka-like network notation, and it is a problem.

Okay. Could we figure out a process to get one?

It's not unusual for me to abandon a solution that's perfectly good in terms of logic, but which I don't want to post here because I don't know of any way to express it in notation that I find to be satisfying. That wasn't so in my early days here. Several people (I won't name them for fear of forgetting someone) have taught me a higher standard (which I sometimes fail to live up to).

I understand. 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.

However, diagrams like the one you drew are always a way around this.

Maybe, but they're not optimal as the only solution. A linear notation that would depict parallelism would be preferable, at least as an option.

The rules I quoted above from DPB assure that an AIC is bi-directional.

And why exactly is that all-important, except as an artificial rule and part of the elegance of AICs? Somehow that reasoning has escaped me, even though I think bidirectionality is a nice feature (for double-checking, if nothing else) and makes AICs more pattern-like. Besides, my nets were also bidirectional if read as intended, even though they didn't exactly follow other AIC rules. From that we can conclude that bidirectionality alone doesn't guarantee AIC-compliance.

Net-like Eureka chains that are not bi-directional are often posted here using various notations (usually involving asterisks). The important thing is that such chains always include something like the asterisk to clearly indicate a departure from strict Boolean notation.

I've thought that asterisks are only used to indicate nodes whose values are reused later in an otherwise linear chain ("memory chain"). That style does kill bidirectionality. Explicit split-joining does not, necessarily, but it requires its own notation style. Below is an example where I'd use an asterisk:

Kraken Row (6)r9.

Code: Select all

(6-8)r9c3 = r9c45 - r6c45 [UR(58)r69c45] = r6c3 - (6|8=37)r37c3 - (3=7)r7c1 - (7=6)r5c1 - r5c4
||
(6)r9c4 - r5c4
=> -6 r5c4; stte


http://forum.enjoysudoku.com/january-26-2018-t34414.html#p263205

I think the first forcing chain needs an asterisk:

(6*-8)r9c3 = r9c45 - r6c45 [UR(58)r69c45] = r6c3 - (6*|8=37)r37c3 - (3=7)r7c1 - (7=6)r5c1 - r5c4

That's an honest forcing net (kraken) anyway so there's no need for bidirectionality. If written as an AIC-like net, however, I think it can be made bidirectional (and without using asterisks):

(6)r9c4 = [[(6)r9c3] & [(58)r9c45 - (8)r6c45 {UR(58):r69c45} = (8)r6c3]] - (6|8=7)r3c3 - r7c3 = r7c1 - (7=6)r5c1

...or something like that (I can't write complex nodes properly so at least the UR-part is probably wrong).

I didn't mean to suggest that your notation is illogical. What I did say is that it doesn't follow standard Boolean notation,

You mean the possibly incorrect use of brackets? Or something besides that?

and doesn't give the reader any warning of that- such as by using asterisks or other symbols that will alert the reader that something interesting is going on. Without that, your intent may not be understood.

Well, the square brackets were meant to indicate that something "interesting" was going on, but I understand if it wasn't obvious. I don't see where and why I'd use an asterisk in those chains, considering my understanding of its usual meaning. The brackets were meant to indicate and separate two parallel chains where the preceding and following links affected/were affected by both equally. I understand they're not an optimal solution and am open to suggestions.

[200e200w]

Hi, SpAce!
I agree that my chain from Jan 26, 2018 puzzle:

Code: Select all

(6*-8)r9c3 = r9c45 - r6c45 [UR(58)r69c45] = r6c3 - (6*|8=37)r37c3 - (3=7)r7c1 - (7=6)r5c1 - r5c4
||
(6)r9c4 - r5c4
=> -6 r5c4; stte

needs an asterisk. I added it to the chain in that sudoku.

200e200w

[SteveG48]

And why exactly is that all-important, except as an artificial rule and part of the elegance of AICs? Somehow that reasoning has escaped me, even though I think bidirectionality is a nice feature (for double-checking, if nothing else) and makes AICs more pattern-like.

It's not all-important. I try to do it that way as a matter of personal preference. What is all important is standard notation that leaves no doubt about intent.

Net-like Eureka chains that are not bi-directional are often posted here using various notations (usually involving asterisks). The important thing is that such chains always include something like the asterisk to clearly indicate a departure from strict Boolean notation.

I've thought that asterisks are only used to indicate nodes whose values are reused later in an otherwise linear chain ("memory chain"). [/quote]

Agreed. A memory chain is one form of networking. Asterisks make it work in Eureka.

I didn't mean to suggest that your notation is illogical. What I did say is that it doesn't follow standard Boolean notation,...

You mean the possibly incorrect use of brackets? Or something besides that?

Incorrect use of brackets is part of it, but the question is how do you use standard notation properly to convey your intent unambiguously? If you work on your chain to meet that end, I think you'll wind up with the same chain that I wrote, or very similar.

and doesn't give the reader any warning of that- such as by using asterisks or other symbols that will alert the reader that something interesting is going on. Without that, your intent may not be understood.

Well, the square brackets were meant to indicate that something "interesting" was going on, but I understand if it wasn't obvious. I don't see where and why I'd use an asterisk in those chains, considering my understanding of its usual meaning. The brackets were meant to indicate and separate two parallel chains where the preceding and following links affected/were affected by both equally. I understand they're not an optimal solution and am open to suggestions.

Correct. Asterisks are not the way to go in this instance, imo. My suggestion is the way I did it . An alternate is to write the parallel chains as separate chains to establish links between their end points. Then use those links in another chain to establish your final result. However, that alternative would be more appropriate, imo, for more complex parallel chains. This puzzle is pretty simple.

[SpAce]

What is all important is standard notation that leaves no doubt about intent.

Yep. Unfortunately we don't have that for more complex nets. That's part of my point.

Incorrect use of brackets is part of it, but the question is how do you use standard notation properly to convey your intent unambiguously? If you work on your chain to meet that end, I think you'll wind up with the same chain that I wrote, or very similar.

In this simple case it's possible but your assumption misses the reasons why I'd personally prefer a more explicit notation: unambiguity (while also subjective) is my goal too and I prefer that over brevity. From my point of view your link (3=25)r2c23 - (5|2)r2c1,r4c2 is ambiguous and unintuitive (like many ALS jumps in general). I can nowadays read those pretty fluently, but it's not that long ago I had to work more to understand what was going on. I may have gained a few levels since I got involved here but I still haven't forgotten what it's like to be a complete newbie. Perhaps I'm just dumber than average, but the other possibility is that there may be people who have a much harder time grasping very concise notations that skip steps experts consider obvious. That's my point.

Also, I'd still like someone to answer my theoretical question. How would you write your chain if there were (somehow) a 5 in r4c2? Your chain would still work for the same effect but the notation would now be logically incorrect, if I understand anything from David's writings.

An alternate is to write the parallel chains as separate chains to establish links between their end points. Then use those links in another chain to establish your final result. However, that alternative would be more appropriate, imo, for more complex parallel chains. This puzzle is pretty simple.

That's one option but it's not much different from the pseudo-graphical representation seen earlier, only less intuitive and more difficult to follow. Between those two its main benefit is that it's easier to write and works without fixed fonts. I think both are an overkill when the net is pretty simple (but not split-node simple) and could be easily written on one line. Especially for those intermediate cases I'd like to have a standard notation. I've understood that brackets were used for that purpose in the old Nice Loop world. See "Multiple inferences" here:

https://www.paulspages.co.uk/sudokuxp/howtosolve/niceloops.htm#complexloops

[eleven]

To get away from formulation details. How do you think about this ?
In "200e200w's Nightmare #2" there is an interesting "pattern".

Code: Select all

*---------------------------------------------------------------*
 |  489   2     49     |  7    168    68   |  5     3     19     |
 |  89    16    5      |  18   3      4    |  7     2     169    |
 |  36    136   7      |  9    2      5    |  8     16    4      |
 |---------------------+-------------------+---------------------|
 | #49   #367   8      |  2    469    1    | #34   #467   5      |
 |  2     5    #46     |  3    468    7    |  14    9     168    |
 |  1     367   3469   |  5    4689   68   |  2     467   3678   |
 |---------------------+-------------------+---------------------|
 |  5     9     1      |  4    7      3    |  6     8     2      |
 |  37    8     2      |  6    5      9    |  134   147   137    |
 |  367   4    a36     |  18   18     2    |  9     5    a37     |
 *---------------------------------------------------------------*

You can see easiliy, that a 4r4c1 implies 3r4c7, 6r5c3, 7r4c2, 6r4c8.
This gives strong links vom 9r4c1 to those four.
So for a manual player it can be one step: 9r4c1=step=6r4c8.
Why not ?

[SteveG48]

In this simple case it's possible but your assumption misses the reasons why I'd personally prefer a more explicit notation: unambiguity (while also subjective) is my goal too and I prefer that over brevity. From my point of view your link (3=25)r2c23 - (5|2)r2c1,r4c2 is ambiguous and unintuitive (like many ALS jumps in general). I can nowadays read those pretty fluently, but it's not that long ago I had to work more to understand what was going on. I may have gained a few levels since I got involved here but I still haven't forgotten what it's like to be a complete newbie. Perhaps I'm just dumber than average, but the other possibility is that there may be people who have a much harder time grasping very concise notations that skip steps experts consider obvious. That's my point.

You've indicated a couple of times now that you would like my chain to be more explicit and that you find it ambiguous. Sorry, but I can't accept either inexplicit or ambiguous as appropriate. It may not be intuitive- that's subjective- but once you accept the standard rules of Boolean logic and the special Sudoku link definitions, it's both explicit and unambiguous. (Unless I've made a blunder. That's unlikely at this point, as someone would have pointed it out by now.) Please look at it again.

Also, I'd still like someone to answer my theoretical question. How would you write your chain if there were (somehow) a 5 in r4c2? Your chain would still work for the same effect but the notation would now be logically incorrect, if I understand anything from David's writings.

You're correct. In that case I would have to modify it from this:

(4=3)r2c78 - (3=25)r2c23 - (5|2)r2c1,r4c2 = (58)r4c12 - (5|8=4)b6p26 , to this:

(4=3)r2c78 - (3=25)r2c23 - ((5)r2c1)|((2)r4c2) = (58)r4c12 - (5|8=4)b6p26

The change is needed because the assertion - (5|2)r2c1,r4c2 is no longer technically true, since there is a 5 in r4c2. We modify that term to indicate clearly that there is no 5 in r2c1 and no 2 in r4c2. The assertion that there must then be both a 5 and an 8 in r4c12 follows.

An alternate is to write the parallel chains as separate chains to establish links between their end points. Then use those links in another chain to establish your final result. However, that alternative would be more appropriate, imo, for more complex parallel chains. This puzzle is pretty simple......

That's one option but it's not much different from the pseudo-graphical representation seen earlier, only less intuitive and more difficult to follow. Between those two its main benefit is that it's easier to write and works without fixed fonts. I think both are an overkill when the net is pretty simple (but not split-node simple) and could be easily written on one line.

Agreed.

[SteveG48]

To get away from formulation details. How do you think about this ?
In "200e200w's Nightmare #2" there is an interesting "pattern".

Code: Select all

*---------------------------------------------------------------*
 |  489   2     49     |  7    168    68   |  5     3     19     |
 |  89    16    5      |  18   3      4    |  7     2     169    |
 |  36    136   7      |  9    2      5    |  8     16    4      |
 |---------------------+-------------------+---------------------|
 | #49   #367   8      |  2    469    1    | #34   #467   5      |
 |  2     5    #46     |  3    468    7    |  14    9     168    |
 |  1     367   3469   |  5    4689   68   |  2     467   3678   |
 |---------------------+-------------------+---------------------|
 |  5     9     1      |  4    7      3    |  6     8     2      |
 |  37    8     2      |  6    5      9    |  134   147   137    |
 |  367   4    a36     |  18   18     2    |  9     5    a37     |
 *---------------------------------------------------------------*

You can see easiliy, that a 4r4c1 implies 3r4c7, 6r5c3, 7r4c2, 6r4c8.
This gives strong links vom 9r4c1 to those four.
So for a manual player it can be one step: 9r4c1=step=6r4c8.
Why not ?

No reason at all why not. It works.

I'm not sure why you find that particularly interesting, but in light of the long discussion here, I find it interesting because writing a simple AIC to show 9r4c1=6r4c8 would be difficult without making it a memory chain or something that even I would say is non-intuitive. If I had to do it I would write 9r4c1 = (3467)r4c127,r5c3 - (4|7=6)r4c8 and rely on the reader to figure out where all the digits in two houses are. But here I am going back to formulation details. Sorry.

[SpAce]

You've indicated a couple of times now that you would like my chain to be more explicit and that you find it ambiguous.

I never actually said or implied the latter in the true meaning of the word. I understand if you interpreted it that way, though. Sorry about that.

Sorry, but I can't accept either inexplicit or ambiguous as appropriate. It may not be intuitive- that's subjective- but once you accept the standard rules of Boolean logic and the special Sudoku link definitions, it's both explicit and unambiguous.

I accept that it's not ambiguous, especially considering that you would indeed change it if there were a 5 in r4c2. What I really meant was "inexplicit", and I stand by that assessment. I guess we have a different definition of the word, or different standards about it, or you just don't understand what I mean. What I mean by that is that parts of your chain leave quite a bit to the imagination of the reader. That imagining may be easy for an experienced expert but not necessarily so for a beginner. For some reason you seem to completely miss or ignore that point.

(4=3)r2c78 - (3=25)r2c23 - ((5)r2c1)|((2)r4c2) = (58)r4c12 - (5|8=4)b6p26

Thanks. I came up with something like that, too. I'd personally prefer that form in the first place. It's more *explicit* that way It may not be as concise and elegant as the original, but it's easier to read, at least for me.

Now my next question is: what if I wanted to be even more explicit and break the (25)r2c23 into its constituent parts (2)r2c2 and (5)r2c3 to even further clarify the weak link into r4c2? How would you do that? It's a theoretical question at this point -- I'd be quite satisfied with your new chain already, especially with a minor change of ordering:

(4=3)r2c78 - (3=25)r2c23 - ((2)r4c2|(5)r2c1)) = (58)r4c12 - (5|8=4)b6p26

[SteveG48]

I accept that it's not ambiguous, especially considering that you would indeed change it if there were a 5 in r4c2. What I really meant was "inexplicit", and I stand by that assessment. I guess we have a different definition of the word, or different standards about it, or you just don't understand what I mean. What I mean by that is that parts of your chain leave quite a bit to the imagination of the reader. That imagining may be easy for an experienced expert but not necessarily so for a beginner. For some reason you seem to completely miss or ignore that point.

OK, I understand what you mean now. However, rather than saying it leaves a lot to the reader's imagination, I would say that it requires that the reader closely examine the placement of the digits. Unfortunately, that's often the case with even fairly simple nodes/links.

(4=3)r2c78 - (3=25)r2c23 - ((5)r2c1)|((2)r4c2) = (58)r4c12 - (5|8=4)b6p26 ...

Thanks. I came up with something like that, too. I'd personally prefer that form in the first place. It's more *explicit* that way It may not be as concise and elegant as the original, but it's easier to read, at least for me.

Reasonable.

Now my next question is: what if I wanted to be even more explicit and break the (25)r2c23 into its constituent parts (2)r2c2 and (5)r2c3 to even further clarify the weak link into r4c2? How would you do that? It's a theoretical question at this point -- I'd be quite satisfied with your new chain already, especially with a minor change of ordering:

(4=3)r2c78 - (3=25)r2c23 - ((2)r4c2|(5)r2c1)) = (58)r4c12 - (5|8=4)b6p26

(4=3)r2c78 - (3)r2c23 = ((2)r2c2)&((5)r2c3) - ((2)r4c2|(5)r2c1)) = (58)r4c12 - (5|8=4)b6p26
I'd call the highlighted 3 "optional for clarity".

[SpAce]

OK, I understand what you mean now. However, rather than saying it leaves a lot to the reader's imagination, I would say that it requires that the reader closely examine the placement of the digits. Unfortunately, that's often the case with even fairly simple nodes/links.

That's true. I guess it's hardly possible to totally remove that requirement, but I'd like to at least minimize the need. Then again, too much "clarification" can have the opposite effect in the form of clutter. I guess the optimum level of detail depends on the experience level of the reader.

(4=3)r2c78 - (3)r2c23 = ((2)r2c2)&((5)r2c3) - ((2)r4c2|(5)r2c1)) = (58)r4c12 - (5|8=4)b6p26
I'd call the highlighted 3 "optional for clarity".

Excellent! Thanks! Could a complete breakdown look like this:

(4)r2c8 = (83)r2c78 - (3)r2c23 = ((2)r2c2 & (5)r2c3) - ((2)r4c2 | (5)r2c1)) = ((8)r4c2 & (5)r4c1) - (8|5)r4c8 = (34)b6p26 => -4 r6c8

Now that I would call explicit! No, I'm not asking anyone to go into that level of detail or saying that it's even necessarily helpful. As I said above, too much clutter can also be a hindrance. In this case I'd probably prefer your first variant, or perhaps I might even warm up to your original chain.

[SpAce]

To get away from formulation details. How do you think about this ?
In "200e200w's Nightmare #2" there is an interesting "pattern".

Code: Select all

*---------------------------------------------------------------*
 |  489   2     49     |  7    168    68   |  5     3     19     |
 |  89    16    5      |  18   3      4    |  7     2     169    |
 |  36    136   7      |  9    2      5    |  8     16    4      |
 |---------------------+-------------------+---------------------|
 | #49   #367   8      |  2    469    1    | #34   #467   5      |
 |  2     5    #46     |  3    468    7    |  14    9     168    |
 |  1     367   3469   |  5    4689   68   |  2     467   3678   |
 |---------------------+-------------------+---------------------|
 |  5     9     1      |  4    7      3    |  6     8     2      |
 |  37    8     2      |  6    5      9    |  134   147   137    |
 |  367   4    a36     |  18   18     2    |  9     5    a37     |
 *---------------------------------------------------------------*

You can see easiliy, that a 4r4c1 implies 3r4c7, 6r5c3, 7r4c2, 6r4c8.
This gives strong links vom 9r4c1 to those four.
So for a manual player it can be one step: 9r4c1=step=6r4c8.
Why not ?

That might be okay for both human writers and readers, but what if it's a program that wants to output its complete solving logic? How should it write it? I don't think it could easily assume that it's an obvious step for humans. Also, as a human I'd be unhappy if I had to resort to writing it that way, too. That's why I'd like to have some standard way to do it.

I'm not sure why you find that particularly interesting, but in light of the long discussion here, I find it interesting because writing a simple AIC to show 9r4c1=6r4c8 would be difficult without making it a memory chain or something that even I would say is non-intuitive. If I had to do it I would write 9r4c1 = (3467)r4c127,r5c3 - (4|7=6)r4c8 and rely on the reader to figure out where all the digits in two houses are.

I'm glad we can agree that it's not intuitive that way As a fan of explicit things, I'd obviously prefer a memory chain or something else here, even if it's not really Eureka/AIC-compliant. First how I see this graphically:

Code: Select all

(9=4)r4c1 ------------------------------- (4|7=6)r4c8
          | \                          /
          |  (4=3)r4c7                /
          |            \-- (3|6=7)r4c2
          (4=6)r5c3 ---/

As a memory chain:

(9=4*)r4c1 - (r4c7 | r5c3) = ((3)r4c7 & (6)r5c3) - (3|6=7)r4c2 - (*4|7=6)r4c8

Or using my bracketed style attempting to depict parallel branches in one dimension (poorly, apparently):

(9)r4c1 = [[ (4)r4c1 ] && [ (4)r4c1 - (r4c7 | r5c3) = ((3)r4c7 & (6)r5c3) - (3|6=7)r4c2 ]] - (4|7=6)r4c8

Both, when read as intended, are bidirectional though not valid AICs. The first one may actually be correct as boolean logic, too (if you remember to add the "remote" NAND between 4r4c1 and 4r4c8).

[SteveG48]

Excellent! Thanks! Could a complete breakdown look like this:

(4)r2c8 = (83)r2c78 - (3)r2c23 = ((2)r2c2 & (5)r2c3) - ((2)r4c2 | (5)r2c1)) = ((8)r4c2 & (5)r4c1) - (8|5)r4c8 = (34)b6p26 => -4 r6c8

Yes!

[SteveG48]

As a memory chain:

(9=4*)r4c1 - (r4c7 | r5c3) = ((3)r4c7 & (6)r5c3) - (3|6=7)r4c2 - (*4|7=6)r4c8

This is what I prefer.