[0.12.27][Twinsen] Combinator strange behavior - 3

[XKnight]

I think you will understand the problem by yourself... (hint: first and second)

1.png (280.15 KiB) Viewed 11398 times

[DevilXD]

Umm...



Where is it not right ?

[XKnight]

Thanks a lot,

Could you also check this build (just in case)?

Yes, it works after the fix, in the sense that nothing is outputted from the combinator.

[DaveMcW]

There is still a 0-signal bug with arithmetic combinators.

[DevilXD]

Thanks a lot,

Could you also check this build (just in case)?

Yes, it works after the fix, in the sense that nothing is outputted from the combinator.

But... It's just plain wrong - 0 is less than 100, so the condition is true and output is 1. IDK why developers changed that...

If you switch the output to the "Input Count", it should output nothing, right ?

[Twinsen]

But... It's just plain wrong - 0 is less than 100, so the condition is true and output is 1. IDK why developers changed that...

If you switch the output to the "Input Count", it should output nothing, right ?

In the previous bug report I decided to make "zero signal == no signal", for consistency and ease of understanding. But after seeing your post and your example, I really have doubts about what to do.

If anyone has any opinions on how you think this should be solved, now is the time to say.

[DaveMcW]

I prefer zero signal == no signal.

The problem is that putting multiple signals on a wire performs an addition that might equal zero. So you can't solve everything by filtering the output of combinators, you need to filter the output of the wire addition too. (Or filter the input of combinators.)

[XKnight]

I prefer zero signal == no signal.

+1 for this choice

[ssilk]

This is quite interesting and I have some stakes in here, cause this made me a lot of work (well it was some kind of fun, but...).

In Informatics I learned that there is a big difference between 0 (a zero value) and NULL (no value at all, or also an "unkown value").
In database this is for example the difference between an unknown street name and no / an empty street name (yes, there are addresses, that have no streets, which is quite legal). For the first state I have an illegal status for the address and need insist, that there is a street name input (even if it is empty then). Well, I'm sure NULL arithmetic also exists in C++, but I explain it also for the other readers. The point is: There are thousands of similar examples around, just want to mention that, to show, that this kind of logic works really well and is approved for more than 50 years.

In our case it is the difference between having a signal (with zero value) and no signal at all (an unknown signal / an empty or broken wire). (*)


So the keyword is in my eyes to differenciate between the signal and the value.


Which leads me to this: The combinator looks first, if the input signal includes his signal(s).

If YES, we can continue to calculate the result with the value. This is just as now and zero is just zero.
If NO, the result is also NULL, cause nothing can be compared/calculated then.



This 3-valued-logic is a bit strange to calculate, but in Factorio it already exists, it's just an empty wire vs. a wire with a signal, but no / zero value and a wire with a signal and a value. See also this fine article: https://en.wikipedia.org/wiki/Null_(SQL)

And technically I would compare SQL here really with Factorio, cause sometimes you need calculate a correct result, even if there is no input signal. That is the same in SQL as in Factorio....


(*) This is also the same case as the difference between having a connection (a wire exists between some entities) and no conncetion.

