Rail signal circuit condition closed on "Everything =/= 0"

[youdoomt]

Rail signal won't open on: "Everything =/= 0", as shown below:

There is no signal provided, the constant combinator is for testing.

This is a problem because I'm trying to mitigate the closing of the station to be closing of the signal, for some train related issues.
Stations setup (that works):


In my mind it would make sense, that the rail signal would open, if there is no circuit signal at all(as there are not in the setup atm).

[Shokubai]

Had to go prove this to myself... != 0 is broken. <= 0 works.

1.png (225.82 KiB) Viewed 6078 times

2.png (235.15 KiB) Viewed 6078 times

[Loewchen]

Sounds correct to me, generally there is no condition where Everything != 0 could be false as any signal=0 is no signal.

[Aeternus]

You should use "Anything" instead of "Everything" in this case. Everything != 0 tests for all available signals, even if the amount of signals is 0. Anything != 0 requires at least one signal to be present for the condition to be evaluated. Assuming you're testing for cargo, "Anything > 0" should be equal to "Everything != 0".

[Shokubai]

Sounds correct to me, generally there is no condition where Everything != 0 could be false as any signal=0 is no signal.

But in my image 50 stone is not = 0 so shouldn't the signal be green?

[Loewchen]

Sounds correct to me, generally there is no condition where Everything != 0 could be false as any signal=0 is no signal.

But in my image 50 stone is not = 0 so shouldn't the signal be green?

You force close when the condition is met (which it is).

[Shokubai]

Sounds correct to me, generally there is no condition where Everything != 0 could be false as any signal=0 is no signal.

But in my image 50 stone is not = 0 so shouldn't the signal be green?

You force close when the condition is met (which it is).

Then why is this green? <>0 and <= would both be false in this case.

[Loewchen]

Then why is this green? <>0 and <= would both be false in this case.

The condition is false and the signal therefore is green.

[Shokubai]

My brain has farted. It's better now.

[Loewchen]

The best rules to help keep in mind how Everything and Anything work for me are:

• Anything is true when the first match is found.
• Everything is not true when the first non-match is found.

[youdoomt]

Sounds correct to me, generally there is no condition where Everything != 0 could be false as any signal=0 is no signal.

So by that logic Everything = 0 whould never be true, because: "any signal=0 is no signal."
So therefore the enabling of the train station would not happen, but it does!

Some math for proof

Everything != 0 === true (when no signal is applied)
<-> not(Everything != 0) === not(true)
<-> Everything = 0 === false (when no signal is applied)
Edit: removed a typo.

And it also goes against your other statement:

Everything is not true when the first non-match is found.[/list]

it never finds a "non-match" and therefore should be true, by that logic.

It's inconsistent And doesn't make sense!

So please it's a bug, or call it a consistency suggestion, if you still believe otherwise.

[pib]

There is more to this bug.

Everything >= 12 is true when there are no signals, even though any normal interpretation would be that no signal = 0. If you put 1 item in a chest, everything >= 12 will be false, but take the item out and it becomes true. That is clearly a bug.

I am forced to use Anything >= X instead and hope the wrong thing never makes it onto a belt instead of everything > x which would keep my belt working as expected even if a mixed up item came down the belt.

[Loewchen]

Sounds correct to me, generally there is no condition where Everything != 0 could be false as any signal=0 is no signal.

So by that logic Everything = 0 whould never be true, because: "any signal=0 is no signal."
So therefore the enabling of the train station would not happen, but it does!

This condition would obviously be true when you do not have a signal. I have not seen a circuit containing a station in this thread yet.
No idea what you consider inconsistent, you'll need to show the case you are talking about.

[youdoomt]

This condition would obviously be true when you do not have a signal.

Did you not look at my proof? (Which I just saw had a typo, sorry.)
It's Boolean algebra, and it (now) shows your two statements contradict each other.

I have not seen a circuit containing a station in this thread yet.

My second picture is of a train station.
I even wrote it was a station.

And I consider it being inconsistent with with underlying Boolean algebra.

[youdoomt]

And here we have a case of inconsistency.

anything everything.PNG (170.01 KiB) Viewed 6018 times

