Broadcast arguments must be greater than the number of dimen

Error message

Broadcast arguments must be greater than the number of dimensions! got {}, need at least {}

What it means

When a shape-like array ([E; D2] of AsIndex) is converted into a broadcast shape via BroadcastArgs::into_shape, the target array must have at least as many entries as the tensor has dimensions (D2 >= D1). Broadcasting aligns dimensions from the right; a shorter argument list is invalid, so Burn panics with the actual vs. required length. This is a shape-specification bug in the caller's reshape/expand call.

Source

Thrown at crates/burn-tensor/src/tensor/api/base.rs:3375

}

/// Trait used for broadcast arguments.
pub trait BroadcastArgs<const D1: usize, const D2: usize> {
    /// Converts to a shape.
    fn into_shape(self, shape: &Shape) -> Shape;
}

impl<const D1: usize, const D2: usize> BroadcastArgs<D1, D2> for Shape {
    fn into_shape(self, _shape: &Shape) -> Shape {
        self
    }
}

impl<const D1: usize, const D2: usize, E: AsIndex> BroadcastArgs<D1, D2> for [E; D2] {
    // Passing -1 as the size for a dimension means not changing the size of that dimension.
    fn into_shape(self, shape: &Shape) -> Shape {
        if self.len() < shape.num_dims() {
            panic!(
                "Broadcast arguments must be greater than the number of dimensions! got {}, need at least {}",
                self.len(),
                shape.num_dims()
            );
        }

        // Zip the two shapes in reverse order and replace -1 with the actual dimension value.
        let new_shape: Vec<_> = self
            .iter()
            .rev()
            .map(|x| {
                let primitive = x.as_index();
                if primitive < -1 || primitive == 0 {
                    panic!(
                        "Broadcast arguments must be positive or -1! Got {}",
                        primitive
                    );
                }

View on GitHub (pinned to d16f7ba2ed)

Solutions

Pad the broadcast argument list with 1s (or -1 to keep dims) on the left so its length is at least the tensor's rank
Use shape.num_dims() or D1 at the call site to build the array with the right const size
Replace the literal with a computed Shape/expand target derived from the tensor's current dims
If ranks vary generically, use APIs accepting Shape or slices rather than fixed-size arrays

Example fix

// before, x is [B, C, H, W] (D1 = 4)
let y = x.reshape([1, -1]); // got 2, need at least 4 -> panic
// after
let y = x.reshape([1, 1, 1, -1]); // length 4 >= rank 4

Defensive patterns

Strategy: validation

Validate before calling

// Check the broadcast arg length against the tensor rank before reshaping
let args_len = args.len();
let rank = x.shape().num_dims();
assert!(args_len >= rank, "broadcast args ({args_len}) must be >= rank ({rank})");

Try / catch

// The API panics rather than returning Result; validate lengths beforehand:
if args.len() < x.shape().num_dims() { args = pad_with_ones_left(args, x.shape().num_dims()); }

Prevention

Left-pad broadcast/reshape literals with 1s (or -1) to match the tensor rank
Derive target shapes from x.dims()/Shape instead of hardcoded short literals
When ranks change (new batch/channel dims), update every reshape/expand site
In generic code, tie D2 >= D1 via types rather than runtime literals

When it happens

Trigger: Calling reshape/expand-style APIs (e.g. tensor.reshape(...) taking broadcast args) with an array shorter than the tensor's rank D1; hardcoding a small shape literal like [1, 32] against a 4-D tensor; using a const-generic D2 smaller than D1 from a generic function.

Common situations: Porting PyTorch view/expand code where -1 semantics differ and fewer dims were passed; writing layer code where the tensor rank changed (added batch/channel dims) but the broadcast literal didn't; miscasting a slice of the shape array.

Related errors

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