Add large arithmetic/decider combinator

[mrvn]

TL;DR

There are operations that can't be performed with arithmetic/decide combinators because red and green wires are added up at the input.

What ?

Add a larger version of the arithmetic and decider combinator that has 2 input terminals. The GUI and function is exactly like the existing GUI with one change. The first operand is taken from the first input terminal and the second operand is taken from the second input terminal. For decider combinators the output is also taken from the first terminal (or can choose terminals but that would change the GUI).

Why ?

Sometimes one wants to do an operation using the red and green wires separately.

A simple example is computing red * green. While you can't do that in an arithmetic combinator you can use a few combinators in a network to solve that problem. Being able to do this in one tick would be an improvement.

For decider combinators people sometimes want to compare the signals on the red and green wire. So they have to delay red by 1 tick, negate green and then compare the combined results against 0. And if you want to emit the original value from the red wire when the condition is met you have to add a "red * green" combinator network on top.

But worse is that you can not compute red / green by some simple formula. For example divide all items by their respective stack size. You can implement your own long division algorithm either as humongus combinator network or as iterative process but the size and delay makes this unusable. Or multiply by the inverse and bit shift but that quickly overflows or underflows.

I could probably come up with a hundred more example. Having combinators with separate input terminals would make all of those simpler and make the circuit network more approachable by the average user.

PS: this would also make more sense when you simply want to add 2 green wires. Currently this requires 2 arithmetic combinators set to each + 0 = each to isolate the inputs and then connecting the outputs to actually add.

[Tertius]

Thought about this, and it boils down to the ability to have an "Each" wildcard as right operand of the arithmetic combinator that uses a second input.

Each as right operand:
Behavior: Values for the right operand are taken from a second pair (red+green) of input (not currently present).
Result: The operation is performed for each signal on the left operand with each corresponding signal on the right operand.

+1

would use it!

[ssilk]

Mrvn seems to have a talent to make simple things complicated….

I mean this has already been suggested in a simpler form here:
viewtopic.php?f=6&t=94715 'Each on Red Circuit' and 'Each on Green Circuit'

See also viewtopic.php?p=540302#p540302 (and the other links), which generally want to enable the usage of red/green signals in combinators.

[mrvn]

I know about the "each on red" suggestion. That post is from 2021 and it's not the first time that was suggested. It's been a thorn in users fun for years.

So many users suggesting the same thing in many different ways. And yet still none of them get implemented.

So we keep suggesting different solutions to basically the same thing in the hope that one might find approval by the devs and get implemented.

Note that all the suggestions you referred to are about handling the red and green wire separately. This one is a different approach by having a combinator that has 2 separate input terminals. Both would have a red and green connector. It's a combinator with 2 inputs instead of only 1 input.

[ssilk]

So we keep suggesting different solutions to basically the same thing in the hope that one might find approval by the devs and get implemented.

That’s not the way how it works.

… and when you did know the suggestions, why didn’t you just linked them and say “this is what I would change”?

Note that all the suggestions you referred to are about handling the red and green wire separately. This one is a different approach by having a combinator that has 2 separate input terminals. Both would have a red and green connector. It's a combinator with 2 inputs instead of only 1 input.

I understood it. Again: with that you make simple things much more complicated. A second terminal means, that you need to understand which input is which side of the operation. With colors this is simple. With a second terminal you need another distinction between both.

[coppercoil]

A second terminal means, that you need to understand which input is which side of the operation. With colors this is simple. With a second terminal you need another distinction between both.

No problems with two terminals. Just name them white and black orange and blue for fast identification. If you need advanced combinator, you should be able to deal with four colors

[mrvn]

I made a new suggestion because it's a different suggestion. It even makes sense to have both. They somewhat overlap but they can also solve different problems.

As for understanding which input is which side of the operation: Would really be an issue? That thought never ocured to me because it's so basic. The left input is the left operand and the right input is the right operand. Same as with splitters where you have a left and right input and output. Users seem to understand left and right even with the entity able to rotate. Wouldn't have thought it would be different for this.