[2.0.14] Combinators: EACH not allowing condition to be evaluated

[Necandum]

I have created the following combinator (in attached image).

Conditions:
[dot] < 500
OR
EACH < 0

OUTPUT [dot](1)

There is currently no input or output to the combinator.

Given the conditions are combined by an 'OR', if one is true, I would expect the combinator to output 1 [dot].
I also expect that the presence or absence of a second condition combined with the first by an 'OR' should not affect the evaluation of either.

In this case, the first condition is not green / the game doesn't evaluate it as true, even though it clearly is. Removing the condition with EACH shows this.
In connection, the game doesn't seem to evaluate this OR expression correctly, and does not output a 1[dot].
Basically, 1 | 0 should = 1.
I'm aware EACH can be a little tricky, but this looks unintended to me.

Apologies if there's just an element of logic I'm missing, I posted on the reddit group first to make sure I wasn't being obviously daft. However, I've played with it further, and EACH combined with an OR condition with something not containing EACH has some generally odd behaviour.

[Necandum]

Another oddity. One would think the second situation would only output a single green.

[Criperum]

I think it's intentional. "Each" filters out signal from Input and then either transforms them into selected signal or outputs then as is. Since there are no inputs it's nothing to filter and nothing to transform/output

[robot256]

I ran some tests and figured out something interesting. The EACH wildcard being used anywhere in the conditions means that the entire list of conditions gets replicated for every nonzero signal received. For example, using your condition:

Input= Dot[1]
Output= Dot[1]
Because one channel was created for the Dot signal, and the Dot<500 condition passed.

Input= A[1]
Output= Dot[1]
Because one channel was created for the A signal, and the Dot<500 condition passed.

Input= Dot[500], B[1], C[-1]
Output= Dot[1]
Because three channels were created for the three input signals, but only the C<0 condition passed.

Input= Dot[1], B[1], C[-1]
Output= Dot[3]
Because three channels were created for the three input signals, the Dot<500 condition passed for all three of them, and the three Dot[1] outputs were added together.

Input= (nothing)
Output= (nothing)
Because no nonzero input signals were found, no channels were created and no conditional checks were performed at all.

This looks like it is working very consistently. If what you really want is the count of how many signals are less than 0, except for Dot, plus 1 if Dot is less than 500, then you can do it easily. Set the combinator to just EACH<0 => Dot[1]. Then add a constant combinator on the input with Dot[-500] to provide an offset.

[boskid]

Not a bug. viewtopic.php?p=631944#p631944

Most likely you are confused about which exact special signal you want to use, it seems you actually want [Everything] signal.

[Necandum]

Not a bug. viewtopic.php?p=631944#p631944

Most likely you are confused about which exact special signal you want to use, it seems you actually want [Everything] signal.

I've had read of that thread, and a few more linked over time. Apologies, I search for similar threads and clearly failed to search well.

In terms of what I was trying to achieve, it was a self starting, self resetting timer combined with a memory cell that only remembers positive digits. The above is just the simplest case of the issue.

Implementing something like EACH is definitely non-trivial, but the above:
a) violates basic prepositional logic
b) means there is no difference between joining conditions with OR and AND in this case, which is confusing for the user.


To paraphrase:

Lets imagine decider combinator with following settings:
inputs [iron-plate]=3, [copper-plate]=4, [plastic]=5
[Everything] < 10 OR [Each] < 50 output [X]=1.

I would contend the output should be X4. EACH is special when used with output (1), and this should be maintained with the new more complicated combinators. The overall logical expression passes, resulting in 1 X. Then, each condition that passes EACH also give 1X.
This way of interpreting is also resistant to flipping the condition order.

It sound like an 'each' mode for the easiest way to solve this originally. However, in the second case I posted, the result seem absurd:
Input: [X]=6, [Yellow] = 1
[X] > 5 OR [Each] > 10 output [Green] = 1

This leads to [Green] = 2, despite EACH being false for all signals.

Pretty please reconsider this not being a bug? With the biggest cherry pie on top?

[boskid]

