How does "each" work as output in the new decider combinator?

[yankee42]

I have read the "Signal Switch"-Section in the circuit network cookbook in the wiki and I am trying to understand what it is doing. It exploits the special behaviour of the "each" signal when used as an output, but I don't fully understand how it works.

My first guess is that each "each"-test has the side-effect of adding matching signals to a list of output signals. So let's start with a very simple example:

simple.png (16.13 KiB) Viewed 414 times

In pseudo-code I could maybe write this as:

Code: Select all

if (each_input_matches(=, -1)) output_each()

Now what I think is that if I expand "each_input_matches" it would probably look like this:

Code: Select all

output = [] # start with an empty list
foreach signal, value in signals
    if value == -1 then output += (signal, value)
return notEmpty(output)

However as a side-effect the "output" is preserved and if I select "each" as output, I will get that list of signals as output.

But what if I start to use "and" and "or"? Let's try this:

if-else-1.png (74.75 KiB) Viewed 414 times

There is a constant combinator (outputing 1=-1, 2=-2) connected as you can see in the list of input signals.

The example consists of two "and"-blocks connected by "or".

There is no belt-signal, so the first and-block is false, but the second one is true.

Nevertheless, the each test in the first and-block does match, because there is a signal with the value -1. So why is the signal "1=-1" not added to the output? Theory: In most programming languages a statement such as "if (A=1 and B=2)" where A<>1 will not check B anymore. So I'd guess that in the example above the decider checks "belts>0", but this is not true and thus the "each_input_matches(=, -1)"-check is not executed. If this theory is correct, then changing the order would change the result. So I try this:

if-else-2.png (72.45 KiB) Viewed 414 times

This disproves my theory, because the order of the conditions does not change the result. So now I am at a loss. My next theory would be that the decide will reorder the conditions, so that each-checks always come last and they are skipped if any connected and-condition is false. Now I am running out of ideas on how to test this theory and I need your help:

If there are multiple "each"-conditions in a decider combinator, what is going to end up in an output?

[jdrexler75]

Basically, for each input signals, ALL conditions are evaluated. For those input signals where the result is true, you get that signal in the "each" output.

I would write it as the following pseudo code:

Code: Select all

output = [] # start with an empty list
for each_signal, each_value in signals
    if evaluate_conditions(each_signal,each_value) then output += (each_signal, value_switch ? each_value : 1)
return output

So in your second example, it would be

Code: Select all

output = [] # start with an empty list
for each_signal, each_value in signals
    if (belt_signal>0 and each_value==-1) or (belt_signal==0 and each_value==-2) then output += (each_signal, value_switch ? each_value : 1)
return output

The each_signal "type" itself is not part of the condition. It is only used for selecting which signal gets the selected output value. And the belt condition uses the belt signal value, not the each signal value, because you're checking the belt signal, not the each signal.

So in your example with belt>0 you get all input signals that are equal to -1, and with belt==0 you get all input signals that are equal to -2.

[jdrexler75]

To make it easier to understand what's going on, I think it would help to reorder the "each" rule to be first, like this. Red is from the constant provider, green is from the inventory.

Screenshot_20250315_120014m.png (407.59 KiB) Viewed 369 times

It's not obvious in the screenshot, but the input values on the red line are 10001, 10002, 10003 etc. Maybe a blueprint would help:

0eNrlV9tuozAQ/ZXKz04VSEkI0u7LfkYVIQcmjVWwWdukjSL+fcckTYBySUgfIu0b2J45Z86MfOBA1kkOmeLCkOBAeCSFJsHrgWj+Jlhi1wRLgQQkhojHoCaRTNdcMCMVKSjhIoZPEjgFbQmxyQwTpj3GLVaUgDDccDhili/7UOTpGhQmpX2JKMmkxlgpLKLlsHj2KNnjw7OHKDFXEB23fWozGCWTcA1btuMYjjH6uK/rz8jjqyhKNjwxoGqrizOrFAxLEh5NmMZDkseTaJuLd2T2N2cJVoJnhFQpamIJpBlTJfOA/CoXcqu5O51a7U7J/UvJTK2luDO5U0u+PCeXn9jKuzJ7U9u9NyXzDDf+2AT6KVOweeIRkAqo2yoiSmv2maWCTeL40COqwvGUEWjNxdvN5U+dOpcO1O9q34fqVlBnnaiNNtwHOatAvnRCsnjHRATxpGV4Va63N0O7DY29YeiW0R4NXRV6PgzdHPzRuFW1FzcM8zjEWUNk/4ZBHo/o1u+O64Z4PNys5UY5gmlSrIrCsmk4hEt73KnbIGZX2cMpZYh7MT8bRfUN77MNV9qEF+c7ibTjyuRlxSd+xxMTYNHWWiDaDeb5HnfjbVi0KFplFAowH1K9l8wVxCQwKgerMgAWvmGJhiabq2JsL5qlD7hiW9XDIbXyfg+WV7I7c7XER5X3hQvhqS9MxKSt5h9u94ANPWK7u75TetrdE/J/tbvP/x+x162fjT2N7jr/SF1Gz5G5yXLT/O25steRzPZh6WLhRsk05AJznTlfJbj1NqTxgY5kSbw61KEudVa4xg2kiHn5R6Nkh5/SpW15c3f5slx6c2fqu75fFP8AM0nFgg==

