As someone who hasn't encountered the "implies" and "not implies" operations in situations like this before, I'm not sure they would make it easier for me to understand a node tree. The others I think would be great additions! Maybe others have more opinions about the last two.

In D13774#364880, @Hans Goudey (HooglyBoogly) wrote:

As someone who hasn't encountered the "implies" and "not implies" operations in situations like this before, I'm not sure they would make it easier for me to understand a node tree. The others I think would be great additions! Maybe others have more opinions about the last two.

"Implies" and "Not Implies" can be useful in situations when you want to respect a boolean only under certain circumstances, much like an enable/disable toggle.

E.G.
Use boolean B when boolean A applies, otherwise return true = Implies
Use boolean B when boolean A applies, otherwise return false = And

For example, if "Set Position" was an action you want to occur unless explicitly stated otherwise:

It is used in various games, for example:
https://minecraft.fandom.com/wiki/Redstone_circuits/Logic#IMPLY_gate
https://nomanssky.fandom.com/wiki/Combinational_Circuits#IMPLY_Gate

"Implies" and "Not Implies" are also the only gates that depend on the order of the inputs.
I was thinking of adding "Converse" and "Not Converse" operators, but you can get the same outcome by swapping the inputs.

Thank you, I think it would be nice to have mote boolean logic in the node!

Some remarks:

• I think the naming should be consistent with itself here: Exclusive Nor -> Exclusive Not Or

• I'm not sure about the Implies gates. I feel like this should rather be done with the Switch node. That one seems more intuitive and allows to define a fallback as well. But I don't really have a strong opinion against including them here.

In D13774#365117, @Simon Thommes (simonthommes) wrote:

Thank you, I think it would be nice to have mote boolean logic in the node!

Some remarks:

• I think the naming should be consistent with itself here: Exclusive Nor -> Exclusive Not Or

• I'm not sure about the Implies gates. I feel like this should rather be done with the Switch node. That one seems more intuitive and allows to define a fallback as well. But I don't really have a strong opinion against including them here.

I agree, the naming should be more consistent. Changed from "Not Or" to "Nor" to keep everything short.

It can be done with a Switch, though it appears more complex:

The main reason for its inclusion is for a complete set of logic gates. There are other uses for the gate which apply heavily in math, especially in conditional proofs.

I'll commit it.

@Hallam Roberts (MysteryPancake) Would you like this to be committed with your real name? If yes, please let me know your real name.

Also see our guidelines here: https://wiki.blender.org/wiki/Style_Guide/Commit_Messages#Author_.2F_Committer

In D13774#366666, @Jacques Lucke (JacquesLucke) wrote:

@Hallam Roberts (MysteryPancake) Would you like this to be committed with your real name? If yes, please let me know your real name.

Also see our guidelines here: https://wiki.blender.org/wiki/Style_Guide/Commit_Messages#Author_.2F_Committer

Thank you, I would like to not use my real name if possible.

will «boolean equal» be implemented, or integer equal works as fast as boolean already?

In D13774#366856, @Vyacheslav (hitrpr) wrote:

will «boolean equal» be implemented, or integer equal works as fast as boolean already?

Exclusive Nor is boolean equal (true when both are equivalent).

Maybe Exclusive Or should be renamed to "Not Equal" and Exclusive Nor to "Equal" ?

Exclusive Nor is boolean equal (returns true when both are equivalent)

Oh, true!

As I think, names «equal» or «not equal» have more clarity and simplicity.
Just as one operation instead three (not + or + if equal), and tooltip can remind, that they are xor and xnor

Updated naming as suggested by Vyacheslav.

"Exclusive Or" and "Exclusive Nor" are technical terms which don't clearly state what they do.
Nobody will use them if it's not clear what they do (I also forget what they do quite often)

"Not Equal" and "Equal" are immediately clear, and much shorter terms.
This goes with the idea of making the node tree more understandable, as mentioned by Hans.

It also improves consistency between the "Compare" node and "Boolean Math".

Operations are still named XOR and XNOR in the codebase, will change if requested.

Little note.
I checked table of imply.
And it is literally «Less or equal»
Probably name should be changed to more familiar variant. And keep «Implification» in tooltip for math-ppl ofc.

In D13774#371657, @Vyacheslav (hitrpr) wrote:

Little note.
I checked table of imply.
And it is literally «Less or equal»
Probably name should be changed to more familiar variant. And keep «Implification» in tooltip for math-ppl ofc.

I was thinking this too, though maybe it would be better to add boolean support to the Compare node to allow other comparisons like this (Less, Greater, Greater or Equal).

"Not Imply" is also equivalent to "Greater", though I like the name "Subtract"

Perhaps Equal/Not Equal/Imply/Subtract should be moved to the Compare node.

Could continue discussion on https://developer.blender.org/D13978