Zero signal distinct from no signal

[Mimos]

I'd like to have a signal with a count of 0 that is distinct from not having a signal at all for making better use of anything and everything conditions.


The long story:
Right now [0.14] all unused signals are 0 by default. That way signals that are 0 are treated to as it they wouldn't exist, no matter the source of the signal. Testing some conditions with anything and everything this leads to some unpleasant behavior:

Anything:
Using a constant combinator to send a signal of -1 or 1 iron ore triggers an anything > -2 condition, sending 0 doesn't. Checking for iron ore explicitly triggers the condition in all three cases, though. So anything only checks for nonzero values, which propably is the expected behavior in most cases because otherwise anything < 1 or anything > -1 would trigger basically always. But sadly this breaks in cases where 0 is a relevant value.

Everything:
The conditions everything = 1, everything > 1 and everything < 1 are met at the same time, if no signal at all is set and also if some circuitry calculates all values to be 0.


Proposal
A zero-signal would not be sent if a empty chest was connected, it would have to be created explicitly, for example by
- using a constant combinator
- as a result of an arithmetric combinator (except when using each)
- as a result from having a red wire and a green wire as an input, one having the value x, the other having -x.
- In general when the components of a sum "cancel each other out"
- filter insterters could also output an explicit zero for their filtered items (when they are not holding any)
- requester chests for requested items (when empty)
- other chests are more difficult, though: maybe this could be added by allowing to set filters (like in cargo wagons).


Usage example:
So if I have a chest which usually contains stacks of different materials and I want to check if any of these materials is empty, I could connect a constant combinator and then send zero-signals for all relevant materials. Now I can check for anything < 1.
I'd prefer getting rid of the constant combinator by having chests with filters which are able to send zeroes, or some other way, though.


A workaround right now is using a constant combinator to set an offset so the condition can always check for positive or negative values, but I'd prefer not having to do that, especially in more complicated cases.


I hope this was not posted before, but sadly it seems to be impossible to search for the word "zero".

[DaveMcW]

viewtopic.php?p=138250#p138250

[Mimos]

Aah, thanks, I didn't search for bug reports, just for suggestions. I guess I'll have to use some workarounds then.

[bluegreen1024]

TL;DR

I would like an option to let the Circuit Network, specifically Combinators, reliably distinguish between a signal with value = 0 and a signal that is not present at all, because the current erasure of zero-valued signals adds significant extra complications to what should be basic math operations.

What?

My current experience with arithmetic, decider, and (with 2.0/Space Age) selector combinators is that they cannot be relied upon to actually output a signal whose value happens to be zero, and I would like it if this behavior were changed. For example, consider an arithmetic combinator that subtracts some value from incoming signals and outputs the results. If a result is zero, no signal is output, which means that the next combinator doesn't see that signal to operate on at all. I would like the first combinator to output a signal with a value of zero in this case, so that the next combinator can continue manipulating that signal. It would be fine with me if this were simply an optional checkbox on combinators, so that anyone who wants/needs the current behavior can still have it.

Why?

Zero is a perfectly legitimate value for inputs, outputs, and intermediate steps in many mathematical and logical operations, which is what combinators are supposed to be used for. Erasing signals with value = 0 makes basic operations needlessly difficult, requires multiple extra combinators and special case handling as workarounds, and breaks the analogy with "real-world" math or programming, leading to combinators being less intuitive than they could be. Tasks made more difficult include but are not limited to finding the minimum of two or more values, or correctly reading, comparing and manipulating item requests and item stockpiles.

[lindenk]

I was just about to post this exact suggestion. Looks like you beat me to it

[Koub]

[Koub] Merged into an older thread with the same suggestion - and a link to why things are the way they are.

[bluegreen1024]

My apologies, it looks like I didn't check far enough back when looking through the existing suggestions. I can only say that combinator and wire behavior has already changed substantially with 2.0, so I hope this gets re-evaluated someday (especially in light of Selector combinator's functionality) but if not or if it's low priority I understand.