These are
Everything = 0
and
Anything = 0

So when applying Boolean algebra/logic on this:

If everything = 0 === true
then anything = 0 === true
but this is not the case.

[Loewchen]

You are still comparing against no signal which makes no sense what so ever because:

• Anything is true when the first match is found.
• Everything is not true when the first non-match is found.

Means that:

• any ANYTHING condition will always be false
• any EVERYTHING condition will always be true

which is completely consistent.

[youdoomt]

First, I'm comparing against no signal, because that's what I get out of an empty station, as we can't have a signal that is equal to 0.

But alright, the game logic is not based on Boolean algebra, While the operators are.

So while I try to be smart and use Boolean algebra to calculate how I set things up without using extra combinators, I have to use an extra combinator, because the games logic is not in line with Boolean algebra, even though it looks like it.

I guess I'll go to the suggestion board, and suggest this.

[pib]

You are still comparing against no signal which makes no sense what so ever because:

• Anything is true when the first match is found.
• Everything is not true when the first non-match is found.

Yeah, but what exactly is "No signal" other than a particular value the game chooses to define in a certain way? If I say "Iron plates > 0" and there is no iron plate signal, the game chooses to interpret "no signal" as meaning the condition is false; even if there is no number assigned to iron plates to compare it against (the 0 integer). But if I say "Everything > 0" and there is no signal, the game does not provide a definition where this is also false; even though once again there is NO REASON that this would not be axiomatic just like comparing no signal against 0 in the former case. As youdoomt also is trying to tell you; we disagree that the game represents this in an internally consistent way. You seem to be describing a bug as a feature; but I am fairly certain that everyone would find the opposite axiom more logical and useful.

[TruePikachu]

I believe the signals are internally tracked in a 1-dimensional array indexed by the signal's internal ID number; as a result, the only way to not have a signal present is for the associated value to be zero. This also defines the inverse relationship: if a signal is zero, it is treated as though it doesn't exist. The only downside to this implementation is that it is not possible to have a zero-valued signal present, but that can only really cause annoyances with, you guessed it, the "Everything" and "Anything" virtual signals; everything else treats the absence of a signal as a zero signal. The additional memory consumption and CPU time required to allow for zero-valued signals does not justify their inclusion.

While there's an inconsistancy between "Everything" (similar to the Lisp function #'EVERY) and "Anything" (similar to the Lisp function #'SOME), this has always been the case, even outside of Factorio. As a rule of thumb, a zero-argument AND (as used by "Everything"/#'EVERY when there are no signals) always returns TRUE, and a zero-argument OR (as used by "Anything"/#'SOME when there are no signals) returns FALSE:

Code: Select all

(and)  ==> T ; T ≡ True
(or)  ==> NIL ; NIL ≡ False

(every #'plusp '())  ==> T ; "Everything" > 0 -- passes with no signals
(every #'plusp '(1 2))  ==> T ; Signals with values of 1 and 2
(every #'plusp '(1 -2))  ==> NIL ; Signals with values of 1 and -2
(every #'plusp '(-1))  ==> NIL ; Signal with value -1

(some #'plusp '())  ==> NIL ; "Anything" > 0 -- doesn't pass with no signals
(some #'plusp '(1 2))  ==> T
(some #'plusp '(1 -2))  ==> T
(some #'plusp '(-1))  ==> NIL

Another way of logically explaining the inconsistancy is that "Everything" is true if no signals fail the condition, while "Anything" is true if some signal passes the condition. If there are no signals, then nothing can fail the condition -> "Everything" is true. If there are no signals, then nothing can pass the condition -> "Anything" is false.


I close this reply with a quotation from the CLHS page on #'EVERY and #'SOME:

every returns false as soon as any invocation of predicate returns false. If the end of a sequence is reached, every returns true. Thus, every returns true if and only if every invocation of predicate returns true.

some returns the first non-nil value which is returned by an invocation of predicate. If the end of a sequence is reached without any invocation of the predicate returning true, some returns false. Thus, some returns true if and only if some invocation of predicate returns true.

(Where predicate is the condition being checked, and sequence is the list of nonzero signal values.)