Pt To Int64

If you've ever gotten a PyTorch error that says something about "expected a Long tensor" or "expected dtype int64", this node is the answer. Pt To Int64 converts a tensor to signed 64-bit integers - what PyTorch calls int64 or long - and that's the dtype the framework defaults to for a whole class of operations: gather, index_select, embedding lookups, most index arithmetic. When you build those ops out of a float tensor or an int32 tensor, PyTorch will complain loudly. Cast to int64 and the complaints stop.

Mechanically it's the same one-liner as the rest of the cast family - tens_a.to(torch.int64) - one required input (tens_a, TENSOR) and one output (TENSOR). It's the sibling of PtToInt32 and PtToInt16, but it's the one you'll reach for when something is angry about indices, because that's what PyTorch's own indexing wants under the hood. Think of int32 as "for data" and int64 as "for indices and labels."

The recurring trap still applies, of course: floats truncate toward zero on the way to ints. And one more thing worth knowing - the pack's training pipeline uses int64 tensors for labels all over the place, so when a training or evaluation node complains about label dtype, this node is the usual fix. Cast, rewire, done.

Install

ComfyUI Manager (search "ComfyUI-Pt-Wrapper") or:

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

Restart ComfyUI. The pack's requirements are heavy - transformers, datasets, peft, accelerate, scikit-learn, pandas, seaborn, matplotlib, gensim, sentencepiece - and the first launch after install is slow to start. No model files to download.

Common issues

If you cast a label tensor to int64 and a training node still complains, check whether the tensor you cast is the one the node actually reads - easy to cast a copy and wire the original. Also remember the truncation rule: casting 1.9 gives 1, not 2, so if your labels are continuous scores you probably want a different pipeline than int64 entirely.