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

Reduce scale_factor[1] so that input_width * scale_factor[1] fits in usize.

Scale factor for width is too large

Error message

Scale factor for width is too large

What it means

This panic is the width counterpart of the height overflow guard in Interpolate2d::calculate_output_size. The output width is computed as input_width * scale_factor[1] in f64, and if the result exceeds usize::MAX the library panics because it cannot be materialized as a tensor dimension. It prevents silent wrap-around when upsampling along the width axis.

Source

Thrown at crates/burn-nn/src/modules/interpolate/interpolate2d.rs:154

    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 [_, _, h, w] = input_dims;

            let new_dim_h = (h as f64) * (scale_factor[0] as f64);

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

            let new_dim_w = (w as f64) * (scale_factor[1] as f64);

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

            [new_dim_h as usize, new_dim_w as usize]
        }
        _ => panic!("Either output_size or scale_factor must be provided"),
    }
}

impl ModuleDisplay for Interpolate2d {
    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

Reduce scale_factor[1] so that input_width * scale_factor[1] fits in usize.
Use with_output_size([h, w]) with explicit target dimensions instead of a scale factor.
Validate the scale before building the config: require finite values and a sane upper bound.
Check whether the huge value belongs on the other axis (h vs w swapped) and correct the ordering.

Example fix

// before
let cfg = Interpolate2dConfig::new().with_scale_factor([2.0, 1e30]);
// after
assert!(scale_w.is_finite() && scale_w < 1e6);
let cfg = Interpolate2dConfig::new().with_scale_factor([2.0, scale_w]);
// or explicit target size:
let cfg = Interpolate2dConfig::new().with_output_size([224, 448]);

Defensive patterns

Strategy: validation

Validate before calling

let new_dim_w = (w as f64) * (scale_factor[1] as f64);
if !new_dim_w.is_finite() || new_dim_w > usize::MAX as f64 {
    return Err("width scale out of range");
}

Type guard

fn valid_scale(s: f64) -> bool {
    s.is_finite() && s > 0.0 && s <= 1e6
}

Try / catch

let result = std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| module.forward(input)));
match result {
    Ok(out) => out,
    Err(_) => fallback_to_output_size_config(),
}

Prevention

Double-check h/w ordering in with_scale_factor([scale_h, scale_w]) — swapped values are a common cause.
Use with_output_size([h, w]) to sidestep overflow math entirely.
Sanity-check scale factors read from external configs before constructing Interpolate2dConfig.

When it happens

Trigger: Calling Interpolate2d::forward where the config used with_scale_factor([s_h, s_w]) and (input_width as f64) * s_w > usize::MAX as f64. Concrete triggers: scale_factor[1] = f64::INFINITY, an enormous finite scale value, or a very wide input multiplied by a large scale.

Common situations: Swapping the order of scale values so the wrong axis gets the huge factor, config-driven scales without sanity bounds, sentinel infinity accidentally left in place, or 32-bit targets where usize::MAX is ~4.29e9 and overflows happen far sooner.

Related errors

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