Else output for decider combinator

[Zaflis]

In programming there is a simple structure; If - Then - Else. There are numerous potential applications for this, but if i were to do that simple thing with current combinators i'd be in for a bit of trouble.

Example: Signals A=10 and B=20, output higher value
Signal first goes to 2 decider combinators: (A>=B => A) and (B>A => B), then combine output signals which now should be 0+B = B.

In my opinion there should be an "Else" output for when the condition is false, it might even encourage making more complicated circuits when the trivial things aren't made harder than they need to be. The above example you could do with a single combinator:
A>=B => A, Else B

Each > B => Each, Else B
Each > B => Each, Else 0 ?? Could we force output 0 too? Actually you need to if you want old kind of combinators still doable.

[steinio]

A >= B => A
A < B => B
with 2 combinators.

You overcomplicate things.

[Zaflis]

A >= B => A
A < B => B
with 2 combinators.

That's exactly the same example i wrote. It's a matter of perspective. 2 inputs is a simple example, but if you have 200 of them the matter of 400 vs 200 combinator makes a significant difference. It's not just that but this simple "if - then - else" is made into something really weird mathematical logic, where you have to think in your mind of summing signals together and dividing into 2 circuits. I'm not here to complicate things, quite the opposite.

You could say that in other words, current implementation is intimidating. Having "else" there makes it easier to understand, build and maintain.

[Zavian]

A >= B => A
A < B => B
with 2 combinators.

That's exactly the same example i wrote. It's a matter of perspective. 2 inputs is a simple example, but if you have 200 of them the matter of 400 vs 200 combinator makes a significant difference. It's not just that but this simple "if - then - else" is made into something really weird mathematical logic, where you have to think in your mind of summing signals together and dividing into 2 circuits. I'm not here to complicate things, quite the opposite.

You could say that in other words, current implementation is intimidating. Having "else" there makes it easier to understand, build and maintain.

So you build a combinator setup that outputs A=1 if your condition is true. It's now trivial to test for the else condition.

[Zaflis]

So you build a combinator setup that outputs A=1 if your condition is true. It's now trivial to test for the else condition.

No it's not.

[Sad_Brother]

It's a matter of perspective. 2 inputs is a simple example, but if you have 200 of them the matter of 400 vs 200 combinator makes a significant difference. It's not just that but this simple "if - then - else" is made into something really weird mathematical logic, where you have to think in your mind of summing signals together and dividing into 2 circuits. I'm not here to complicate things, quite the opposite.

You could say that in other words, current implementation is intimidating. Having "else" there makes it easier to understand, build and maintain.

Can you show us what you want it for?

[Zaflis]

Can you show us what you want it for?

I don't have any immediate uses, but i might later. You can propably even simplify SR-latch with it. It's because the current implementation in circuit system is so many layered that i am not bothering with circuits as much as i'd like to. Anything that makes them more approachable would be a big help, and this is such an obvious one. You can in best case scenario do your setups with 50% the amount of combinators, and you would see that directly in UPS. Have you seen what people do with combinators? Whole CPU's and video tracks with lamps (which btw run like slideshows at 1 fps), digital numbers etc... All of those things could get higher performance and less combinators. Do you not think there are people who are still even scared of circuits, thinking they are too hard? What makes you think we shouldn't be doing everything in our power to improve the situation? I mean.. even oil setups are too hard for majority of people.

[darkfrei]

Signal to green, and not_signal to red?

[Zaflis]

Code A:

Code: Select all

if A >= B then
  return A
else
  return B
end

VS
Code B:

Code: Select all

return (A>=B?A:0)+(B>A?B:0)

Not only is the above version simpler to understand it's also faster, and i think summarizes this topic 100%. I rest my case and wait for someone to actually put some thought in his reply... Every single one with one sentence. So disrespectful.

[quyxkh]

Can you show us what you want it for?

I don't have any immediate uses, but i might later.

Just fyi, some variation on this sequence is repeated by just about everyone proposing changes to the circuits. Nobody who's built anything substantial with circuits is serously arguing they need changing. The closest any proposal ever gets to having an actual problem with them is ~I have this problem right now and I expected it to work like so, and if circuits worked that way it'd be easy, so circuits should work that way~. This is at least not that. But try solving actual problems posed by actual game situations with the game circuits and you'll get fascinated by what's there now. It's not like programming, it's its own set of design puzzles with clever solutions. When I stopped trying to solve general problems and tried to just identify and solve the specific cases I'd have to deal with I was surprised and gratified at how few circuits it generally took to do it. Seriously: the combinators in this game are a delight as they are.

[Optera]

Nobody who's built anything substantial with circuits is serously arguing they need changing.

I beg to differ.
there certainly are improvements that would save a lot of additional combinators and performance. E.g. Setting deciders to output a specific value instead of 1 or count, but that's off topic here.

The op's change wouldn't save much and like steinio said can already be nicely implemented with 2 deciders.

[Sad_Brother]

Can you show us what you want it for?

I don't have any immediate uses, but i might later.

