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

HuberLoss::forward supports only Mean, Auto, and Sum reductions; any other variant panics. The unreduced element-wise loss (|error| beyond delta is delta*|error|, else 0.5*error^2) is available via forward_no_reduction.

Source

Thrown at crates/burn-nn/src/loss/huber.rs:95

    ///
    /// `Reduction::Auto` behaves as `Reduction::Mean`.
    ///
    /// # Shapes
    ///
    /// - predictions: \[...dims\]
    /// - targets: \[...dims\]
    /// - output: \[1\]
    pub fn forward<const D: usize>(
        &self,
        predictions: Tensor<D>,
        targets: Tensor<D>,
        reduction: Reduction,
    ) -> Tensor<1> {
        let loss = self.forward_no_reduction(predictions, targets);
        match reduction {
            Reduction::Mean | Reduction::Auto => loss.mean(),
            Reduction::Sum => loss.sum(),
            other => panic!("{other:?} reduction is not supported"),
        }
    }
    /// Compute the loss element-wise for the predictions and targets.
    ///
    /// # Shapes
    ///
    /// - predictions: [...dims]
    /// - targets: [...dims]
    /// - output: [...dims]
    pub fn forward_no_reduction<const D: usize>(
        &self,
        predictions: Tensor<D>,
        targets: Tensor<D>,
    ) -> Tensor<D> {
        let residuals = targets - predictions;
        self.forward_residuals(residuals)
    }
    /// Compute the loss element-wise for the given residuals.

View on GitHub (pinned to d16f7ba2ed)

Solutions

Use Reduction::Mean, Reduction::Sum, or Reduction::Auto.
Use HuberLoss::forward_no_reduction and apply your own reduction (e.g. .sum(), .mean(), or per-sample weighting).
Constrain the config enum to supported reductions or map unsupported ones explicitly.

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 huber 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

Pass only Mean/Auto/Sum to HuberLoss::forward.
Use forward_no_reduction for custom/weighted reductions.
Reject unsupported reduction variants during config load.
Keep a per-loss compatibility table in your config validation.

When it happens

Trigger: Calling HuberLoss::forward(predictions, targets, reduction) with Reduction::None or any unsupported variant.

Common situations: Porting PyTorch HuberLoss/SmoothL1Loss with reduction='none' for per-sample weighting; passing a shared reduction config through; version differences where a previous burn variant accepted None.

Related errors

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