What causes "float_cumprod: unsupported dtype {:?}" in tracel-ai/burn?

Cast the tensor to a float dtype before cumprod, then cast back if needed.

float_cumprod: unsupported dtype {:?}

Error message

float_cumprod: unsupported dtype {:?}

What it means

float_cumprod computes the running product, supporting F32/F64 directly and F16/BF16 via half-precision kernels that round-trip through f32. Any other dtype reaching the op panics with the dtype printed. The backend intentionally restricts cumprod to float tensors.

Source

Thrown at crates/burn-flex/src/ops/float.rs:786

            }
            DType::BF16 => {
                crate::ops::cumulative::cumsum_half(tensor, dim, bf16::to_f32, bf16::from_f32)
            }
            _ => panic!("float_cumsum: unsupported dtype {:?}", tensor.dtype()),
        }
    }

    fn float_cumprod(tensor: FloatTensor<Flex>, dim: usize) -> FloatTensor<Flex> {
        match tensor.dtype() {
            DType::F32 => crate::ops::cumulative::cumprod_f32(tensor, dim),
            DType::F64 => crate::ops::cumulative::cumprod_f64(tensor, dim),
            DType::F16 => {
                crate::ops::cumulative::cumprod_half(tensor, dim, f16::to_f32, f16::from_f32)
            }
            DType::BF16 => {
                crate::ops::cumulative::cumprod_half(tensor, dim, bf16::to_f32, bf16::from_f32)
            }
            _ => panic!("float_cumprod: unsupported dtype {:?}", tensor.dtype()),
        }
    }

    fn float_cummin(tensor: FloatTensor<Flex>, dim: usize) -> FloatTensor<Flex> {
        match tensor.dtype() {
            DType::F32 => crate::ops::cumulative::cummin_f32(tensor, dim),
            DType::F64 => crate::ops::cumulative::cummin_f64(tensor, dim),
            DType::F16 => {
                crate::ops::cumulative::cummin_half(tensor, dim, f16::to_f32, f16::from_f32)
            }
            DType::BF16 => {
                crate::ops::cumulative::cummin_half(tensor, dim, bf16::to_f32, bf16::from_f32)
            }
            _ => panic!("float_cummin: unsupported dtype {:?}", tensor.dtype()),
        }
    }

    fn float_cummax(tensor: FloatTensor<Flex>, dim: usize) -> FloatTensor<Flex> {

View on GitHub (pinned to d16f7ba2ed)

Solutions

Cast the tensor to a float dtype before cumprod, then cast back if needed.
Verify the input-producing ops did not return Int tensors (e.g. comparisons, casts, indexing).
Use f64 instead of f32 when integer-range overflow matters, since integers converted to f32 lose precision above 2^24.
Add an integer cumprod path in the flex backend if integral semantics are required.

Example fix

// before
let p = factors.cumprod(0); // factors: I64 -> panic
// after
let p = factors
    .to_dtype(burn::tensor::FloatDType::F64)
    .cumprod(0);

Defensive patterns

Strategy: validation

Validate before calling

assert!(matches!(tensor.dtype(), DType::F32 | DType::F64 | DType::F16 | DType::BF16), "cumprod needs a float tensor, got {:?}", tensor.dtype());

Type guard

fn is_float_dtype(dtype: &DType) -> bool { matches!(dtype, DType::F32 | DType::F64 | DType::F16 | DType::BF16) }

Try / catch

// Validate before the op; Rust panics cannot be caught:
if is_float_dtype(&tensor.dtype()) { let p = tensor.cumprod(dim); }

Prevention

Use F64 for cumprod when large integer factors could exceed f32 precision.
Cast explicitly after integer-producing ops before cumulative operations.
Prefer typed tensor kinds to catch wrong dtypes at compile time.
Add dtype assertions in scan/reduction utility wrappers.

When it happens

Trigger: Calling Tensor::cumprod (cumprod along a dim) on burn-flex with an Int/Bool or otherwise non-float tensor.

Common situations: Computing running products of integer factors; cumulative-product utilities typed generically and instantiated with Int; forgetting that cumprod needs floats for the f32-based kernel.

Related errors

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