[0.13] Train conditions don't follow Boolean precedence

[siggboy]

As discussed here: viewtopic.php?f=18&t=29237

If you have a set of circuit conditions in the train schedule of the form

a AND b OR c AND d

then the statement should evaluate to TRUE if "a AND b" is true (regardless of "c" and "d"). However, it does not ("d" has to be true, which is incorrect behaviour).

Boolean precedence order is not followed correctly (the conjunction "AND" must have higher precedence than the disjunction "OR", like in all programming languages and in predicate logic).

[kingarthur]

i also ran a couple more tests. all and statements must be true for the train to run. only 1 or statement must be true no matter what order and amount of statements you add to the list.

[siggboy]

i also ran a couple more tests. all and statements must be true for the train to run. only 1 or statement must be true no matter what order and amount of statements you add to the list.

picard-facepalm.jpg (4.97 KiB) Viewed 6689 times

Judging from these forums, probably 90% of Factorio players are IT people or engineers. Probably 100% of the players who'd even attempt a train schedule with multiple conditions are computer programmers.

Please bring this in line with common conventions

(An alternative would be to change the way the conditions are presented: "necessary conditions" and "sufficient conditions", or some other wording; but I doubt it would make it easier to understand. Right now, with the choice of "AND" and "OR" in a simple list, one simply has to suppose it's using Boolean precedence rules.)

[Rseding91]

Nobody ever said the train conditions follow boolean precedence. They do a simply top->bottom accumulation of comparisons.

[siggboy]

Nobody ever said the train conditions follow boolean precedence. They do a simply top->bottom accumulation of comparisons.

Yes. Do you think that is good, or intuitive, or easily understood from the UI?

Pretty much everybody who knows about boolean logic will look at the train schedule UI and assume it uses boolean precedence rules (not least because of the uppercase keywords AND/OR). The way it actually behaves goes contrary to that, it looks like a bug. (My personal take is that it's Just Wrong.)

[nonstickfrypan]

I didn't even know there was a formal precedence for boolean operations without using parenthesis (yes, of course there are in programming languages etc but these are convention rather than anything formal). That said, I would have assumed that in a game there would be some kind of rule and bottom to top would not have been my first intuition (I would have guessed, if I'd been asked to guess, that it would have been top to bottom/left to right).

[siggboy]

Boolean operations are a mathematical formalism, and of course there are precendence rules. The formalism would be incomplete without them.

Like the precendence rules for integer arithmetics: Parentheses, Exponents, Multiplication, Division, Addition, Subtraction (Please Excuse My Dear Aunt Sally).

It's just that a lot more people know these than the boolean rules (which are similar). If the train station did multiplication and division and violated those rules, everybody would have problems using the system. This is exactly the problem with the current implementation -- it breaks the rules that we know.

That said, I would have assumed that in a game there would be some kind of rule and bottom to top would not have been my first intuition (I would have guessed, if I'd been asked to guess, that it would have been top to bottom/left to right).

It's not "bottom to top". It's actually completely messed up: for the composite condition to be true, either ALL of the "AND" rules have to be true or ANY of the "OR" rules. The "OR" rules are "sufficient conditions" by themselves, and the "AND" rules are each "necessary conditions", for the composite "AND" rule that they form, which is a "sufficient condition". If that confuses you, it's because it is confusing.

If the current behaviour is kept, then at least the UI should be changed to better explain what is going on. The keywords "AND" and "OR" definitely have to go because they suggest that Boolean precedence rules apply.

[siggboy]

Nobody ever said the train conditions follow boolean precedence. They do a simply top->bottom accumulation of comparisons.

After some more investigation, it seems that the evaluation is in fact from bottom to top (not top -> bottom), and the result of the expression is compounded along the way (what you've probably meant by "accumulation").

I'm guessing it's some sort of linked list or array that you're iterating over while accumulating the result, and then shortcutting after "OR" and continuing after "AND". Whatever.

Please at least traverse the list from top to bottom (bottom -> top must surely be an implementation error, or it looks like bot->top but is indeed top->bot with some less than obvious parenthesizing), it'll still be very arcane but maybe make sense to 1% of the players instead of only 0.1% (estimated).

[BlakeMW]

If the current behaviour is kept it would be helpful to segregate AND or OR commands, such as the AND commands coming first, then a horizontal bar, followed by OR commands. It would make it visually clearer how the internal logic works.

[siggboy]

That's not how the internal works, sadly. The "AND" and "OR" conditions belong in a list, but from the keywords it's not clear how the list is evaluated. If you'd segregate them (as I've suggested earlier, too), that would also make no sense (I assumed the system works differently).

We've actually worked it out in another thread, but it's certainly difficult to explain in few words, and impossible to explain in a tooltip or any short in-game description.

[nonstickfrypan]

Boolean operations are a mathematical formalism, and of course there are precendence rules. The formalism would be incomplete without them.

Can you show me where these precedence rules are formalised? Because, quite honestly, (outside of programming languages) you generally use parenthesis to save confusion and I've never seen a formal set of precedence values. See: https://en.wikipedia.org/wiki/Logical_c ... precedence

However, not all authors use the same order; for instance, an ordering in which disjunction is lower precedence than implication or bi-implication has also been used.[16] Sometimes precedence between conjunction and disjunction is unspecified requiring to provide it explicitly in given formula with parentheses. The order of precedence determines which connective is the "main connective" when interpreting a non-atomic formula.

In my book that is *not* formalised.

[siggboy]

The formalism would be incomplete without them.

Can you show me where these precedence rules are formalised? Because, quite honestly, (outside of programming languages) you generally use parenthesis to save confusion and I've never seen a formal set of precedence values.

That's correct, so let me put it another way:

If you can not use parentheses, then the expressions are ambiguous if you do not know the precedence rules.

We can not use parentheses in the train schedule, so there must be precedence rules, otherwise the formalism for "train station conditions" would be underspecified (of course it is underspecified because the algorithm in effect is nowhere near obvious to the player).

(Even in math, if you gave a Boolean expression to somebody who knows what it is, and you left away the parentheses, probably almost everybody would expect && to take precedence over ||; the smart people would point out that your parentheses are missing and your expression might be considered ambiguous without assuming certain rules.)

By FAR the most common case for Boolean expressions to be used in practice (outside of math/academics) are programming languages. Again, by FAR the most common of these programming languages are C(++), Java, JavaScript, Python, younameit. All of them give "AND" precedence over "OR". Other cases might exist, somewhere, but there is not a programming language on the planet with more than 5 users that gives OR precedence over AND in an unparenthesized expression.

[golfmiketango]

I don't think it's even documented, much less formalized. I'm sure many people have paused a moment to ponder this question before they were distracted by something or another such as a giant green tentacled cockroach-monster screaming bloody murder while eating their car.

In other words, I'm not sure anyone has found the time to answer the question scientifically just yet. I'm sure whoever does deserves a small moment of praise and glory before they are sent back to the fucking coal mines

[dee-]

Just see Boolean algebra (axiom 5, distributivity).


Edit: gosh, siggboy is right; disregard above as indicative, it's a nice read anyway

[siggboy]

Distributivity has nothing to do with this.

The operator precedence is there to decide if "a || b && c" means

"(a || b) && c" ["c" must be true for the expression to be true, "a" is not sufficient]

or if it means

"a || (b && c)" ["a" is sufficient]; this is the variant that practically all programming languages use ("and" takes precedence over "or"). This one also allows for "shortcut evaluation", that means that if "a" is true you don't have to evaluate the rest of the expression.

Distributivity applies in both cases, so that the first variant is equivalent to "(a && c) || (b && c)" and the second variant is equivalent to "(a || b) && (a || c)" -- but which variant is correct is not decided by distributivity laws, but by the implicit parentheses from the operator precedence.

[Zeblote]

Nobody ever said the train conditions follow boolean precedence. They do a simply top->bottom accumulation of comparisons.

Does this mean the condition he wants to create

(a AND b) OR (c AND d)

is actually not possible at all as you can only make

((a OP b) OP c) OP d

conditions? Why would it be set up like this?

[siggboy]

Why would it be set up like this?

Because it's easier to implement, maybe. Reworking this into something that makes sense for the player is not a quick fix, I guess they'd at least have to rewrite the code that does the evaluation.

In a "proper" implementation any "OR" condition could short circuit. I guess it wouldn't be hard to implement it that way.

No matter how you implement it, though, as long as you don't allow explicit parenthesizing in the train schedule, there will always be expressions that you can not formulate without using circuits outside of the train station (and that's only if all the parts of your expression are circuit conditions).

[Aatch]

Nobody ever said the train conditions follow boolean precedence. They do a simply top->bottom accumulation of comparisons.

Could you please elaborate on this? What does "Top->bottom accumulation of comparisons" mean. The only reasonable interpretation is that

Code: Select all

a OR b OR c AND d

is evaluated as

Code: Select all

(((a OR b) OR c) AND d)

. Which is fine, but certainly not obvious from the interface or anything I've seen anybody say about them.

On another note (and this is more of a suggestion), it would be nice to be able to explicitly group wait conditions together to help avoid this kind of thing.

[siggboy]

Code: Select all

(((a OR b) OR c) AND d)

Which is fine, but certainly not obvious from the interface or anything I've seen anybody say about them.

In this thread: 29237 we spent quite a lot of time working the above out.
I would agree with you that it's not obvious at all from the user interface. I would not agree with you in that it's "fine" .

On another note (and this is more of a suggestion), it would be nice to be able to explicitly group wait conditions together to help avoid this kind of thing.

I'm guessing because this significantly complicates the user interface, the simple approach that we currently have has been taken.

[golfmiketango]

Code: Select all

(((a OR b) OR c) AND d)

Which is fine, but certainly not obvious from the interface or anything I've seen anybody say about them.

In this thread: 29237 we spent quite a lot of time working the above out.
I would agree with you that it's not obvious at all from the user interface. I would not agree with you in that it's "fine" .

Good to know, and yeah, kinda an unfortunate choice, since I'm pretty sure there are certain compound disjunctive conditionals this won't allow us to construct.