_.isComplex

_.isComplex checks whether a value is a Python complex number - one with a real and imaginary part, like 3 + 4j. It's a straight port of the type-checking spirit of Underscore.js (_.isNumber, _.isBoolean, and so on) applied to a type that's distinctly Python.

How it works

An exact type comparison:

def isComplex(self):
    return self._wrap(type(self.obj) is complex)

type(...) is complex - so 3+4j passes, while 3, 3.0, and "3+4j" all fail. Python treats complex as its own numeric type, distinct from int and float, and this node honors that boundary precisely. Notably, the port's other numeric checks (isInt, isFloat, isNumeric) don't include complex, so if you're validating numbers and complex values could slip through, this is the test that catches them.

The inputs that matter

One input, one output:

• obj - the primary input (*), the value being inspected. Also accepts a _.CHAIN to continue chaining.

Output is a single * - a real bool at runtime, untyped on the socket because the auto-generator only types standard Underscore.js method names.

Where you'd actually use it

Rarely, and honestly. Complex numbers are vanishingly rare in ComfyUI data flow - you'd have to be doing custom math that produces them (FFT-style work, some signal-processing nodes can return complex arrays). The realistic use is the defensive one: when a numerical pipeline can hand you complex values and downstream math can't handle them, a _.isComplex guard lets you branch to a fallback. If you're not generating complex numbers, this node will sit unused, which is the correct outcome.

Installing

Part of comfy-ovum (MIT). ComfyUI Manager → search comfy-ovum → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/sfinktah/comfy-ovum

No extra dependencies for the underscore nodes - the bundled underscore3 port handles them.

Gotchas

Untyped * output and the pack README's WIP warning apply, as with the whole family. The one thing worth internalizing: isComplex is exact, and the port's other number checks deliberately exclude complex. If you're validating "is this a number" for downstream math, don't assume the number check covers complex values - it doesn't.