[0.12.27][Twinsen] Combinator strange behavior - 3

This subforum contains all the issues which we already resolved.
XKnight
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

[0.12.27][Twinsen] Combinator strange behavior - 3

Post by XKnight »

I think you will understand the problem by yourself... (hint: first and second)
1.png
1.png (280.15 KiB) Viewed 7397 times

DevilXD
Fast Inserter
Fast Inserter
Posts: 213
Joined: Tue Aug 12, 2014 10:47 am
Contact:

Re: [0.12.27] Combinator strange behavior - 3

Post by DevilXD »

Umm...

Image

Where is it not right ?

XKnight
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: [0.12.27] Combinator strange behavior - 3

Post by XKnight »

XKnight wrote:Thanks a lot,

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

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

User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3601
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: [0.12.27] Combinator strange behavior - 3

Post by DaveMcW »

There is still a 0-signal bug with arithmetic combinators.
Attachments
any-bug.jpg
any-bug.jpg (338.13 KiB) Viewed 7375 times

DevilXD
Fast Inserter
Fast Inserter
Posts: 213
Joined: Tue Aug 12, 2014 10:47 am
Contact:

Re: [0.12.27] Combinator strange behavior - 3

Post by DevilXD »

XKnight wrote:
XKnight wrote:Thanks a lot,

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

Image
Twinsen wrote: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
Factorio Staff
Factorio Staff
Posts: 1239
Joined: Tue Sep 23, 2014 7:10 am
Contact:

Re: [0.12.27] Combinator strange behavior - 3

Post by Twinsen »

DevilXD wrote: 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.

User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3601
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by 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
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by XKnight »

DaveMcW wrote:I prefer zero signal == no signal.
+1 for this choice

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12678
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by 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 :) )
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

DevilXD
Fast Inserter
Fast Inserter
Posts: 213
Joined: Tue Aug 12, 2014 10:47 am
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by DevilXD »

DaveMcW wrote: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
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: [0.12.27] Combinator strange behavior - 3

Post by XKnight »

DevilXD wrote:
XKnight wrote:
XKnight wrote:Thanks a lot,

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

Image
Twinsen wrote: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
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by 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.
Last edited by XKnight on Mon Mar 21, 2016 9:10 pm, edited 1 time in total.

XKnight
Filter Inserter
Filter Inserter
Posts: 329
Joined: Thu May 28, 2015 10:40 pm
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by XKnight »

DevilXD wrote: 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

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12678
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by ssilk »

Did anybody read my post? I really think it would solve the described problems....
(hope so :) )
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3601
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by DaveMcW »

XKnight wrote: 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. ;)

User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3601
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by DaveMcW »

DevilXD wrote: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
less-than-4.jpg (263.74 KiB) Viewed 7116 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
Factorio Staff
Factorio Staff
Posts: 1239
Joined: Tue Sep 23, 2014 7:10 am
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by Twinsen »

DaveMcW wrote:
DevilXD wrote: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
Factorio Staff
Factorio Staff
Posts: 1239
Joined: Tue Sep 23, 2014 7:10 am
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by 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.

User avatar
tehroach
Fast Inserter
Fast Inserter
Posts: 128
Joined: Mon Feb 01, 2016 11:04 am
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by 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
Fast Inserter
Fast Inserter
Posts: 212
Joined: Wed Apr 13, 2016 11:31 pm
Contact:

Re: [0.12.27][Twinsen] Combinator strange behavior - 3

Post by 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.

Post Reply

Return to “Resolved Problems and Bugs”