tracel-ai/burn · error

HannWindow size doesn't fit in i64 range.

Error message

HannWindow size doesn't fit in i64 range.

What it means

hann_window() computes a Hann window tensor of the requested length. Before building the tensor it converts the `size` (usize) to i64 via `i64::try_from(size)`, because the arange call needs i64. If `size` exceeds i64::MAX (only possible on 64-bit targets with an absurd value), the conversion fails and this expect() panics.

Source

Thrown at crates/burn-tensor/src/tensor/signal/hann_window.rs:51

pub fn hann_window(
    size: usize,
    periodic: bool,
    options: impl Into<TensorCreationOptions>,
) -> Tensor<1> {
    let opt = options.into();
    let dtype = opt.resolve_dtype::<Float>();
    let shape = [size];
    check!(TensorCheck::creation_ops::<1>("HannWindow", &shape));

    if size == 0 {
        return Tensor::<1>::empty(shape, opt).cast(dtype);
    }

    if size == 1 {
        return Tensor::<1>::ones(shape, opt).cast(dtype);
    }

    let size_i64 = i64::try_from(size).expect("HannWindow size doesn't fit in i64 range.");
    let denominator = if periodic { size } else { size - 1 };
    let angular_increment = (2.0 * core::f64::consts::PI) / denominator as f64;

    Tensor::<1, Int>::arange(0..size_i64, &opt.device)
        .float()
        .mul_scalar(angular_increment)
        .cos()
        .mul_scalar(-0.5)
        .add_scalar(0.5)
        .cast(dtype)
}

View on GitHub (pinned to d16f7ba2ed)

Solutions

1. Verify the `size` argument passed to hann_window; print/log it before the call.
2. Check for usize arithmetic that can underflow or overflow before being passed as size (e.g. `a - b` where a < b, or multiplication overflow).
3. Clamp or validate size before calling, e.g. assert it is within a sane range such as < i64::MAX and realistically < a few million samples.
4. If a truly enormous window is intended, it exceeds practical memory anyway; redesign the algorithm (chunked/streaming windowing).

Example fix

// before
let size = samples_total - hop; // may underflow when hop > samples_total
let window = hann_window(size, &device);
// after
let size = samples_total.checked_sub(hop).expect("hop must be <= samples_total");
assert!(size > 0 && size <= i64::MAX as usize);
let window = hann_window(size, &device);

fn safe_hann_window(size: usize, device: &Device) -> Tensor<1> {
    assert!(size <= i64::MAX as usize, "hann_window size must fit in i64");
    assert!(size > 0, "hann_window size must be positive");
    hann_window(size, device)
}

fn fits_i64(v: usize) -> bool { v <= i64::MAX as usize }

When it happens

Trigger: Calling `Tensor::hann_window(size, ...)` (or `hann_window::hann_window`) with a size larger than i64::MAX (~9.2e18). On 32-bit platforms usize cannot exceed i64 range so it never fires; on 64-bit it requires an extreme or corrupted size value, e.g. one computed from bad math or a wrapped/negative value cast into usize.

Common situations: Almost always a bug in the caller's own size computation: multiplying window lengths, using a garbage config value, or a usize underflow (e.g. `0usize - 1`) producing a huge number passed as the window size.

Related errors

• Requires autodiff tensor.
• an enabled float tensor must use an autodiff primitive
• Should be float, got int
• Should be float, got bool
• Should be float, got quantized

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