There is nothing here to reconsider. [Each] signal is for working with vectors of signsls (frames of signals) where you want the combinator logic to be performed independently for each signal on the input to produce (usually) vector of signals on the output. Any logic proposed here tries to add some exceptions that do not work for a concept of "vector of signals". Proposal of output value of 4 is just absurdly incompatible with logic of [each] signal. When output would be configured to output [each]=1, what would be the signal substitute used for the output related to the freestanding [everything]<10 condition that was ORed?

[Qon]

It sound like an 'each' mode for the easiest way to solve this originally. However, in the second case I posted, the result seem absurd:
Input: [X]=6, [Yellow] = 1
[X] > 5 OR [Each] > 10 output [Green] = 1

This leads to [Green] = 2, despite EACH being false for all signals.

Pretty please reconsider this not being a bug? With the biggest cherry pie on top?

If you make two combinators:
[X] > 5 OR [X] > 10 output [Green] = 1
[X] > 5 OR [Yellow] > 10 output [Green] = 1
Then both will have their conditions evaluated to true when fed signal [X]=6, [Yellow] = 1. And combined they will output 2. Makes perfect sense.
X > 5 on both, and you used OR, so the [each] > 10 doesn't matter. That is OR and [each] working as expected and intended.

[robot256]

Pretty please reconsider this not being a bug? With the biggest cherry pie on top?

Qon is absolutely correct. Personally, the main takeaway I get from this and the other threads is that making combinators multi-conditioned might have been a mistake. It seems to have misled people into thinking that anything they can imagine should be doable with only one combinator. The multi-condition feature is nice but there are still lots of problems that are easier to solve--or can only be solved--by using more than one combinator.

There are certainly more permutations that need to be documented, and more work for the community to do to explain how vector and synchronous discrete-time operations work, but we haven't found any inconsistencies in the underlying behavior.

[boskid]

Main conclusion here is that [each] signal has a precisely defined way of processing: it is for handling vectors of signals so the "stack of combinators" principle usually should apply.

There are 2 cases where it does not apply but they were chosen for compatibility or usability reason.

Case 1 where this principle does not hold: Conditions with [each], output [anything]. In this case it was decided to be more useful to return only one, arbitrarily chosen signal from the passing signals. If this selection is not what is ecpected, then output [each] and use selector combinator to pick one signal using one of selector combinator modes (random, highest, lowest, whatever). This is solvable with second combinatorvif soneone disagree.

Case 2 where conditions has [each] but output is a specific signal with input count. In this case the input count is not value of that signal but value of the each substitute signal. This case was selected for compatibility with 1.1. If someone disagree then output specific signal with value 1 (it will be effectively amount of signals passing) and use arithmetic combinator to multiply amount of signals passing with the original signal. Current behavior is equivalent of having "output [each]=1" and feeding this into arithmetic that does element-wise multiplication with input signals and outputs those values into a specific signal.

All of those special cases can be worked around with second combibator. [Each] signal has precisely defined meaning and there are no arguments given that would explain changing how it behaves.

(FYI i hate typing on my phone, way too many mustakes gets introduced)

[Necandum]

Thanks for the detailed answer boskid! Its always good to hear the intricacies from a person neck deep in the codebase. And thank you for entertaining these questions.

There is nothing here to reconsider. [Each] signal is for working with vectors of signsls (frames of signals) where you want the combinator logic to be performed independently for each signal on the input to produce (usually) vector of signals on the output. Any logic proposed here tries to add some exceptions that do not work for a concept of "vector of signals". Proposal of output value of 4 is just absurdly incompatible with logic of [each] signal. When output would be configured to output [each]=1, what would be the signal substitute used for the output related to the freestanding [everything]<10 condition that was ORed?

The output should be two of every signal that was passed.
If you just have condition Everything > 0 output Each (1), then you get every signal passed in at value 1.
If you just have condition Each > 0 output Each (1), then you get every positive signal passed in at value 1.
If these were joined by an OR, you should get both (so every signal at value 2, assuming all signal were positive), as there is no way to prioritise one over the other in a logical manner.
If the user only wanted one of every output, they should use AND.

