FloatBinaryCondition

FloatBinaryCondition answers a yes/no question about two numbers: is a equal to b, greater than it, less than it, and so on. Where FloatBinaryOperation produces a new number, this produces a decision - a BOOLEAN you can then use to gate or branch the rest of your workflow. It's the comparison half of ComfyMath's float tools, and it's the node you want the moment "run this differently depending on whether a computed value crosses some threshold" shows up in a workflow.

How it works

Pick a comparison from op - Eq, Neq, Gt, Gte, Lt, Lte (equal, not-equal, greater-than, greater-or-equal, less-than, less-or-equal) - feed in a and b, and it outputs true or false depending on whether the comparison holds.

The inputs and outputs that matter

• op - the comparison dropdown.
• a, b - the two float operands (default 0, step 0.001).
• Output - a single BOOLEAN, the result of the comparison.

Installing it

ComfyUI Manager: search ComfyMath, install, restart. Or:

cd ComfyUI/custom_nodes && git clone https://github.com/evanspearman/ComfyMath

then restart. Pure Python, no extra dependencies, no model files.

Common issues

The thing to understand about this node is what it doesn't do: it produces a boolean, but ComfyMath itself doesn't ship a general-purpose "if this then run branch A, else branch B" node in this line-up. To actually act on the result you need a separate switch or gate node downstream - something like rgthree-comfy's Any Switch, which is built specifically for routing based on a condition like this. Wiring this node's output into something that doesn't know what to do with a plain boolean is the single most likely reason it "doesn't work."

Float comparisons also carry the usual floating-point trap: Eq on two floats that arrived via different arithmetic paths can come back false even when the values are "the same" mathematically, because of ordinary floating-point rounding. If you're comparing a computed value against a target and getting a surprising false, that's worth suspecting before assuming the node is broken - a Gte/Lte with a small tolerance, or comparing rounded/integer versions of the values via FloatToInt first, sidesteps it.

Being one of the lowest-traffic nodes in an already small pack, this one has essentially no community troubleshooting history to lean on. That's not a red flag by itself - the operation is simple enough to reason about directly - but it does mean you're on your own if something behaves oddly. ComfyMath overall has had no active maintainer since roughly early 2024, though as pure arithmetic with no external dependencies, that inactivity hasn't translated into reported breakage for the nodes people actually use.