DC "Everything" signal behaving inconsistently

[AveCarota]

I have a few examples of the "everything" signal in a decider combinator behaving inconsistently or incorrectly. All combinators in question are wired with inputs and outputs, but no signals are present on the input wires. I have a condition to check that "everything = 0" on both R and G on all three, and three different outcomes.

11-05-2024, 12-33-54.png (478.66 KiB) Viewed 456 times

The first image is somewhat of a control, showing the signal correctly evaluating to true, as there are no input signals.

11-05-2024, 12-34-39.png (479.7 KiB) Viewed 456 times

The second image shows the everything signal in an OR relationship with another condition, comparing the values of the R and G wires. Despite the wires being empty, the Everything condition does not evaluate to true. This was achieved by placing the combinator, setting the Each condition, and then adding the Everything condition

11-05-2024, 12-37-55.png (678.07 KiB) Viewed 456 times

The final image shows the opposite of the second, where the Everything condition visually evaluates to true, but does not output any values.
I achieved this state by first setting the Everything condition and then adding the Each condition.

[boskid]

Ok i will have to take some drastic changes because people keep reporting bugs about [Each] signal apparently changing the behavior. First i will keep a list of bug reports where this confusion was a primary factor:

• [2.0.13] OR in decider combinator with EACH + EVERYTHING signals does not behave as expected
• Decider with OR condition not becoming 'true'
• [2.0.9] Decider combinator bug
• [2.0.14] Decider combinator 'Each' signal outputs wrong signal count in combination with red and green only checkboxes
• DC "Everything" signal behaving inconsistently (this)

First i will do a quick overview of signals that people in most of those cases want to use:
- [Everything] special signal used in a condition checks the condition for all signals that are present on the input. If every signal present (to be present it must be non zero) matches the condition then entire condition evaluates to true, otherwise it evaluates to false. If there are no signals to be checked it defaults to true (there were no contradicting signals so it is true).
- [Anything] special signal used in a condition checks the condition for all signals that are present on the input. If any of the signals present (to be present it must be non zero) matches the condition then entire condition evaluates to true, otherwise it evaluates to false. If there are no signals to be checked it defaults to false (there were no signals passing so it is false).

Now there is also a third special signal which flips the brain inside-out and completly changes the meaning of a combinator. It is an [Each] signal. Main purpose why this signal was introduced is to make it possible for a single arithmetic combinator or decider combinator to behave as a huge block of combinators, each configured for a different signal. [Each] becomes a substitute of a signal that has appeared as non zero signal on the arithmetic combinator input side or has appeared as non zero signal on the decider combinator conditions side. This effectively falls into a "stack of combinators" principle: if there are N unique signals on the input side, then combinator with [Each] will (in most cases*) behave as if there was a stack of N combinators connected in parallel, each one of them having a different signal put in place of the [Each] condition inside.

This "stack of combinators" principle effectively means that this:

11-05-2024, 20-09-13.png (65.25 KiB) Viewed 434 times

Is effectively the same as this set of 3 combinators where [each] signal was replaced with individual signals present on the input:

11-05-2024, 20-10-19.png (219.99 KiB) Viewed 434 times

Main point here is: If you are not an advanced circuit network user, you probably do not want to ever use [Each] as it will be confusing at first, and effectively never ever would you want to mix [Each] with [Everything] or with [Anything] in the same decider combinator.

Now with my points given here for other topics to link here, i can explain what is happening in the original post here:

- [Everything] = 0. is true so the output is given (decider is working in "normal" mode which effectively means it produces one output only)
- Each[G] < Each[R] OR [Everything] = 0. In this case obviously the second part is true, however that does not matter. Decider is working in "each" mode which means it produces output once for every signal that was used as [Each] substitute. Since N=0, that means the decider effectively behaves as no decider combinators because there were no Each signal substitutes and it correctly outputs value of 0. In this mode it is important that decider checks conditions for each signal separately because it matters for how many of the substitutes the conditions were true: output [check mark]=1 would give you a value of 5 if there were 5 substitute signals that made conditions with [each] to be considered true since it is an equivalent of having 5 deciders each checking individual signals and each of them tries to output [check mark]=1 into a shared output network.

Moving to Not a bug.

As for the [Each] signal, i will have to consider if i want to keep allowing mixed [Each]+[Everything] or [Each]+[Anything] as in many cases it simply does not make any sense, and i will also need to consider if [Each] signal could be renamed into something less ambiguous, like [For each].

[AveCarota]

Thanks for the quick response, that explanation cleared things up for me.

I think the current visuals make it easy to incorrectly intuit that the Each loop and the Everything condition would be evaluated separately, and not that including the Each will make the combinator loop through both conditions for each possible signal. I think updating the tooltip for the Each wildcard could be more than sufficient, if changes are in fact being considered. Adding a line similar to the Everything and Anything signals that note that if there are no input signals, no conditions will be evaluated, so people using Everything to try and evaluate whether a box is empty will stop and consider that there's definitely a better way to do so