[0.12.27][Twinsen] Combinator strange behavior - 3

This subforum contains all the issues which we already resolved.
dee-
Filter Inserter
Filter Inserter
Posts: 415
Joined: Mon Jan 19, 2015 9:21 am
Contact:

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

Post by dee- »

OT:

Well' I come from a database view and there is "no value" something entirely different than "0".

"0" means specifically there are none of these but the question is valid, e.g. how many red Camaros came up the street in the last half hour.
"no value" is used where an answer is not appropriate or possible, e.g. how many pupils are in class 4f when there is no such class.

Being able to distinguish missing value from zero is a fundamental concept in databases and also in programming ("NaN", JavaScript "undefined", "none", etc.)

Both examples above could be applied to Factorio:
"How many Iron Plates are in the network"?
a) "0" because it's a valid item but not seen here
b) "no value" because there just are no such items in this network? Just because there is no class 4f here does not mean it's not possible to have one, just that the question did not apply in this instance.

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 »

dee- wrote:...
"no value" is used where an answer is not appropriate or possible, e.g. how many pupils are in class 4f when there is no such class.

Being able to distinguish missing value from zero is a fundamental concept in databases and also in programming ("NaN", JavaScript "undefined", "none", etc.)

Both examples above could be applied to Factorio:
"How many Iron Plates are in the network"?
a) "0" because it's a valid item but not seen here
b) "no value" because there just are no such items in this network? Just because there is no class 4f here does not mean it's not possible to have one, just that the question did not apply in this instance.
The first thing about "no such class", can't really apply here because you can't request a name (a signal) that doesn't exist. It's an error that's caught at the 'code editor' stage, before even compile time, because it's a restricted interface with exhaustive error handling. And in Python, there is a special value None, but it has a corresponding unique non-numeric type (NoneType). That could only correspond to an alternate signal. I tend to associate merging special values like NaN to the exclusion of true numeric types with things like symbolic math engines. Python doesn't have any of these special null/NaN/infinite values in it's numeric types, they are pure, even all the way up to it's built-in complex type. And yet it gets along beautifully, they are never missed by anyone, despite being an extremely high level language. Instead, when a numeric operation is called that can't produce a number, it simply throws an error. Python has a great aversion to any form of redundancy in it's design, and this simplifies everything, adds great elegance.

Maybe I'm missing something, but what would be the advantage of a special null-like value? How could it be used? And when would 0 or null be produced? Everything is null (that is, everything is not 0) unless a combinator expressly puts out a 0 on a specific signal? That leads to such unintuitive and inconsistent behavior when performing comparisons like is equal, is greater than, etc. And what happens when you compare this non-number with another number? Does it propagate with higher priority, like an error value, so that the result is also null? Where do you find a null constant, for use such as "is equal to null", so that you might catch it and end the propagation, or make some other deliberate use of the null value?

And in deliberate uses, how might the special value be better than using an alternate signal? I know there are at least a hundred of them. Non-numeric values, in this context, seem unnecessary and complex. I think, the game should strive to treat this subject consistently, where all 0 values are omitted from the display when you select a combinator, and there is no distinction between 0 and 'absent'.