Qon kindly explained how the system now works, and I'm pretty sure I understand it fully. This is outside bug report territory, but you asked how else the logic should work, and I think a simple alteration is that the 'combinator stack' for an each operator should be created separately for each block of conditions connected by OR connectors, and their results summed.

So if:
INPUT [X] =1, [Y] = 2, [Z] = 3

{
[X] = 1
}
OR
{
[Each] > 1
}
OR
{
[Each] > 1
AND
[Z] = 3
}

OUTPUT [A] (1)

Would give give output [A] = 1+2+2 = 5

The stacks would be:
1)
[X] = 1 {1}

2)
[X] > 1 {0}
[Y] > 1 {1}
[Z] > 1 {1}

3)
[X] > 1 AND [Z] = 3 {0}
[Y] > 1 AND [Z] = 3 {1}
[Z] > 1 AND [Z] = 3 {1}

Obviously I'm not privy to why the system is as it is, and haven't done a study to find what else might break, but the above logic seems much more tractable to me. Its all still vectorised, but the connector OR acts closer to what it does in classical logic.

If you make two combinators:
[X] > 5 OR [X] > 10 output [Green] = 1
[X] > 5 OR [Yellow] > 10 output [Green] = 1
Then both will have their conditions evaluated to true when fed signal [X]=6, [Yellow] = 1. And combined they will output 2. Makes perfect sense.
X > 5 on both, and you used OR, so the [each] > 10 doesn't matter. That is OR and [each] working as expected and intended.

Thanks for the explanation! The intended logic now makes perfect sense to me. I think its suboptimal however, as outlined above. I don't see why, when creating the 'combinator stack' for EACH, you should include conditions connected to it by OR. The results you get may be intended by factorio logic, but as presented it has seriously started to depart from the logical uses of OR and AND, and, I think, doesn't give a good result.

1 OR 0 should give 1. Even if 0 stands in for a complicated function. If it doesn't, then it shouldn't be called OR.

EDIT: In combinator stack #3 I iterated the number being compared to instead of the signal letter. Ooops.

[Qon]

The output should be two of every signal that was passed.
If you just have condition Everything > 0 output Each (1), then you get every signal passed in at value 1.
If you just have condition Each > 0 output Each (1), then you get every positive signal passed in at value 1.
If these were joined by an OR, you should get both (so every signal at value 2, assuming all signal were positive), as there is no way to prioritise one over the other in a logical manner.
If the user only wanted one of every output, they should use AND.

No, if the full logic on the left evaluates to true, then you get the output on the right (once, except if each exists somewhere).

Qon kindly explained how the system now works, and I'm pretty sure I understand it fully.

I'm sorry, but you do not. But I'll help you

So if:
INPUT [X] =1, [Y] = 2, [Z] = 3

{
[X] = 1
}
OR
{
[Each] > 1
}
OR
{
[Each] > 1
AND
[Z] = 3
}

OUTPUT [A] (1)

Would give give output [A] = 1+2+2 = 5

The stacks would be:
1)
[X] = 1 {1}

2)
[X] > 1 {0}
[Y] > 1 {1}
[Z] > 1 {1}

3)
[X] > 1 AND [Z] = 3 {0}
[X] > 2 AND [Z] = 3 {1}
[X] > 3 AND [Z] = 3 {1}

Obviously I'm not privy to why the system is as it is, and haven't done a study to find what else might break, but the above logic seems much more tractable to me. Its all still vectorised, but the connector OR acts closer to what it does in classical logic.

That's not how it works and not how it should work.

First a minor detail, > is the "greater than" symbol. < is the "less than" symbol" You meant < in (3), because your partial calculation results are impossible with >.

But you don't split up the combinator and then virtually stack it with each. You make a virtual stack of the entire combinator with the each signals replaced with one signal type for each input, and run them all in parallel.
For input X = 1, Y = 2, Z = 3 the combinator configured like:

Code: Select all

X = 1 || each > 1 || (each > 1 && Z = 3)

OUTPUT [A] (1)

will expand to be equivalent to these 3 combinators (because 3 input signals) configured like so:

Code: Select all

