x < N, anything/everything. Real math or "Factorio" math?

[zOldBulldog]

Consider the equation x < N, where N is a constant.

- In normal math, if x is 0 or does not exist the equation is true.

- In Factorio math, if x is a specific item signal (like a belt, assembler or any other item) the equation is also true.

But once you go generic and use anything/everything signals, if a signal exists and is zero the equation is true, but if there are no signals at all... the equation becomes false.

This is completely counter-intuitive and feels wrong. Is there a logical reason to make no signals at all = false for x < N in Factorio? If yes, what is it? Or should this behavior be changed to match normal math expectations?

[Arzorth]

For me it was counter-intuitive too at the beginning but if you think about it, if anything signal is true when there is nothing of an item, it will be true always, because it is almost impossible to have one of every item.

Lets see an example with your proposed logic:

-You configure a condition (anything) < 20.
-There is no items, so under your reasoning it should be true.
-You introduce items, lets say 20 belts, condition should be false because 20 belts is not lower than 20. But what about bullets? There are 0 bullets in your chest, should the output signal be true? The same with the rest of items.

The real behaviour is:

-You configure a condition (anything) < 20.
-There is no items, so output is false.
-You introduce items, lets say 10 belts, output is true.
-You introduce 10 more belts, output changes to false.
-You introduce 1 bullet, output changes to true cos there is at least 1 item that matches the condition * < 20.

I hope it helps you to understand the logic

[zOldBulldog]

@arthoth,

I totally understand the logic of how it behaves today, and I can do one better as I understand that they are really measuring signals and that is clearly why it behaves the way it behaves.

Of course they made an exception for the specific item test when there is no signal for that item.

I even agree that the behavior is valid (according to normal math) if there is even a single signal of any kind on the wire.

So, all I am saying is that they need to treat anything and everything the same way as they treat a single item... In the very specific case where there are no signals *of any kind* on the wire (no signals at all = same as if all the signals are zero, same as today if even one signal has a value) In other words anything and everything should apply to the items for which there are signals.

So the scenario where you have 10 of one item and 20 of another would be false, just like now, and is false even if you apply normal math.

So, while I understand what they are doing, the question is WHY did they choose to do it this way , deviating from normal math? Oversight? Laziness? Or if there is a good reason for it... What is the reason?

[DaleStan]

In Factorio, there are two different ways you can look at the wires:
- All signals are always present on all wires. (The UI chooses not to display the signals with a value of zero.)
- It is not possible to express a zero-valued signal; all signals must have a non-zero value.

Because "Any < 100" would be useless if it took the first view, it takes the second view instead. It sees a wire that has no signals, and we have:

- In normal math, if I have no items of a certain type, I also have no items of that type that satisfy an additional condition.

The 'Any' pseudo-signal asks about items of the type 'signal'. If I have no signals, I also have no signals that are less than one hundred.
In the same way, if I were to have no computers, I would also have no computers with an Nvidia card, and if I had no cats, I would also have no cats less than 100 days old.

[zOldBulldog]

In Factorio, there are two different ways you can look at the wires:
- All signals are always present on all wires. (The UI chooses not to display the signals with a value of zero.)
- It is not possible to express a zero-valued signal; all signals must have a non-zero value.

Because "Any < 100" would be useless if it took the first view, it takes the second view instead. It sees a wire that has no signals, and we have:

- In normal math, if I have no items of a certain type, I also have no items of that type that satisfy an additional condition.

The 'Any' pseudo-signal asks about items of the type 'signal'. If I have no signals, I also have no signals that are less than one hundred.
In the same way, if I were to have no computers, I would also have no computers with an Nvidia card, and if I had no cats, I would also have no cats less than 100 days old.