This last one has also another reason: Because you can never be 100% sure, that there is really a connection. For example the biters have eaten a pole and now my factory goes wild, because null === 0.
(that happened to me more than one time and it is currently really quite complicated to make a factory failsafe in a way, that it doesn't matter )

[DevilXD]

I prefer zero signal == no signal.

The problem is that putting multiple signals on a wire performs an addition that might equal zero. So you can't solve everything by filtering the output of combinators, you need to filter the output of the wire addition too. (Or filter the input of combinators.)

But consider this:

I set my factory to work only when signal 'A' is less than 4. Following the "zero signal == no signal" logic the result would be:

...
A = -2 = working
A = -1 = working
A = 0 = not working
A = 1 = working
A = 2 = working
A = 3 = working
A = 4 = not working
...

I know that all signals are zero by default, but, IMHO:

Sum of two signals that is equal to zero is still a signal, it's just equal to zero and should be displayed and processed like any other signal.

[XKnight]

Thanks a lot,

Could you also check this build (just in case)?

Yes, it works after the fix, in the sense that nothing is outputted from the combinator.

But... It's just plain wrong - 0 is less than 100, so the condition is true and output is 1. IDK why developers changed that...

If you switch the output to the "Input Count", it should output nothing, right ?

No, if we decide that "zero-signal != no signal", output will be "Blue 0".

[XKnight]

Imagine situation when you have a list of signals and want to remove one of them from this list
input: A, B, C, D, ...
signal to remove: C

zero signal == no-signal
just multiply C * -1 and add with the input.

zero signal != no signal
the naive approach is to filter signals using (Each > C) + (Each < C)
But this will also remove other signals that have the same value as C
As a result, you will have to add some huge value to C and use (Each < C)
This is a little bit tricky.

Second example:
You want to get information about the amount of repair packs in your outpost.

zero signal == no signal
If electric pole is destroyed you will receive the same output as in situation when you have 0 repair packs.
So you have to add some status signal which always will be set to "1".
This is also a little bit tricky.

zero signal != no signal
Nothing to worry about.

The last question is how will you distinguish zero-signal from null-signal?
Compare it with zero? but in current implementation null signal has the same value as zero-signal,
so check "C == 0" always returns true for zero-signal and null-signal.

In fact, you won't be able to detect that your outpost is disconnected without status signal.

Update:
Yes, you can make a check (Anything > 0, output 1) + (Anything == 0, output 1) + (Anything < 0, output 1) to detect that your outpost is alive, but this solution is even trickier than the previous. Also, in this solution each signal is used as a status signal.

[XKnight]

But consider this:

I set my factory to work only when signal 'A' is less than 4. Following the "zero signal == no signal" logic the result would be:

...
A = -2 = working
A = -1 = working
A = 0 = not working
A = 1 = working
A = 2 = working
A = 3 = working
A = 4 = not working
...

zero-signal == null-signal
you can subtract 4 from 'A', and use condition A < 0

[ssilk]

Did anybody read my post? I really think it would solve the described problems....
(hope so )

[DaveMcW]

Second example:
You want to get information about the amount of repair packs in your outpost.

zero signal == no signal
If electric pole is destroyed you will receive the same output as in situation when you have 0 repair packs.
So you have to add some status signal which always will be set to "1".
This is also a little bit tricky.

The status signal can simply be a constant combinator with repair pack = 1.

The tricky part is remembering to check for a missing signal.

[DaveMcW]

I set my factory to work only when signal 'A' is less than 4. Following the "zero signal == no signal" logic the result would be:

A = 0 = not working

Using the current logic of "zero signal == no signal",

A = 0 = working

less-than-4.jpg (263.74 KiB) Viewed 11131 times

The missing zero signal only becomes an issue if you are using a special signal: EVERYTHING, ANYTHING, EACH. But anyone with experience using the special signals knows how useful it is to completely remove a signal, which is much easier with "zero signal == no signal".

[Twinsen]

I set my factory to work only when signal 'A' is less than 4. Following the "zero signal == no signal" logic the result would be:
A = 0 = not working

Using the current logic of "zero signal == no signal",

A = 0 = working
The missing zero signal only becomes an issue if you are using a special signal: EVERYTHING, ANYTHING, EACH.

This^. For example if signal A is missing, it means signal A==0, so conditions like "if A==0" or "if A<4" will work as intended.
The only differences are with special signals. When EVERYTHING, ANYTHING, EACH are evaluated, any signal that is 0 is ignored. So for example if you have A=0, B=20, C=22. "If ANYTHING < 10" will be false because A=0 is skipped. Not a big deal but it could lead to some confusion.

[Twinsen]

None of the solutions are perfect, but in the end I kept "zero signal == no signal".
So I fixed the situation mentioned by this report and the one posted by DaveMcW. Thanks for the reports guys, as usual let me know if you find more.
You will see them in version 0.12.29.

[tehroach]

I would have to agree with Ssilk on this one, you guys are trying to make oranges out of apples.

The only reason that C++ has a NULL values is to be backwards comparable with C; a language who's compiler roots come from back in the days when Zeroing a memory address could actually be considered an over head.

Think of the more modern standards ie C##; all memory addresses are Zeroed by default.
There is no reason that Circuit Networks in Factorio should differ from NULL an Zero both should be treated equally and just not appear in the list.

PS: Your if then else statement to check for broken power poles could be simplified by just having a constant combiner at the far end sending an unused signal and a light or combiner checking for that at the other end.
or running your circuit networks alongside your logistics networks so the robots can just automatically repair them.

[Aru]

I like programming, and I would vote with Ssilk and tehroach. For a system like this (that is, a system working with truly natural numbers), a deliberate 0 and an absent value shouldn't be differentiated. An empty chest, and no chest, both result in an empty sum. And an empty sum, is 0, like an empty product is 1. These signals are all numeric types, they shouldn't be allowed any non-numeric special values like 'null' or absent, that's unintuitive. And it's redundant with the signal feature. I'd rather use an alternate signal than rely on a special null value.