numpy.sum vs torch.sum: why reductions on torch.Tensor error out and how to fix it

Learn why numpy.sum fails on torch.Tensor due to out= handling, how to avoid NumPy-PyTorch interop traps, and the safe fixes: convert to NumPy or use torch.sum.

Mixing NumPy, pandas, and PyTorch looks convenient until it suddenly isn’t. A common example: calling numpy.sum on a torch.Tensor. The same call happily works for a NumPy array or a pandas DataFrame, yet it raises an error for a PyTorch tensor. Understanding why this happens helps avoid subtle interop traps and keeps your numerical code predictable.

Reproducing the mismatch

The behavior shows up immediately when performing a reduction over axis=1 across the three data types.

data_src = [[1.1, 2.2], [1.1, 2.2], [1.1, 2.2]]

arr_np = np.array(data_src)
frame_pd = pd.DataFrame(data_src)
block_torch = torch.tensor(data_src)

np.sum(arr_np, axis=1)  # works
np.sum(frame_pd, axis=1)  # works
np.sum(block_torch, axis=1)  # raises an error

What’s actually going on

This is not a bug. NumPy and PyTorch are separate libraries. They make a best effort to interoperate, but they don’t guarantee full API compatibility across all operations. In practice, the safest approach is not to mix different array types within the same API call.

The core detail sits in how reductions are implemented. Both libraries expose reductions as pure functions and as object methods. In NumPy, both the function form and ndarray method form support the out= argument. In PyTorch, only the pure function form supports out=, while the method form does not. NumPy’s reduction machinery may dispatch to an object’s method and pass out=, even as out=None. That works for NumPy arrays, but it collides with torch.Tensor.sum, which does not accept out= in the method form, and thus a TypeError is raised.

To sketch the difference succinctly, the following is supported in PyTorch:

torch.sum(block_torch, 1, out=None)  # function form accepts 'out'

while the method form with an out argument is not:

block_torch.sum(1, out=None)  # method form does not accept 'out'

NumPy’s reduction path may call the method and provide out=, which triggers the error you observe with a torch.Tensor input.

Fix: don’t mix array types in the reduction

The straightforward way to avoid this error is to keep the array type consistent. If you want to use numpy.sum, convert the tensor to a NumPy array first.

data_src = [[1.1, 2.2], [1.1, 2.2], [1.1, 2.2]]

arr_np = np.array(data_src)
frame_pd = pd.DataFrame(data_src)
block_torch = torch.tensor(data_src)

np.sum(arr_np, axis=1)                # works
np.sum(frame_pd, axis=1)              # works
np.sum(block_torch.numpy(), axis=1)   # works after converting to NumPy

This keeps the call within NumPy’s domain, which aligns with its expectations and argument handling.

Why you should care

Interoperability is helpful, but API differences are real and sometimes subtle. Relying on cross-library calls can break in unexpected ways, especially for nuanced features like out=. The NumPy documentation describes numpy.sum as accepting an “array-like” input; whether a torch.Tensor is considered “array-like” here is not guaranteed. Without an explicit promise to support torch.Tensor, this behavior does not qualify as a bug. For long-term portability across array libraries, there is ongoing work in the Python array API standard. The array-api-compat package can help when you want an interface that follows that standard.

Takeaways

When you want NumPy behavior, keep your data as a NumPy array before calling NumPy functions. The same goes for PyTorch: use torch.sum for tensors. The mismatch here comes from NumPy providing out= to a method form that PyTorch’s tensor does not accept. This is expected under the current interop landscape. If your project needs smoother cross-library behavior, consider aligning on a single array type per operation or looking into the Python array API ecosystem.