X = 1 || X > 1 || (X > 1 && Z = 3)    =>    true || false || (false && true)    => true 
X = 1 || Y > 1 || (Y > 1 && Z = 3)    =>    true || true  || (true  && true)    => true 
X = 1 || Z > 1 || (Z > 1 && Z = 3)    =>    true || true  || (true  && true)    => true 

OUTPUT [A] (1) for all that evaluate to true and sum up the values.

Since you OR with test X = 1 in all, which is true, they all pass and all output A = 1, which means the complete result is A = 3 as output.

Thanks for the explanation! The intended logic now makes perfect sense to me. I think its suboptimal however, as outlined above. I don't see why, when creating the 'combinator stack' for EACH, you should include conditions connected to it by OR. The results you get may be intended by factorio logic, but as presented it has seriously started to depart from the logical uses of OR and AND, and, I think, doesn't give a good result.

1 OR 0 should give 1. Even if 0 stands in for a complicated function. If it doesn't, then it shouldn't be called OR.

You didn't get it. But give it another try.
1 OR 0 does give 1. Look at the example above, again.

[boskid]

ORs are not a boundary of combinator. Having conditions "[X]=1 OR [Y] = 2 output Z=1" under this interpretation would no longer be deciding if condition on the left side is true, but how many times it is true. That case would then be expected to output Z=2 when inputs were X=1,Y=2. This is just unreasonable. In normal mode decider uses conditions to get a single boolean saying if it should output or not. In each mode it gets a vector of booleans, one for each substitute usee.

[Necandum]

The output should be two of every signal that was passed...

No, if the full logic on the left evaluates to true, then you get the output on the right (once, except if each exists somewhere).

Qon kindly explained how the system now works, and I'm pretty sure I understand it fully.

I'm sorry, but you do not. But I'll help you

So if:
INPUT [X] =1, [Y] = 2, [Z] = 3

...

That's not how it works and not how it should work.

First a minor detail, > is the "greater than" symbol. < is the "less than" symbol" You meant < in (3), because your partial calculation results are impossible with >.

But you don't split up the combinator and then virtually stack it with each. You make a virtual stack of the entire combinator with the each signals replaced with one signal type for each input, and run them all in parallel.
For input X = 1, Y = 2, Z = 3 the combinator configured like:

Code: Select all

X = 1 || each > 1 || (each > 1 && Z = 3)

OUTPUT [A] (1)

will expand to be equivalent to these 3 combinators (because 3 input signals) configured like so:

Code: Select all

X = 1 || X > 1 || (X > 1 && Z = 3)    =>    true || false || (false && true)    => true 
X = 1 || Y > 1 || (Y > 1 && Z = 3)    =>    true || true  || (true  && true)    => true 
X = 1 || Z > 1 || (Z > 1 && Z = 3)    =>    true || true  || (true  && true)    => true 

OUTPUT [A] (1) for all that evaluate to true and sum up the values.

Since you OR with test X = 1 in all, which is true, they all pass and all output A = 1, which means the complete result is A = 3 as output.

Thanks for the explanation! The intended logic now makes perfect sense to me. I think its suboptimal however, as outlined above. I don't see why, when creating the 'combinator stack' for EACH, you should include conditions connected to it by OR. The results you get may be intended by factorio logic, but as presented it has seriously started to depart from the logical uses of OR and AND, and, I think, doesn't give a good result.

1 OR 0 should give 1. Even if 0 stands in for a complicated function. If it doesn't, then it shouldn't be called OR.

You didn't get it. But give it another try.
1 OR 0 does give 1. Look at the example above, again.

The long example I gave was not how I think the system currently works, but how I think it *should* work with each (and only with each).
My new understanding for how the system *now* works accords with everything you wrote, so I will continue to believe I understand how it works.
And yes, apologies, I made an error and instead of iterating the signals in stack #3, I iterated the numbers. This wasn't a problem with the signs.

In terms of 1 | 0 = 0:

Input: NULL

[X] < 500 {true}
OR
[Each] > 5 {false}

Output = False

Yes, I now understand why this happens. But it I contend it shouldn't: adding an OR condition should not prevent a previously true condition from being evaluated as true.

