float_scatter with {other:?} update is not implemented

Error message

float_scatter with {other:?} update is not implemented

What it means

float_scatter on the CubeCl backend implements only IndexingUpdateOp::Add and IndexingUpdateOp::Mul. Other update-op variants hit the catch-all arm and panic with unimplemented!. Like the int variant, this is a deliberate backend feature boundary.

Source

Thrown at crates/burn-cubecl/src/ops/tensor.rs:194

    fn float_scatter(
        dim: usize,
        tensor: FloatTensor<Self>,
        indices: IntTensor<Self>,
        value: FloatTensor<Self>,
        update: burn_backend::tensor::IndexingUpdateOp,
    ) -> FloatTensor<Self> {
        match update {
            burn_backend::tensor::IndexingUpdateOp::Assign => {
                kernel::scatter_assign(dim, tensor, indices, value)
            }
            burn_backend::tensor::IndexingUpdateOp::Add => {
                kernel::scatter(dim, tensor, indices, value, false)
            }
            burn_backend::tensor::IndexingUpdateOp::Mul => {
                kernel::scatter_mul(dim, tensor, indices, value)
            }
            other => unimplemented!("float_scatter with {other:?} update is not implemented"),
        }
    }

    fn float_scatter_nd(
        data: FloatTensor<Self>,
        indices: IntTensor<Self>,
        values: FloatTensor<Self>,
        reduction: burn_backend::tensor::IndexingUpdateOp,
    ) -> FloatTensor<Self> {
        kernel::scatter_nd(data, indices, values, reduction)
    }

    fn float_gather_nd(data: FloatTensor<Self>, indices: IntTensor<Self>) -> FloatTensor<Self> {
        kernel::gather_nd(data, indices)
    }

    fn float_select(
        tensor: FloatTensor<Self>,

View on GitHub (pinned to d16f7ba2ed)

Solutions

Emulate Sub via Add with negated update values (works for floats).
Use slice_assign with gathered/computed index regions for arbitrary update semantics.
Implement the missing arm with a new CubeCl float scatter kernel and submit upstream.
Check the burn docs/issue tracker for which IndexingUpdateOp variants your backend supports.

Example fix

// before
let out = tensor.scatter(1, indices, updates, IndexingUpdateOp::Sub);
// after
let out = tensor.scatter(1, indices, -updates, IndexingUpdateOp::Add);

Defensive patterns

Strategy: validation

Validate before calling

fn assert_scatter_op_supported(op: &IndexingUpdateOp) {
    assert!(
        matches!(op, IndexingUpdateOp::Add | IndexingUpdateOp::Mul),
        "float_scatter on CubeCl supports only Add/Mul"
    );
}

Type guard

fn is_supported_scatter_op(op: &IndexingUpdateOp) -> bool {
    matches!(op, IndexingUpdateOp::Add | IndexingUpdateOp::Mul)
}

Prevention

Use only Add/Mul for float scatter on CubeCl
Negate values and use Add to express subtraction
Test scatter paths on every backend you ship
Follow burn issue tracker for new IndexingUpdateOp kernel support

When it happens

Trigger: Calling float_scatter (or Tensor::scatter) on a FloatTensor with the CubeCl backend using an IndexingUpdateOp other than Add/Mul, e.g. Sub or Max.

Common situations: Scatter-subtract gradients or custom scatter-reduce semantics; porting NumPy/torch scatter_reduce code with 'subtract' reduction; new IndexingUpdateOp variants added upstream without a CubeCl float kernel.

Related errors

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