[BLUEPRINT] Skip Boolean AND if one pure input is Not true

Hey there.
Following Scenario:

You have a boolean variable and a very very very heavy pure function that also returns a boolean.
The Boolean is set to false.
Plug the simple boolean into the first AND input and the heavy function into the second Input.

Execute the Graph and you’ll notice that the heavy heavy function gets executed.

An Example:Unbenannt.JPG

in this case the Last digit of Pi (lel) will always be calculated, even though it does not have to.

I’m no C++ expert, but I’m sure that && won’t execute anymore functions if one boolean gets false:

if( lightFunction() && heavyFunction())

in this example heavyFunction won’t execute if lightFunction() returns false.

I’d like to have this in blueprints.

The same can be done with OR. Since it will always progress if at least one is true.

So what you are basically asking for is hort circuit evaluation.
This has been discussed before.

One point agaist it might be that the AND operator’s behaviour wiuld then depend on the pure-ness of the operands.
Imagine at some point in your development, a pure function needs to become impure…
In your scenario above, you could also feed the first boolean through a second branch, comparing it to a static true/false. This way you could avoid evaluation of the second operand/function…

What’s the problem with impure?
Impure Functions get executed, no matter if it’s needed or not.

What do you mean here?

You need to change a lot of wiring around, if you change it as an afterthought…

Something like this.
Here you evaluate the second (heavy) condition only if the first one evaluates to true.
Kind of like splitting an “if (a && b)” into a nested if-then-else-if form.
Much cleaner and without the need to look up to what an AND node is connected to (puer/impure?) to know how it will behave.

^This can be a solution for some cases, but I wouldn’t say this is more readable. Imagine doing multiple heavy functions. Using a Branch for each function is a waste of space and instructions.

While it is indeed an additional node in the graph, a short circuit evaluating operator would do the same instructions internally.
So instruction wise its about the same…

I don’t see how short circuiting has anything to do with evaluating pure vs impure nodes. Perhaps I am missing something.

Impure nodes execute when the exec wire passes through them, and any outputs effectively persist during that frame (if not longer).
Pure nodes execute when a wire they output is needed for an input on an impure node.

Oversimplified, sure.

bool SomeResult = MyImpureFunction(Params in);

if (SomeResult && MyPureFunction())
    // some action

if(MyPureFunction() && SomeResult)
    //some other action

Yeah, you can break your code if you change a pure node to an impure node, but that is a drawback to BP, not a drawback to short circuiting. You’d run into the same problem currently. In fact, an impure node that returns a bool should return false if never called before (if everything in UE4 is zero filled), so the effect of changing a pure node to be impure should not be different just because short circuiting exists.

More lke this:

if (A == true)
     if (B() == true)
          //  heavy stuff

By using a second branch, you are making basicaly the pure function impure.
I somehow prefer that (sequential evaluation) over a context dependent AND operator…

Create a function.

Blueprint does need short circuit evaluation though. I find it a bit baffling that Select nodes evaluate all branches even though the condition dictates that only one branch would ever need to be.

Yeah I agree

Wow, yeah that’s new to me. I was always taught that the select node was more efficient than a branch, but based on this I guess that would be wrong probably about half the time.

Here I’m thinking I’m being smart avoiding branch nodes and I’m actually just wasting my time haha

Yeah the lack of SCE is confusing at best, harmful at worst. However it’s also been discussed for a while now… Blueprints just don’t do it, they evaluate all branches on everything.

Wait, does this make the BP “AND” a “&”, not a “&&”, or is it just the way BP treats function nodes?

Exactly, it is a & and | respectively

You’d be wrong every time! Due to the way it’s implemented, a select node can never be more efficient than a branch.

That’s crazy! Thanks for explaining that.