Skip to content

← Reductions and dim step 2 of 7

Easy Primitives

Accuracy from a comparison

Accuracy is the mean of a boolean tensor. Writing it that way does not work:

(preds == labels).mean()
RuntimeError: mean(): could not infer output dtype. Input dtype
must be either a floating point or complex dtype.

Why it refuses rather than guessing

The mean of [True, False, True] could reasonably be 0.667 as a float or 0 as an integer, and PyTorch will not pick for you. sum() has an obvious answer, so it works and quietly promotes to int64:

(preds == labels).sum()        # tensor(3)          int64
(preds == labels).float().mean()   # tensor(0.75)   float32

This refusal is a small kindness. The languages that guess produce integer zero accuracy and leave you to find it.

Two spellings

correct.float().mean()
correct.sum() / correct.numel()

Both fine. The first says “the average of these indicators” and is what people read faster. The second is what you want when you also need the count.

Do not reach for .item() here

correct.float().mean().item()      # a float, and a host synchronisation

Metrics accumulated inside a training loop should stay as tensors and be reduced at the end. Calling .item() per batch forces the GPU to finish and hand a number back to Python, once per batch, forever. The performance track returns to this; for now, note that the cast is the fix and .item() is not part of it.

Your task

def accuracy(preds: torch.Tensor, labels: torch.Tensor) -> torch.Tensor

Return the fraction of positions where preds equals labels, as a 0-dimensional float tensor.