Copy blueprint

So the logic is, "if we're evaluating the metal asteroid recipe signal, compare the metal chunks to the following value and add the recipe to the output if true". The key is that you can uniquely identify the signal type from the signal value using the red wire, and so do different conditions depending on the signal type, which a standard each condition does not do.

[Tertius]

My next theory would be that the decide will reorder the conditions, so that each-checks always come last and they are skipped if any connected and-condition is false. Now I am running out of ideas on how to test this theory and I need your help:

If there are multiple "each"-conditions in a decider combinator, what is going to end up in an output?

An EACH can be seen as multiple combinators, each processing one signal, and all inputs and all outputs connected.
Imagine the processing logic first collects all nonzero signals on the input, regardless of color. Now it processes every condition that contains an EACH and replaces it with a bunch of internal combinators each one processing one of the collected signals. The signals are given the values from their corresponding input, i. e. red, green, or red+green.

Simple conditions without each are attached to each of these expanded internal combinators.
In your example, the <1> and the <2> signals are collected, so the first condition with EACH becomes 2 conditions:
(I use == for "is equal to" to differ between condition and value assignment)
<1> == -1
<2> == -1

The 2nd condition becomes:
<1> == -2
<2> == -2

The conditions come with an additional simple condition with AND, and is combined with the expanded EACH. The combined 1st EACH becomes:
<1> == -1 AND <belts> > 0
<2> == -1 AND <belts> > 0

The second one:
<1> == -2 AND <belts> == 0
<2> == -2 AND <belts> == 0

This is now processed like this.
Inputs are <1> = -1, <2> = -2, <belts> = 0

Let's evaluate the single conditions:
<1> == -1 AND <belts> > 0 becomes -1 == -1 AND 0 > 0, so it becomes false for <1>
<2> == -1 AND <belts> > 0 becomes -2 == -1 AND 0 > 0, so it becomes false for <2>

The other EACH:
<1> == -2 AND <belts> == 0 becomes -1 == -2 AND 0 = 0, so it becomes false for <1>
<2> == -2 AND <belts> == 0 becomes -2 == -2 AND 0 = 0, so it becomes true for <2>

Both are combined with OR, so the end result is true, if either one of the two is true. One of the EACH expansions is true (the last one), so that EACH becomes true. This EACH is true, so the OR combination is true. So the whole condition in the combinator is true, so an output is generated.

Now to the output generation:
The output is an EACH as well, so it is expanded with every signal that resulted in a true result in condition evaluation. This happened for one of the EACH, for the <2> signal, so the output EACH is expanded with the <2> signal. You defined it to output=1. Since the <2> signal matched 1 time at input processing, the 1 is output 1 time, resulting in a value of 1 for the <2> signal.

You see order has nothing to do with evaluation. The order is irrelevant.

[yankee42]

Thanks for response.

So in your second example, it would be

Code: Select all

[..]
    if (belt_signal>0 and each_value==-1) or (belt_signal==0 and each_value==-2) then output += (each_signal, value_switch ? each_value : 1)
[..]

I had to run this through my head a number of times. This does make sense. I think the key I was missing then is, that the foreach-Loop is actually the "outer command". So the the whole "if" is executed for each signal and not just the inner condition.

Also thank you Tertius. For your examples I would have better used "A" and "B" instead of "1" and "2", but I think I got it. You model yields the same result as the "outer command" model, but actually makes for sense to me from a logic perspective.

[Tertius]

Don't make the mistake and see combinators as a program or subroutine. There's no program sequence. Instead, it is more like a rule based state machine.
It's completely static, not dynamic like a program.

You have an input state, rules, and an output state. The rules are given high level and expanded to internal raw rules that actually process the input state to produce intermediate and output states. Any AND and OR define how intermediate states are created and combined. All conditions combined with AND create one intermediate state, and conditions combined with OR combine these intermediate states.