As you correctly indicate (and I didn't consider earlier), the Factorio implementation treats "no signal" as a "zero signal". You can see this by using a constant combinator and generating green=0 with a constant combinator... nothing shows on the wire, while if you generate green=1 or higher you see a value on the wire.

That is all perfectly fine and does not interfere with anything. For example, if you set Beacon = 0 in a combinator, and then use Beacon < 100 the condition returns true.

The problem is with how Any/Every handle 0:

- If there is at least a signal with a value, it evaluates the value(s) and decides whether Any/Every < 100 is true... for the signals present. That is exactly as expected, in both normal and Factorio math.

- But if there are no signals at all, which in Factorio terms means that whatever is setting those signals is setting them as 0... it evaluates as false. But since it *means* 0 < 100 then it should be true.

Among other things this is why you can't use an Any/Every condition on an inserter to limit a chest content. If the content goes over 100 it correctly stops the inserter, but if the content goes to 0 it also stops the inserter and prevents it from ever inserting anything again.

The solution is simple and obvious, the condition for Any/Every needs to treat "there are no signals of any kind" as a value of zero for the variable in the condition. You don't put any new signlas on the wire, you adjust the condition evaluation formula.

---

So far every reply has been "this is how it works" or "this is how it works if you only consider the possibilities of putting signals on the wire or not putting signals on the wire", but none has explained WHY it was made this way.

More specifically WHY Every/Any don't treat "there are no signals of any kind on the wire" as zero in the equation... as it does for specific signals like Beacon or Rail?.

[posila]

You are confusing "real math" with common sense.

Signal anything is existential quantifier and signal everything is universal quantifier.

In logic, "All my cats are less then 100 days old" is true when I don't have any cats, while it could be considered false by common sense because I don't have any cats. On the other hand, "There exists a cat that is mine and is 100 days old" is false.

[zOldBulldog]

You are confusing "real math" with common sense.

Signal anything is existential quantifier and signal everything is universal quantifier.

In logic, "All my cats are less then 100 days old" is true when I don't have any cats, while it could be considered false by common sense because I don't have any cats. On the other hand, "There exists a cat that is mine and is 100 days old" is false.

Got it and taking it as the official answer as you seem to be staff by your tag color:

Factorio implements logic constructs but does not follow the logic rules... since in Factorio "All my cats are less than 100 days old" is false when you don't have cats.

I am also going to assume that this is intentional and not a bug.

Thanks for the reply. This settles it. Will adapt even though it feels so wrong to me (trained as a scientist and made a career in software development where logic is king), but I understand your choice.

[posila]

Factorio implements logic constructs but does not follow the logic rules... since in Factorio "All my cats are less than 100 days old" is false when you don't have cats.

As far as I know (and quickly tested just now), that is not correct. "Everything < 100" is evaluated to true when there are no signals on input (which matches "All signals are less than 100"), and "Anything < 100" is evaluated to false (which matches "Signal exists such that it is less than 100")

[zOldBulldog]

Factorio implements logic constructs but does not follow the logic rules... since in Factorio "All my cats are less than 100 days old" is false when you don't have cats.

As far as I know (and quickly tested just now), that is not correct. "Everything < 100" is evaluated to true when there are no signals on input (which matches "All signals are less than 100"), and "Anything < 100" is evaluated to false (which matches "Signal exists such that it is less than 100")

I must admit I am extremely puzzled.

- I tested yesterday and "Everything < 100" was being evaluated to false when there were no signals... just like Anything. Feeding a chest from an assembler with a condition on the inserter. If the chest emptied it would not be fed ever again because there was no signal.

- I just retested and indeed Everything is working correctly now.

Either something changed or (more likely) I made a mistake testing.

[BlueTemplar]

Damn, ninjaed.
And Everything works indeed well for limiting chests.
(And the tooltip describes their behaviour when no inputs.)

Btw, any reason why a red/green * is used as an icon instead of ∀ / ∃ ?
I've wanted to do this for a while, so :

[Qon]

It's a bit weird when 0 doesn't exist. Anything < 5 is true when fed an iron plate signal of 1 or -1, but false when the iron plate signal is 0.
So 0 > 5.
Anything > -5 is true for iron plate -1 or 1, but false for iron plate = 0.
So 0 < -5.

Or if you have a wire with 1 green, 2 red and 3 blue and do "Each -1" and then "Each +1" then you get 2 red and 3 blue as output. Because 1 - 1 + 1 = 0 in Factorio! Which means that 1 = 0 (every number is = 0 since X - X + X = 0 in Factorio).

Btw, any reason why a red/green * is used as an icon instead of ∀ / ∃ ?
I've wanted to do this for a while, so :

Have you released those as a mod yet or are you submitting them in hope of someone else doing it?

[DaleStan]

Anything < 5 is true when fed an iron plate signal of 1 or -1, but false when the iron plate signal is 0 not present.
So 0 > 5.
Anything > -5 is true for iron plate -1 or 1, but false when the iron plate = 0 is not present.
So 0 < -5.

FTFY.

If no signals are present, then no signals are present. You must have at least one signal present if you want the Any pseudo-signal to return true.

[Qon]

Anything < 5 is true when fed an iron plate signal of 1 or -1, but false when the iron plate signal is 0 not present.
So 0 > 5.
Anything > -5 is true for iron plate -1 or 1, but false when the iron plate = 0 is not present.
So 0 < -5.

FTFY.

If no signals are present, then no signals are present. You must have at least one signal present if you want the Any pseudo-signal to return true.

That was the point of the post.........

[Qon]

Btw, any reason why a red/green * is used as an icon instead of ∀ / ∃ ?
I've wanted to do this for a while, so :

Have you released those as a mod yet or are you submitting them in hope of someone else doing it?

May I present to you: The Mod That Makes Anything And Everything Better!

TheModThatMakesAnythingAndEverythingBetter_1.0.0.zip

(6.84 KiB) Downloaded 78 times

The name is a bit long but I like it. I actually spelt the name wrong at first, but thankfully I noticed it right before I uploaded. And the name is like half the mod....

With your permission, I'll go ahead and post it to the portal now. Or if you prefer, it can be your first mod posted to the portal

[BlueTemplar]

I was trying to see if anyone would care...

This is great, thank you !

I'll upload it.
(I have several unpublished mods because I never got around to do them "properly"... maybe now I will !)

I love the name !

Looks like that the only way to make a mod compatible across multiple major versions is to upload it on the portal several times, once for each ?

(P.S.: HandyHands is neat !)

[Qon]

I was trying to see if anyone would care...

This is great, thank you !

I'll upload it.
(I have several unpublished mods because I never got around to do them "properly"... maybe now I will !)

I love the name !

Looks like that the only way to make a mod compatible across multiple major versions is to upload it on the portal several times, once for each ?

(P.S.: HandyHands is neat !)

Glad you like it, and the name

Making funny names is always so satisfying when you find something with a double meaning or something that sounds funny when it's spoken out loud
And it's pretty silly how the mod name implies that it touches on absolutely everything in factorio when it is one of the smallest mods ever made!

I looked at the modding tutorial and found no info on multi version compatability for mods, and the mod api documentation doesn't even mention info.json at all even though it is the most important file of all... strange. It just skips over it completely

So set factorio_version to 0.16 and upload it and then set it back to 0.17 and make it "TMTMAAEB" v1.1.0 or something (this means you can maybe update to 1.0.x if you need to patch something for factorio_version 0.16 later). Because the portal might freak out if you upload a lower mod version number later or higher version number later but that has a lower factorio_version. Or skip 0.16 to not make it too hard on yourself.

[Nidan]

How about separating zero and unpresent signals from each other?

But I'd like if a distinction between "signal is zero" and "signal is not present" were added.
Most entities would continue to work as now
- Outputting a signal results in that signal being present
- Reading a signal that isn't present is treated as zero
For arithmetic (mainly the arithmetic combinator, but also the implicit add when merging cables), the result is present if at least one signal operand is present, except that division by zero should result in "not present".
For decisions there would be are two new tests: checking for the presence and absence of a signal. Output is present when condition is true.
All/Each/Any act on all present signals; as result "any == 0" is no longer a pointless test

The implementation could be a bitset, which should be both compact and efficient to update, as most operations will either output specific signals (machines, combinators not using "each"), forward the input set (arithmetic, decider with output "everything"), or or'ing multiple sets together (implicit add). Deciders using "each" would have to set each bit individually based on the condition, but compared to evaluating said condition setting the presence bit should be minor work.

[autopoiesis]

Imo, we should have two dual combinator symbols, one that is "for all" (or product or meet) and it's dual "there exists" (or sum/union or join). The "for all" signal would do what it says on the tin - it checks if all signals are less than N, and the "there exists" signal would check if there is at least one signal less than N. This would be much more intuitive than the "any" sign, which for some reason adds these signals together.

However, since changing the current functionality would be an issue and there is probably a reason these aren't included, I would at least suggest adding a new signal that would act as the dual to our current "any" signal. The "any" signal acts as a tropical product, and so we could fill in the cases where this signal doesn't work by adding the the tropical min-sum. That is to say, add a new combinator symbol "min", that selects the minimum of all signals. If there are no signals on min, then the condition is immediately false, and then change the current "any" signal that acts a sum to return true in these cases.

The fact that the default way to quantify over signals is tropically is one of the most frustrating things about combinator logic to me, but if this is the design decision, I think it would at least be best to have the dual quantifier as well.

[sparr]

Removed because I failed to read.

[zOldBulldog]

- But if there are no signals at all, which in Factorio terms means that whatever is setting those signals is setting them as 0... it evaluates as false. But since it *means* 0 < 100 then it should be true.

You've said a version of this multiple times now, and it's wrong.

One of any/every evaluates a lack of signals as true, the other false. This is described in the last line of the tooltip for the signal. If you want it to be true, use the other one.

This was resolved half a page ago.