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

Use Reduction::Mean, Reduction::Sum, or Reduction::Auto when calling forward.

{other:?} reduction is not supported

Error message

{other:?} reduction is not supported

What it means

CosineEmbeddingLoss::forward only supports Mean, Auto, and Sum reductions. Any other Reduction variant (e.g. None) passed to forward hits a catch-all arm that panics. To get per-element losses, use forward_no_reduction instead.

Source

Thrown at crates/burn-nn/src/loss/cosine_embedding.rs:98

    ///
    /// - input1: ``[batch_size, embedding_dim]``
    /// - input2: ``[batch_size, embedding_dim]``
    /// - target: ``[batch_size]`` with values 1 or -1
    ///
    /// # Returns
    ///
    /// Loss tensor of shape ``[1]``
    pub fn forward(
        &self,
        input1: Tensor<2>,
        input2: Tensor<2>,
        target: Tensor<1, Int>,
    ) -> Tensor<1> {
        let tensor = self.forward_no_reduction(input1, input2, target);
        match &self.reduction {
            Reduction::Mean | Reduction::Auto => tensor.mean(),
            Reduction::Sum => tensor.sum(),
            other => panic!("{other:?} reduction is not supported"),
        }
    }

    /// Compute loss without applying reduction.
    ///
    /// # Arguments
    ///
    /// * `input1` - First input tensor of shape ``[batch_size, embedding_dim]``
    /// * `input2` - Second input tensor of shape ``[batch_size, embedding_dim]``
    /// * `target` - Target tensor of shape ``[batch_size]`` with values 1 or -1
    ///
    /// # Returns
    ///
    /// Tensor of per-element losses with shape ``[batch_size]``
    pub fn forward_no_reduction(
        &self,
        input1: Tensor<2>,
        input2: Tensor<2>,

View on GitHub (pinned to d16f7ba2ed)

Solutions

Use Reduction::Mean, Reduction::Sum, or Reduction::Auto when calling forward.
Use CosineEmbeddingLoss::forward_no_reduction(input1, input2, target) to obtain unreduced per-element losses and reduce manually.
Validate/normalize the reduction setting at config-load time before constructing/invoking the loss.

Example fix

// before
let loss = criterion.forward(x1, x2, target, Reduction::None); // panics
// after
let per_elem = criterion.forward_no_reduction(x1, x2, target);
let loss = per_elem.mean(); // or handle per-element directly

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 cosine embedding: {other:?}")),
    }
}

Type guard

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

Try / catch

// burn panics rather than returning Result; isolate in catch_unwind if needed
let result = std::panic::catch_unwind(std::panic::AssertUnwindSafe(||
    criterion.forward(x1, x2, target, reduction.clone())));

Prevention

Only pass Reduction::Mean | Auto | Sum to burn loss forwards.
Use forward_no_reduction plus manual reduction whenever you need Reduction::None semantics.
Clamp reduction settings in your training config to the supported set at load time.
Add a unit test asserting your config's reduction is supported before training runs.

When it happens

Trigger: Calling CosineEmbeddingLoss::forward(input1, input2, target) with reduction set to Reduction::None or any variant other than Mean/Auto/Sum.

Common situations: Copying reduction config from PyTorch (where 'none' is valid for losses) into burn; constructing Reduction from user config/CLI where the enum has more variants than this loss supports; blindly forwarding a shared Reduction from a config struct.

Related errors

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