SteveG48 wrote:SpAce wrote: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.