What causes "{other:?} reduction is not supported" in tracel-ai/burn?

Use Reduction::Mean, Reduction::Auto, or Reduction::Sum.

{other:?} reduction is not supported

Error message

{other:?} reduction is not supported

What it means

SmoothL1Loss's `forward_with_reduction` only supports Mean, Auto (as Mean), and Sum reductions; any other Reduction variant panics in the catch-all arm. The reduced API returns a scalar `Tensor<1>`, so unsupported modes cannot be honored.

Source

Thrown at crates/burn-nn/src/loss/smooth_l1.rs:165

    /// A scalar tensor containing the reduced loss value.
    ///
    /// # Shapes
    ///
    /// - predictions: `[...dims]` - Any shape
    /// - targets: `[...dims]` - Must match predictions shape
    /// - output: `[1]` - Scalar loss value
    pub fn forward_with_reduction<const D: usize>(
        &self,
        predictions: Tensor<D>,
        targets: Tensor<D>,
        reduction: Reduction,
    ) -> Tensor<1> {
        let unreduced_loss = self.forward(predictions, targets);

        match reduction {
            Reduction::Mean | Reduction::Auto => unreduced_loss.mean(),
            Reduction::Sum => unreduced_loss.sum(),
            other => panic!("{other:?} reduction is not supported"),
        }
    }

    /// Computes the smooth L1 loss with reduction over specified dimensions.
    ///
    /// Calculates element-wise smooth L1 loss, then takes the mean
    /// over the specified dimensions. Useful for per-sample or per-channel losses.
    ///
    /// Dimensions can be provided in any order.
    ///
    /// # Arguments
    ///
    /// - `predictions` - The model's predicted values.
    /// - `targets` - The ground truth target values.
    /// - `dims` - Dimensions to reduce over.
    ///   Negative dimensions are supported and count from the end.
    ///
    /// # Returns

View on GitHub (pinned to d16f7ba2ed)

Solutions

Use Reduction::Mean, Reduction::Auto, or Reduction::Sum.
Call `SmoothL1Loss::forward(predictions, targets)` to get the element-wise (unreduced) loss.
Guard user/config-supplied Reduction values before invoking.

Example fix

// before
let loss = smooth_l1.forward_with_reduction(pred, target, Reduction::None);
// after
let elemwise = smooth_l1.forward(pred, target); // unreduced
let loss = elemwise.mean();

Defensive patterns

Strategy: validation

Validate before calling

fn is_supported_reduction(r: &Reduction) -> bool {
    matches!(r, Reduction::Mean | Reduction::Auto | Reduction::Sum)
}
assert!(is_supported_reduction(&reduction));

Type guard

fn is_supported_reduction(r: &Reduction) -> bool {
    matches!(r, Reduction::Mean | Reduction::Auto | Reduction::Sum)
}

Try / catch

let result = std::panic::catch_unwind(|| smooth_l1.forward_with_reduction(pred, target, reduction));
match result {
    Ok(loss) => loss,
    Err(_) => smooth_l1.forward(pred, target).mean(),
}

Prevention

Call SmoothL1Loss::forward directly when reduction='none' semantics are wanted.
Centralize reduction mapping in one helper tested against all losses.
Validate configs at deserialization time.

When it happens

Trigger: Calling `SmoothL1Loss::forward_with_reduction(predictions, targets, reduction)` with a Reduction value outside {Mean, Auto, Sum}, most often Reduction::None.

Common situations: Sharing a reduction enum across multiple losses where one supports None and others do not; config deserialization producing an unexpected variant; refactoring to a newer burn version that extended the Reduction enum.

Related errors

AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05). Data as JSON: /api/errors/b8ba9f18f20c5a97. Report an issue: GitHub.