FloatToNumber

FloatToNumber is IntToNumber's sibling for decimals: it takes a plain FLOAT and converts it into ComfyMath's own generic NUMBER type. NUMBER is what the pack's NumberBinaryOperation and NumberUnaryOperation nodes actually operate on - a type designed to hold either an int or a float so one set of math nodes covers both, instead of ComfyMath needing a whole separate "float add" and "int add" for every operation. This node is how a float value gets into that world.

You'd reach for it when you're already deep in a chain of ComfyMath NUMBER nodes - say, computing something with NumberUnaryOperation's trig or log functions - and you need to introduce a fresh float value (a CFG scale, a denoise strength, a manually-set constant) partway through without breaking the chain's type.

How it works

a (FLOAT, default 0) in, NUMBER out. It's a straight type conversion with nothing to configure - the value doesn't change, only the socket type it's wearing.

The inputs and outputs that matter

• a - the float you're converting.
• Output - NUMBER, which only plugs into other ComfyMath NUMBER sockets (NumberBinaryOperation, NumberUnaryOperation), not into a generic FLOAT input elsewhere in the graph.

Installing it

ComfyUI Manager: search ComfyMath, install, restart. By hand:

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

then restart ComfyUI. No extra pip dependencies, nothing to download - it's a small, self-contained Python pack.

Common issues

This is a niche node in the sense that most workflows doing basic float math never touch NUMBER at all - they use FloatBinaryOperation directly, since it works on FLOAT sockets that connect to everything else natively. You reach for FloatToNumber specifically when you've committed to building a longer calculation with ComfyMath's generic NUMBER nodes (usually because you want to mix int and float values through the same chain without converting at every step), and this is where a float value enters that chain.

The type-mismatch trap is the same one that hits every node in ComfyMath's conversion family: NUMBER, VEC2/VEC3/VEC4, FLOAT and INT are all distinct socket types as far as ComfyUI's graph is concerned. A NUMBER output will refuse to wire into a plain FLOAT input even though the underlying value is a float - you have to go back the other way through NumberBinaryOperation's output or an explicit converter to leave NUMBER-land.

Maintenance-wise, there's not much to report either way: ComfyMath hasn't seen active development since around early 2024, per a Reddit thread where the author was described as no longer working on the project, but it's plain, dependency-free Python arithmetic, so there's little for an upstream ComfyUI change to actually break. Don't expect updates, and if this exact node ever does misbehave, you're most likely looking at a workflow-side type mismatch rather than a bug in the node itself - double-check what's actually plugged into a before assuming otherwise.