What causes "Scale factor is too large" in tracel-ai/burn?

Use a sane scale_factor (e.g. 2.0 for upsampling) that keeps output size well within usize range.

Scale factor is too large

Error message

Scale factor is too large

What it means

Interpolate1d's `calculate_output_size`, when scaling by `scale_factor`, computes `l * scale_factor` as f64 and panics if the result exceeds usize::MAX — i.e. the requested output length cannot be represented as a valid tensor dimension. This guards against absurd scale factors silently overflowing the cast to usize.

Source

Thrown at crates/burn-nn/src/modules/interpolate/interpolate1d.rs:155

/// or if the scale factor is too large
fn calculate_output_size(
    input_dims: [usize; 3],
    output_size: Option<usize>,
    scale_factor: Option<f32>,
) -> usize {
    match (output_size, scale_factor) {
        (Some(output_size), None) => {
            // Use provided
            output_size
        }
        (None, Some(scale_factor)) => {
            // Calculate output size based on scale factor
            let [_, _, l] = input_dims;

            let new_dim = (l as f64) * (scale_factor as f64);

            if new_dim > usize::MAX as f64 {
                panic!("Scale factor is too large");
            }

            new_dim as usize
        }
        _ => panic!("Either output_size or scale_factor must be provided"),
    }
}

impl ModuleDisplay for Interpolate1d {
    fn custom_settings(&self) -> Option<DisplaySettings> {
        DisplaySettings::new()
            .with_new_line_after_attribute(false)
            .optional()
    }

    fn custom_content(&self, content: Content) -> Option<Content> {
        content
            .add_debug_attribute("mode", &self.mode)

View on GitHub (pinned to d16f7ba2ed)

Solutions

Use a sane scale_factor (e.g. 2.0 for upsampling) that keeps output size well within usize range.
Prefer specifying an explicit `output_size` instead of a scale factor for very large tensors.
Compute the expected output length yourself and assert it fits in usize before forwarding.

Example fix

// before
let interp = Interpolate1d::new(Interpolate1dConfig::Scale(1e18)); // overflow
// after
let interp = Interpolate1d::new(Interpolate1dConfig::Scale(2.0));
// or explicit
let interp = Interpolate1d::new(Interpolate1dConfig::Output(512));

Defensive patterns

Strategy: validation

Validate before calling

fn validate_scale(input_len: usize, scale_factor: f64) {
    let out = input_len as f64 * scale_factor;
    assert!(out.is_finite() && out <= usize::MAX as f64,
        "output length {out} exceeds usize range");
}
validate_scale(input_len, scale_factor);

Type guard

fn output_fits(input_len: usize, scale_factor: f64) -> bool {
    (input_len as f64 * scale_factor) <= usize::MAX as f64
}

Try / catch

let result = std::panic::catch_unwind(|| interpolate.forward(input));
match result {
    Ok(out) => out,
    Err(_) => {
        let interp = Interpolate1d::new(Interpolate1dConfig::Scale(scale_factor.min(4.0)));
        interp.forward(input)
    }
}

Prevention

Use modest scale factors (e.g. 2.0); verify the intended semantics (fraction vs percentage).
Prefer explicit Output sizes for large tensors.
Clamp computed output sizes to a sane maximum in your pipeline.

When it happens

Trigger: Calling Interpolate1d forward with an Interpolate1dConfig::Scale(scale_factor) where `input_length as f64 * scale_factor as f64 > usize::MAX as f64`, e.g. a scale_factor like 1e18 on a long input.

Common situations: Passing a percentage (e.g. 200) intending 2.0 and compounding scales; a misparsed config value (NaN-adjacent huge numbers); accidental f64/usize unit mismatch on very large tensors.

Related errors

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