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.)