[Necandum]

ORs are not a boundary of combinator. Having conditions "[X]=1 OR [Y] = 2 output Z=1" under this interpretation would no longer be deciding if condition on the left side is true, but how many times it is true. That case would then be expected to output Z=2 when inputs were X=1,Y=2. This is just unreasonable. In normal mode decider uses conditions to get a single boolean saying if it should output or not. In each mode it gets a vector of booleans, one for each substitute usee.

You would only do a new 'stack' if and only if a block* of conditions included each and was connected to another block by OR. Everything else goes in one stack.
*a block of conditions = conditions connected together by ANDs

To illustrate how this small change would effect things:

Case 1
Input: [X] = 1, [Y] = 2

X>0 OR Y >0

Output: [A](1)

No stacking , no each involved, use standard logic. Outputs 1 A.

Case 2
Input: [X] = 1, [Y] = 2

X>0 OR Y >0 OR { Each > 1 and X>0}

Output: [A](1)

Stack #1:
X>0 OR Y>0 {1}

Stack #2:
[X] > 1 AND [X]>0 {0}
[Y] > 1 AND [X]>0 {1}

Answer would be 2 A. Same as current System

Case 3

Input: [X] = 1, [Y] = 2, [Z] = 1

X>0 OR Y >0 OR { Each > 1 and X>0}

Stack #1:
X>0 OR Y>0 {1}

Stack #2:
[X] > 1 AND [X]>0 {0}
[Y] > 1 AND [X]>0 {1}
[Z] > 1 AND [X]>0 {0}

Output: [A](1)

Answer remains 2. Current system would give the result 3. Why should adding a signal that does not meet any of the criteria increment the answer? To clarify, I understand why it does with the current system. I just think this behaviour is not ideal, and that the alternative would be both more intuitive and more useful.

Case 4

Finally, my proposed alternate system would make 1 | 0 = true.

Input: NULL

[X] < 500 OR [Each] > 0

Stack #1:
[X] < 500 {1}

Stack #2:
NULL

Output: A(1)

This would output 1 A. Current system gives 0. Again, I understand why. Taking an outsider's point of view, the result seems...not correct. It is history and implementation details that lead to current answer being what it is.

[Qon]

Answer would be 2 A. Same as current System

The result being the same is just an accident. 2 * 2 = 2 ^ 2, but multiplication isn't exponentiation. A broken clock is right twice a day. Your proposed system makes no sense. To get the behavior you want just use [every] instead of [each] for this post. And the earlier example with 5 as proposed output makes no sense at all. You are basically asking for your wrong code to get the behavior you want by pestering the devs to change the compiler/language so that you don't have to fix your bugs, while breaking the system for everyone else and ensuring no one else can use the combinators current useful features.

[Necandum]

Answer would be 2 A. Same as current System

The result being the same is just an accident. 2 * 2 = 2 ^ 2, but multiplication isn't exponentiation. A broken clock is right twice a day. Your proposed system makes no sense. To get the behavior you want just use [every] instead of [each] for this post. And the earlier example with 5 as proposed output makes no sense at all. You are basically asking for your wrong code to get the behavior you want by pestering the devs to change the compiler/language so that you don't have to fix your bugs, while breaking the system for everyone else and ensuring no one else can use the combinators current useful features.

Sorry, I don't understand your comment. And I don't think you understand my proposal. What doesn't make sense to you?
I don't believe it will break the current system at all, and will only improve the usability/comprehensibility of the combinator system. I have outlined some cases above to try to show that. Would you have any cases where this behaviour would ensure on one else can use the current useful features?

And I don't think I'm pestering the devs: I'm replying in a single conversation to clarify what I mean when it seems I have been mis-understood. As soon as boskid gets bored, they will stop replying and that's the end of that.

[boskid]

I got bored when i said "There is nothing here to reconsider." and rest was just trying to be nice by providing details that would help you understand why your proposals are just bonkers. [Each] signal was made for handling vector of signals and you are trying to make excuses that would violate this primary use case and trying to explain that based on percieved consistency of language rules and how OR should behave. I will just lock this topic to discourage future discussion about this.