To me, this behavior would be expected, easily understood, tolerable, predictable, intuitive, perfectly okay in every way:
if Everything = 0, Output 1 on Everything
Then, all channels (yes, all of them, but they won't all fit in the window) show a 1 when you hover over the decider, and nothing is connected to input. But currently, this is not what it does. It produces nothing according to rollover or via testing with a lamp. To me, that is unintuitive, unexpected, inconsistent, because connected to the input, there is exactly 0 of every item. That is, there are no items connected to it's input, there's no circuit connected. Already at this point, if I were a new player, I would be taking on a hint of frustration at this somewhat peculiar and exceptional behavior which I would then have to exhaustively test at length in order to properly understand. There's still a lot of behavior that doesn't make sense. (Everything > 0, lamp turns on; Inserter > 0, lamp is off? Unintuitive.) I might get bored before I finish, and lose out on a feature with a lot of potential. But, if it actually output 1 on every signal, I would think, great! it's working. Now I can do fun things with circuit networks, because I can understand them.

(Perhaps, if there is any problem or ugliness with putting out a 1 on every possible signal, the problem is with the design of the display, the interface, not with the behavior. That behavior would be perfect! Then, effecting this improved behavior should not be delayed merely to wait on the interface improvement. You don't keep one bug, to make another bug less noticeable. Then neither one gets fixed. Not that these are bugs, but you get the idea.)

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 »

dee- wrote:OT:

Well' I come from a database view and there is "no value" something entirely different than "0".

"0" means specifically there are none of these but the question is valid, e.g. how many red Camaros came up the street in the last half hour.
"no value" is used where an answer is not appropriate or possible, e.g. how many pupils are in class 4f when there is no such class.

Being able to distinguish missing value from zero is a fundamental concept in databases and also in programming ("NaN", JavaScript "undefined", "none", etc.)
But is this fundamental concept valid in Factorio
ie
"Iron plates" is always valid question in Factorio,
"Uranium Ore" is not a valid question in Vanilla Factorio

The UI filters out valid and invalid questions by simply making invalid questions unaskable as their icons are just not present.

just because I didn't connect those last two poles and what I believe to be a single network is actually two networks is kind of my problem and easily solved with a constant combiner and a reserved signal (one that I know will not occur by itself)


dee- wrote:Both examples above could be applied to Factorio:
"How many Iron Plates are in the network"?
a) "0" because it's a valid item but not seen here
b) "no value" because there just are no such items in this network? Just because there is no class 4f here does not mean it's not possible to have one, just that the question did not apply in this instance.
OK assuming that NULL and 0 are NOT equal

I make a simple network ie smart chest connected to a power pole.
(as all possible signals should be NULL at this stage)
I then place X "Iron plates" in the chest,
(now all signals except Iron Plates should be NULL and Iron Plates should be X)
I then remove all the Iron plates from the chest
(now all signals except Iron Plates should be NULL and Iron Plates should be 0)
I then add a comparator to the network
If I then compare any two signals, other than Iron plates they will be equal, but if I compare Iron plates to any other signal they will not be equal.

What advantages does the NULL value bring?

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 »

Twinsen wrote: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.
But, this isn't the current behavior, at least not entirely. There are still these unintuitive (for players) non-numeric values creeping into what ought to be pure numeric types (the signals).
Aru wrote:... To me, this behavior would be expected, easily understood, tolerable, predictable, intuitive, perfectly okay in every way:
if Everything = 0, Output 1 on Everything
Then, all channels (yes, all of them, but they won't all fit in the window) show a 1 when you hover over the decider, and nothing is connected to input. But currently, this is not what it does. It produces nothing according to rollover or via testing with a lamp. To me, that is unintuitive, unexpected, inconsistent, because connected to the input, there is exactly 0 of every item. That is, there are no items connected to it's input, there's no circuit connected. Already at this point, if I were a new player, I would be taking on a hint of frustration at this somewhat peculiar and exceptional behavior which I would then have to exhaustively test at length in order to properly understand. There's still a lot of behavior that doesn't make sense. (Everything > 0, lamp turns on; Inserter > 0, lamp is off? Unintuitive.) ...
Clearly there is still a special non-numeric value in the signals, and it leads to other unintuitive behaviors, that turn people off of the most powerful features of combinators. Because it makes no sense.

Late edit:

Combinator behavior has changed, and I have also since done a more exhaustive analysis. There's no special values, at least not any more, only special consideration by special signals for values of 0. All signals default to 0. With Everything as input signal, inputs of 0 are considered True regardless of what the comparison says. So if one signal compares as True and the rest are all 0, then they are all True, thus Everything is True. And if all inputs are 0, then Everything is still True. Similarly, Each and Anything as signals consider inputs of 0 as False regardless of what the comparison says. If all inputs are 0, then Each is False and Anything is False.

Another way to look at it, is that all values of 0 are ignored or skipped over by the special input signals, meaning that you only have as many comparisons as you have non-zero inputs. Then the empty series I mentioned come into play. Everything performs a logical AND on it's results, so no input corresponds to an empty product, which is 1. Anything performs a logical OR on it's results, so no input corresponds to an empty sum, which is 0. Each without Each as output will produce a numerical sum; no inputs means an empty sum of 0.

I think, the name and color of the Everything output signal should be changed, because it's function is very different from the Everything input, which is a little confusing. The Everything input is an AND, the Everything output causes outputs to mirror the inputs. Maybe, it could be changed to "All"? It has more in common with the Each output than it does with the Everything input (because it doesn't combine things). However Each with Each as output is fine because they have similar functions.

Some tooltips would go a very long way toward teaching people how these things work.

Post Reply

Return to “Resolved Problems and Bugs”