Pt To Float64

Most of the time your tensors in ComfyUI-Pt-Wrapper are float32, and that's fine. PyTorch defaults to float32 everywhere, and swapping in float64 (double precision) is something you do on purpose, not by accident. Pt To Float64 is that purpose. It's a one-line dtype cast that takes any tensor and returns the same values, same shape, as a 64-bit float.

So when do you actually reach for it? A few honest cases: you're doing statistics where accumulated precision matters, you're feeding a downstream node that demands double-precision inputs (some scipy/sklearn-style routines are picky), or you're trying to match a known-good reference computation bit for bit. It's also useful when two tensors refuse to play nice because of a dtype mismatch - casting both to the same type is the fastest way to unstick them.

The node itself is about as simple as this pack gets. One required input, tens_a (a TENSOR), and one output (TENSOR). Internally it's a single line: tens_a.to(torch.float64). No options, no mode switch, nothing to misconfigure. It's the same family as the pack's PtToFloat16 and PtToFloat32 nodes - think of them as the cast-to-flavor aisle.

One thing worth knowing before you get fancy: consumer NVIDIA cards are notoriously slow at float64 math. GPU fp64 throughput is deliberately gimped compared to fp32. If you cast a tensor to float64 and suddenly your training node crawls, that's why - and it's usually a sign you don't actually need double precision. For plain inspection and display it's harmless.

Install

ComfyUI Manager is the easy path: search "ComfyUI-Pt-Wrapper", install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/HowToSD/ComfyUI-Pt-Wrapper

Then restart ComfyUI. The pack is heavy: its requirements.txt pulls in transformers, datasets, peft, accelerate, scikit-learn, pandas, seaborn, matplotlib, gensim, and sentencepiece. First launch after install can take a while while those land. No model files to download for the pack itself.

Common issues

A float64 cast is close to foolproof, but keep the gotcha in view: dtype mismatches are the classic cause of "expected Float tensor, got Double" style errors in the next node down the wire. If a tensor in your graph suddenly errors after a cast, check whether a sibling node still expects float32 - and if this cast was purely diagnostic, unplug it rather than carrying float64 through the whole pipeline.