You got answer already.

You can propably even simplify SR-latch with it. It's because the current implementation in circuit system is so many layered that i am not bothering with circuits as much as i'd like to. Anything that makes them more approachable would be a big help, and this is such an obvious one. You can in best case scenario do your setups with 50% the amount of combinators, and you would see that directly in UPS. Have you seen what people do with combinators? Whole CPU's and video tracks with lamps (which btw run like slideshows at 1 fps), digital numbers etc... All of those things could get higher performance and less combinators. Do you not think there are people who are still even scared of circuits, thinking they are too hard? What makes you think we shouldn't be doing everything in our power to improve the situation? I mean.. even oil setups are too hard for majority of people.

You think combinators with "else" would be more UPS friendly? Doubt it.
You think they would be more user friendly? Definitely not.

Setting deciders to output a specific value instead of 1 or count

is better.

[Zaflis]

You think combinators with "else" would be more UPS friendly? Doubt it.
You think they would be more user friendly? Definitely not.

It's not a doubt but a fact. 1 combinator makes less cpu cycles than 2.

No comments on the code example? The sum version is how you prefer to do all your programming IRL? Most programming languages have been trying to achieve more with higher level code, rather than low level tinkering such as ASM. Tinkering is exactly what implementing "else" with 2 combinators is. You can propably try to code like that but your boss would fire you.

Code B is more user friendly? Definitely not.

I needed to raise code examples because it's how you need to think of the circuits if you want to understand what they do. What i'm proposing is easier for our brains to handle, and if you were to showcase your circuits to new audience they will understand it faster.

[Sad_Brother]

You think combinators with "else" would be more UPS friendly? Doubt it.
You think they would be more user friendly? Definitely not.

It's not a doubt but a fact. 1 combinator makes less cpu cycles than 2.

From another side combinator with "else" need more cpu cycles than without "else". And definitely not all combinators need "else".
It does not mean final circuit would use more cpu with "else". But things are not so simple as you think.

No comments on the code example?

Code example not fully relevant. Will answer later.

[Zaflis]

You're still not convinving on why the old system is better. The cpu cost you need to think from multiple perspectives, the else condition added to single combinator is trivial/nonexistent compared to all processing that goes on the complexity of another combinator entity. One with circuit connection on both ends. The devs are excellent at optimizing, but circuits can't be made as one entity same way as power grid because each condition is different. It's multiple tables, dynamic allocations and who knows... Even the cost of rendering the entity and wires.

[quyxkh]

Nobody who's built anything substantial with circuits is serously arguing they need changing.

I beg to differ.
there certainly are improvements that would save a lot of additional combinators and performance. E.g. Setting deciders to output a specific value instead of 1 or count, but that's off topic here.

I do that with a multiplier on the output, I've never seen it cause any problems, it seems to me you'd always be able to fold most of it into premultiplied constants elsewhere in anything bigger than a single constant calc like requester sizing. I'm just j.random.luser here but could you post an in-use blueprint where the extra combinator hurts? I mean, sure, there's plenty of places where you can imagine a one-combinator version of any two-combinator setup, but I think making any combined-operations combinator will just open up at least one more place where you could imagine a one-combinator version of a two-combinator setup, if it's not solving some actually intractable performance or design problem in a game situation what's the actual point? It could always get incrementally easier. when does that stop being enough of a reason? It has to stop some time, right?

The op's change wouldn't save much and like steinio said can already be nicely implemented with 2 deciders.

Exactly.

[pleegwat]

What I suspect would give more benefit is being able to specify everything/anything/each inputs limited to a specific (red/green) input contact, which would increase flexibility when processing many signals in parallel since emulating a computation like (green * red) will take several combinators and be non-obvious.

As I recall, emulating (green * red) takes the form of ((((green * green) + (red * red)) * -1 + ((green + red) * (green + red))) / 2), or 5 arithmetic combinators (since addition is free).

However I have no idea how often such constructs are actually needed in real factories.

[Joe78man]

I can't understand why arguing against the if-else logic. It's actually the 2nd thing I tried while starting with circuits. I's basic logic, I was surpised there is no circuit machine that does that. Yes, it can be done with 2 deciders, but the user are wider with the else option.
I can understand that this game does not offer it, and that there are ways to achieve it, what I see ilogical is to deny the usefullness, that's being stubborn

A year later, still valid point

[ssilk]

I think hat you forgot is, that the game little bit wired logic is part of the gameplay.

[CheeseMcBurger]

Can you show us what you want it for?

I don't have any immediate uses, but i might later.

[...] Nobody who's built anything substantial with circuits is serously arguing they need changing. [...]

And how do you know that? Does anybody who builds anything substantial report their experience directly to you? Are you the spokesman of the substantial Factorio players?

If anything, this just shows that you argument is so weak, that you try to give it some weight by imagining, that everyone else agrees with you.

But back to topic. An else statement to th decider combinator would simplify certain builds by saving wires and combinators, which would also make it use less space and look cleaner. So I support the suggestion.

+1