Float → Number

Let me be straight with you: SL_FloatToNumber is the most skippable node in the SimpleLogics pack. Its input is already a float, its output is a NUMBER, and since ComfyUI already lets an INT wire plug into a FLOAT input, a float wire will happily plug into anything that accepts NUMBER. You can build a lot of workflows and never touch this node. So why does it exist, and when does it earn its keep?

The honest answer is type hygiene. ComfyUI's type system is strict about some mismatches - a FLOAT won't connect to an INT input - but the NUMBER type is the loose one that both INT and FLOAT can feed. The problem with "loose" is that it's ambiguous: a NUMBER output doesn't tell the next node whether it's holding 5 or 5.0. This node makes the choice explicit. You're saying "whatever this float is, treat it as the generic numeric type," which lets it flow into any NUMBER-typed input downstream without the graph getting picky.

The mechanism is the least interesting part of the pack: return (float(value),). It's a passthrough that relabels the type. The value never changes - 0.5 stays 0.5, your CFG of 7 stays 7.0. That means you can use it as a no-op type cast in the middle of a chain to keep everything consistently NUMBER, which is handy when a downstream node (often from WAS Node Suite, KJNodes, or similar utility packs) declares its input as NUMBER and you want zero doubt the wire will connect.

Inputs and outputs:

• value (FLOAT) - your number, usually a slider, a computed strength, or a denoise value.
• Output: NUMBER - same value, float-backed, generic label.

Installing it

It's part of ComfyUI-SimpleLogics. Via ComfyUI Manager: search "SimpleLogics" in Install Custom Nodes, install, restart. Manual route:

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

Restart, then Add Node → search "Float → Number" (menu group SimpleLogics/Convert). The pack has zero dependencies - no pip install, no model downloads - so install is quick either way.

When it's actually useful

Two scenarios, honestly:

1. You're standardizing a chain on NUMBER. If several nodes in a row all want NUMBER, converting once at the source keeps the whole branch consistent instead of hoping each auto-coercion behaves.
2. You're feeding a node with a NUMBER-typed input and want the wire to be unambiguous. It won't red-link, but some graphs just feel safer with an explicit cast in the path.

Otherwise, skip it. The pack has Float → Int and Float → String for the conversions that actually change things; this one changes nothing but the label. There's no trap here, no rounding gotcha - just an honest little type-cast node that's there when you want to be deliberate about types.