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

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

{other:?} reduction is not supported

Error message

{other:?} reduction is not supported

What it means

Reduction-enum exhaustiveness guard in LpLoss::forward: only Mean/Auto and Sum reductions are supported; any other `Reduction` value passed by the caller panics, indicating an unsupported or unknown reduction variant.

Source

Thrown at crates/burn-nn/src/loss/lp_loss.rs:151

    /// 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<const D: usize>(
        &self,
        predictions: Tensor<D>,
        targets: Tensor<D>,
        reduction: Reduction,
    ) -> Tensor<1> {
        let unreduced_loss = self.forward_no_reduction(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 element-wise loss `|error|^p` without reduction.
    ///
    /// # Arguments
    ///
    /// * `predictions` - The model's predicted values.
    /// * `targets` - The ground truth target values.
    ///
    /// # Returns
    ///
    /// A tensor of the same shape as the inputs, containing `|prediction - target|^p`
    /// for each element.
    ///
    /// # Shapes
    ///
    /// - predictions: `[...dims]` - Any shape

View on GitHub (pinned to d16f7ba2ed)

Solutions

Use Reduction::Mean, Reduction::Sum, or Reduction::Auto.
Use LpLoss::forward_no_reduction for the element-wise |error|^p tensor and reduce manually.
Validate reduction settings in the training config loader against the supported set.

Example fix

// before
let loss = criterion.forward(pred, target, Reduction::None); // panics
// after
let elem = criterion.forward_no_reduction(pred, target);
let loss = elem.mean();

Defensive patterns

Strategy: validation

Validate before calling

fn ensure_supported(r: &Reduction) -> Result<(), String> {
    match r {
        Reduction::Mean | Reduction::Auto | Reduction::Sum => Ok(()),
        other => Err(format!("unsupported reduction for Lp loss: {other:?}")),
    }
}

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(std::panic::AssertUnwindSafe(||
    criterion.forward(pred, target, reduction.clone())));

Prevention

Only use Mean/Auto/Sum with LpLoss::forward.
Use forward_no_reduction + manual reduction for element-wise |error|^p.
Validate reduction once in config parsing.
Add regression tests for each reduction your configs may set.

When it happens

Trigger: Calling LpLoss::forward(predictions, targets, reduction) (L1/L2 style loss) with Reduction::None or any non-Mean/Auto/Sum variant.

Common situations: Migrating PyTorch L1Loss/MSELoss with reduction='none'; a global training-config reduction value reused across losses; expecting None to be valid because other frameworks allow it.

Related errors

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