tracel-ai/burn · error

unsupported dtype: {other:?}

Error message

unsupported dtype: {other:?}

What it means

Same family as error 420 but from `execute_with_float_out_dtype!`: a float-output op in the ndarray backend dispatches on the requested out dtype, and the catch-all `other` arm panics because no float arm matches. The macro only expands arms for the float element types the backend supports.

Source

Thrown at crates/burn-ndarray/src/tensor.rs:333

            _ => panic!("Unsupported dtype: {:?}", $tensors[0].dtype())
        }
    };
}

/// Macro to execute an operation that returns a given element type.
#[macro_export]
macro_rules! execute_with_float_out_dtype {
    ($out_dtype:expr, $element:ident, $op:expr, [$($dtype: ident => $ty: ty),*]) => {{
        match $out_dtype {
            $(
                burn_std::FloatDType::$dtype => {
                    #[allow(unused)]
                    type $element = $ty;
                    $op
                }
            )*
            #[allow(unreachable_patterns)]
            other => unimplemented!("unsupported dtype: {other:?}")
        }
    }};
    // Unary op: type automatically inferred by the compiler
    ($out_dtype:expr, $op:expr) => {{
        $crate::execute_with_float_out_dtype!($out_dtype, E, $op)
    }};

    // Unary op: generic type cannot be inferred for an operation
    ($out_dtype:expr, $element:ident, $op:expr) => {{
        $crate::execute_with_float_out_dtype!($out_dtype, $element, $op, [
            F64 => f64, F32 => f32
        ])
    }};
}

/// Macro to execute an operation that returns a given element type.
#[macro_export]
macro_rules! execute_with_int_out_dtype {

View on GitHub (pinned to d16f7ba2ed)

Solutions

1. Use F32 tensors (the default supported float dtype) for the operation.
2. Enable the backend feature for the needed float dtype if available.
3. Cast inputs and specify a supported out dtype (`.cast(DType::F32)`).
4. Verify model export settings so weights are stored as f32.

Example fix

// before
let out = tensor_f64 + other_f64;
// after
let out = tensor_f64.cast(DType::F32) + other_f64.cast(DType::F32);

fn assert_float_out_dtype(d: DType) -> bool {
    matches!(d, DType::F32) // extend per your backend's enabled features
}
let out = if assert_float_out_dtype(input.dtype()) { input.clone() } else { input.cast(DType::F32) };

fn is_f32(d: DType) -> bool { matches!(d, DType::F32) }

When it happens

Trigger: Invoking a float op (e.g. matmul, activation) via this macro with a float out-dtype not covered by the macro arms, such as F64 or F16 with an ndarray backend compiled only for F32.

Common situations: Running float64 training/inference on the CPU ndarray backend; using a half-precision model without enabling the corresponding backend feature; dtype inferred from input data files (e.g. f64 numpy arrays).

Related errors

• Quantization scheme is not valid for dtype {other:?}
• Can't store native sub-byte values
• burn-flex does not support Bool(U32) storage (only Native an
• compare_int: unsupported dtype {:?}
• compare_int_elem: unsupported dtype {:?}

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