TensorCheck::matmul short-circuits for D < 2 in crates/burn-tensor/src/tensor/api/check.rs:
check = check.binary_ops_device("Matmul", &lhs.device(), &rhs.device());
if D < 2 {
return check;
}
Tensor::matmul is defined generically over Tensor<D, K> where K: Numeric, so Tensor<1>::matmul compiles but skips all validation. Rank-1 inputs have no matrix dimensions, so the operation is ill-defined; the matmul docs only describe [..., M, K] @ [..., K, N] shapes.
What happens today, per backend:
- ndarray: panics in
crates/burn-ndarray/src/ops/matmul.rs with attempt to subtract with overflow (it indexes shape_lhs[ndims - 2] with ndims == 1).
- tch: libtorch treats 1D x 1D
matmul as a dot product and returns a 0-dim scalar, which does not match the Tensor<1> output rank.
- cubecl: not a valid kernel input.
None of these produce a usable Tensor<1> result; the backends fail in inconsistent, hard-to-debug ways.
Proposal: have TensorCheck::matmul reject ranks < 2 with a clear message (mirroring the TensorCheck::tri pattern) and add a should_panic regression test in burn-backend-tests/tests/tensor/float/ops/matmul.rs.
TensorCheck::matmulshort-circuits forD < 2incrates/burn-tensor/src/tensor/api/check.rs:Tensor::matmulis defined generically overTensor<D, K>whereK: Numeric, soTensor<1>::matmulcompiles but skips all validation. Rank-1 inputs have no matrix dimensions, so the operation is ill-defined; the matmul docs only describe[..., M, K] @ [..., K, N]shapes.What happens today, per backend:
crates/burn-ndarray/src/ops/matmul.rswithattempt to subtract with overflow(it indexesshape_lhs[ndims - 2]withndims == 1).matmulas a dot product and returns a 0-dim scalar, which does not match theTensor<1>output rank.None of these produce a usable
Tensor<1>result; the backends fail in inconsistent, hard-to-debug ways.Proposal: have
TensorCheck::matmulreject ranks < 2 with a clear message (mirroring theTensorCheck::tripattern) and add ashould_panicregression test inburn-backend-tests/tests/tensor/float/ops/matmul.rs.