Compare Float

ComfyUI doesn't have an if statement, but it has something better: a node that turns a condition into a boolean you can wire anywhere. SL_CompareFloat compares two floats with an operator you pick from a dropdown - ==, !=, >, <, >=, <= - and outputs True or False. That boolean is then fuel for switch nodes, AND gates, and every other conditional construct in your graph.

This is the node that makes workflows responsive. "Only run the high-res pass if the computed quality score is above 0.5." "Switch to a different sampler when denoise exceeds a threshold." "Skip a branch when a value went negative." All of those are a Compare node feeding a switch or a logic gate.

The mechanism is a plain dictionary lookup in the source: it maps your chosen operator to the Python comparison and returns the result. >= is genuinely >=, there's no rounding being applied, no hidden tolerance.

Inputs:

• a (FLOAT) - first value, default 0.0
• b (FLOAT) - second value, default 0.0
• op - dropdown with the six comparison operators
• Output: BOOLEAN - the result of the comparison

Note that the op choice lives on the node, so you pick it once in the node's config, not via a wire. That's a deliberate simplification - it makes the graph read cleanly (one node per comparison) at the cost of not being able to switch operators dynamically.

Installing it

Ships with ComfyUI-SimpleLogics. Manager → search "SimpleLogics" → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/danipisca07/ComfyUI-SimpleLogics

Restart, Add Node → search "Compare Float" (menu group SimpleLogics/Compare). No dependencies, no models.

The float-equality trap

Here's the one thing that will bite you, and it's not this node's fault - it's how floats work. == and != on floats are exact comparisons, and floats are rarely exact. 0.1 + 0.2 is 0.30000000000000004 in binary, not 0.3. So if you build a workflow that compares two computed floats for equality, it will sometimes come out False when you'd swear they're equal. If you need "close enough," compare with > / < against a small epsilon instead, or compare the two values against a tolerance bound. For ordering comparisons (>, >=, etc.) this trap mostly doesn't apply.

Where it shows up

• Threshold gating: quality scores, depth values, or any continuous measurement crossing a decision line.
• Feeding switches: SL_SwitchFloat, SL_SwitchAny, or this pack's other switch nodes take the boolean and pick a branch.
• Composed conditions: run the result into SL_AND or SL_OR to build multi-condition logic.

There's an integer twin, SL_CompareInt, that works identically on INT inputs - and since FLOAT inputs accept INT wires, you can even feed this one from an integer source without converting. For most "is this number past a threshold" needs, this is the node you want.