IntToFloat

IntToFloat is FloatToInt's mirror image - instead of chopping a decimal down to a whole number, it takes an INT and hands back a FLOAT. Same reason to reach for it: ComfyUI's graph won't let you plug an INT output straight into a FLOAT input, even though the conversion is trivial. You need an actual node sitting in the wire, and this is it.

It comes up constantly in workflows that mix integer and float parameters - a pixel dimension (naturally an int) feeding into a ratio or scale calculation (naturally a float), or a frame count needing to become a duration. Rather than redo your whole chain in one type, you convert at the boundary and keep going.

How it works

a (INT, default 0) goes in, a FLOAT comes out. The integer is represented exactly as a float - there's no rounding to worry about here, unlike its sibling FloatToInt. That asymmetry is worth remembering: int→float never loses information; float→int always can.

The inputs and outputs that matter

• a - the integer you're converting.
• Output - a FLOAT, ready for anything expecting a decimal: CFG scale, denoise strength, or the a/b inputs of a downstream FloatBinaryOperation.

Installing it

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

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

then restart. Pure Python, no extra dependencies, nothing to download - the whole pack is live the moment ComfyUI comes back up.

Common issues

This is one of the more-used nodes in the pack for a mundane reason: an int/float type mismatch is one of the most common "why won't these connect" moments a beginner runs into in ComfyUI, and this is the direct fix. A workflow author building an LTX-2 video pipeline described needing ComfyMath specifically for "silly float/int conversion for framerate" - exactly this kind of boundary crossing, not some exotic edge case.

The pack has had no active maintainer since at least 2024 - a user asking about extending it on Reddit was told the author "no longer work[s] on the project" - but because it's plain arithmetic with zero external dependencies, that hasn't translated into breakage. It mostly just means don't expect new features, and don't expect a fast fix if ComfyUI's frontend ever changes something underneath it.

One mixup worth watching for: this converts to ComfyUI's native FLOAT type, not ComfyMath's own internal NUMBER type used by its number-family nodes (NumberBinaryOperation, NumberUnaryOperation, and friends). If you're chaining those together, you want IntToNumber instead - plugging IntToFloat's output into a NUMBER-only socket won't work, since they're different socket types even though they represent the same kind of value.