Classical expression `Value` does not store data correctly

[gadial]

Environment

• Qiskit version: 2.2
• Python version: 3.13
• Operating system: Linux

What is happening?

when expr.Value is of type Uint it is expected to have unbounded precision. When it was implemented in Python, this was the case automatically; in Rust the value is converted to f64 when it is too big, causing precision loss.

How can we reproduce the issue?

from qiskit.circuit.classical import expr, types
n = 10
val = expr.Value(n, types.Uint(1)),
print(val[0].value == n) # returns True
n = 100000000000000000000000000000000000
val = expr.Value(n, types.Uint(1)),
print(val[0].value == n) # returns False

What should happen?

The code above should return True in both cases; the integer value should be stored as an unbounded sequence of bytes.

Any suggestions?

The QPY component already had this problem and solved it:

        elif isinstance(node.value, int):
            self.file_obj.write(type_keys.ExprValue.INT)
            if node.value == 0:
                num_bytes = 0
                buffer = b""
            else:
                # This wastes a byte for `-(2 ** (8*n - 1))` for natural `n`, but they'll still
                # decode fine so it's not worth another special case.  They'll encode to
                # b"\xff\x80\x00\x00...", but we could encode them to b"\x80\x00\x00...".
                num_bytes = (node.value.bit_length() // 8) + 1
                buffer = node.value.to_bytes(num_bytes, "big", signed=True)
            self.file_obj.write(
                struct.pack(formats.EXPR_VALUE_INT_PACK, *formats.EXPR_VALUE_INT(num_bytes))
            )
            self.file_obj.write(buffer)

This can be done easily in Value.

[gadial]

In addition to the above (serious) problem, I have another smaller rambling:

In rust classical expressions, we have Value which is

pub enum Value {
    Duration(Duration),
    Float { raw: f64, ty: Type },
    Uint { raw: u64, ty: Type },
}

Where Type is

pub enum Type {
    Bool,
    Duration,
    Float,
    Uint(u16),
}

This allows cases where we have a Value which is a Uint but has a Type element which is Float and similar cases. Since Rust demands being very explicit about handling all cases, this results in having to explicitly deal with this cases (and throw exceptions in situation where different data structure would have avoided them altogether).

It seems to me that this problems results from too directly emulating the structure of Value in Python, instead of relying on Rust's powerful pattern matching. I suggest a small overhaul, as part of fixing the above bug, to make the inner rust representation of Value free of such cases, while maintaining the Python interface as-is.

[kevinhartman]

Thanks @gadial for catching this, we're apparently missing a test on the Python side for integers wider than 64 bits.

It looks like @mtreinish has already mentioned num_bigint::BigUInt elsewhere, but I think the best fix here is likely just to use that in place of the u64 for Value::raw.

Regarding the other changes to Value you're proposing (this is the same thing I wrote on Slack, but for posterity):

The reason [I did that] was that Value is an expression, and all expressions have an explicit Type. You can see this if you look at all of the expression variant types in the Expr enum—they all have ty (unless the expression can't be anything else, like how a Stretch is always a duration). If you manually construct an expression value, it looks like this:

let my_val = Expr::Value(Value::Uint {
    raw: 5,
    ty: Type::Uint(3),
});

If we use the representation you mention, then the Type is something we would be inferring from the contents of the Value, which is inconsistent with the rest of the expression model.

So it's more just a matter of letting the expression builders we have explicitly "stamp" the type on whatever expression they build.

Rust pattern matching is great, but to my knowledge Qiskit isn't planning on optimizing classical expressions, so I'm not sure there are many use cases for destructuring outside of QPY 🙂.