[0.15.32] Empty chest incorrectly evaluates inserter logic

[notsew93]

Summary: The inserter with enabled condition: Everthing>3000 incorrectly evaluates to true when the chest is empty, causing the inserter to remove the first item placed in the chest.

1. What I did:
I set up a system with inerters, the circuit network, and the logistic network as in the screenshot.

The Idea is to draw items in when low, and emit them when they are too high, with the filter inserter connected to my "sorting belt".

In the center is a Passive Provider Chest.
The Fast Inserter on the left, which puts items from the belt into the chest, is set only to enable/disable from the circuit network, not to read hand contents. The enabled condition is Everything<2000.
The Fast Inserter on the top, which puts items from the chest onto the belt, is set only to enable/disable from the circuit network, not to read hand contents. The enabled condition is Everything>3000.
The Filter Inserter on the right, which pulls items from the belt into the chest, is set only to set filters via the circuit network, not to read hand contents or enable/disable.
The Chest and three inserters are connected to each other to make a small isolated circuit network, using the red wire.

2. What Happened:
When the chest is empty, the top inserter evaluates "Everything>3000" to be true. As a consequence, it will remove items from the chest as they are put into it, preventing the items from staying inside and accumulating.
The inserter on the left will grab an item from the belt, and put it into the chest. The top inserter will grab the item before it's logic condition is checked again, removing the item from the chest and places it onto the belt.

3. What I expected to happen:
I expected that the top inserter's logic condition of "Everything>3000" to evaluate to false when the chest is empty, or has a null item list or whathaveyou.
If the top inserter was disabled on the empty chest, it wouldn't remove the first item placed in the chest. Removing the first item placed in the chest is unexpected because the inserter was active when there were fewer than 3000 items in the chest.

If there is more than one item in the chest, everything works as expected.

[SteelWolf300]

This is not a bug.

It happens for 2 reasons :

• the "Everything" signal does not work as you think it works
• there is 1 tick of delay between the insertion of the item and the processing of the signal

the "Everything" pseudo-signal apply independently to every signal that is present (AKA ≠ 0). So, when there is no signal, everyone of them verify the condition.
This is the same as why "∀ x∈∅, P(x)" ("for each x in the empty set, the property P of x is true") evaluate to "⊤" ("True"), no matter what P is.

Basically, what you meant: "sum(S)>3000", and what it actually is: "∀ x∈S, x>3000" (S for the set of active signals).


Here are some alternatives you could do to solve your problem :

• SIMPLE SOLUTION: Check "Read hand contents" then "Hold" in the inserters that fill the chest (it will anticipate the 1 tick delay).
  It will work fine with 1 type of item, and require very few modification.
• BETTER SOLUTION: sum the signals from the chest with a combinator. You can do this in many ways, for example with an Arithmetic combinator configured to "Each+0" and outputing to the A signal. then use "A<2000", "A>3000" in the inserters config.
  
  (I used an other way to sum the signals; the idea is to output the signals to the same one without modifying them, they cumulate at the end)
• EVEN BETTER: Both at the same time. Require 2 wire colors to avoid making a loop.
  

[Loewchen]

See: viewtopic.php?f=23&t=49125, if you still think there is a something we missed, post the save.

[notsew93]

Alright, thanks guys.

I suspected that the Everthing operator might not work on null sets, but since we cannot have a "zero" signal in the game I had expected the game to treat nulls as zeros, even though they are different things in computer speak.

Checking for null in this sort of thing may have been voted against because it is an extra "check" or computer operation, and the devs are big on computing efficiency. But, as I see in the link that Loewchen provided other users expected the same "null counts as zero" behavior that I did.

[posila]

Checking for null in this sort of thing may have been voted against because it is an extra "check" or computer operation, and the devs are big on computing efficiency.

Extra check operation is not the reason.

"Everything" signal behaves as universal quantification
"Any" signal behaves as existential quantification