Multi-level Bloq decomposition for symbolic Bloqs

[pqvr]

Description:

When you instantiate certain Bloq subclasses with Sympy symbols for register widths (e.g.)

StatePreparationAliasSampling.from_n_coeff(L, lam, precision=eps)

the call to decompose_bloq() immediately raises

DecomposeTypeError("bitsize must be a concrete value")

because each of these Bloq classes contains a guard like:

if not isinstance(self.bitsize, int):
    raise DecomposeTypeError("bitsize must be a concrete value")

This affects many Bloqs (e.g. LessThanEqual, QROM, CSwap, etc.) and prevents any symbolic-parameter subtree from ever being expanded when you convert to QREF + GraphViz. All you ever see is a monolithic leaf.

There is a private _decompose_from_build_composite_bloq() that builds a CompositeBloq via the call-graph, but it still runs the same per-class guards, so it also refuses on symbolic bitsizes.

Why the “obvious” fixes don’t work

• Centralizing dual-fallback in the QREF importer
  We could catch DecomposeTypeError and call _decompose_from_build_composite_bloq() instead—but that builder itself enforces the same isinstance(bitsize, int) checks, so symbolic widths are still rejected.

• Using from_callgraph=True
  There is already a bloq_to_qref(..., from_callgraph=True) path, but it only reconstructs a flat call-graph of Bloqs. It does not produce real port definitions or connection wiring in the resulting RoutineV1, so to_graphviz on that schema loses all topology.

Minimal repro

import sympy
from qualtran.bloqs.state_preparation import StatePreparationAliasSampling

L, lam, eps = sympy.symbols("L lam eps")
alias = StatePreparationAliasSampling.from_n_coeff(L, lam, precision=eps)

cb = alias.decompose_bloq()       # CompositeBloq with 5 leaves
for inst in cb.bloq_instances:
    inst.bloq.decompose_bloq()    # always raises DecomposeTypeError

Related

MR #1643 adds a dual-fallback for numeric Bloqs, but it still fails for symbolic cases because of the per-class guards.

Tagging @mstechly

[mpharrigan]

I wouldn't get hung up on the decompose_bloq -> _decompose_from_build_composite_bloq -> build_composite_bloq chain, as it does some standard bookkeeping and all the logic is in each bloq's build_composite_bloq.

---

There are certain bloqs for which a symbolic decomposition is impossible. The simplest example is OnEach, which takes an n-bit wire and applies n single-qubit operations. How do you create a DAG for this when n is a symbol? How do you get graphviz to draw a graph with a symbolic number of nodes?

It is true that there are probably some bloqs whose decomposition can be re-worked to stay symbolic for longer. Many early implementations quickly split up all registers and operated on single qubits. So something like LessThanEqual or QROM might have a level of symbolic decomposition. But something like CSwap really shouldn't. It's the same case as the OnEach example.

[pqvr]

Thanks, @mpharrigan, that makes sense. Agreed that in many cases (like OnEach or CSwap), a symbolic decomposition would be ill-defined. There's no meaningful way to create a graph with a symbolic number of nodes, especially for to_graphviz or other concrete backends.

My goal here wasn't to fully decompose every symbolic Bloq, but more to support symbol-aware, partial expansion when possible. For example:

• Some Bloqs like LessThanEqual or QROM might be able to decompose into a symbolic-level representation that still reflects control/dataflow structure (even if they can’t be split into single-qubit gates).
• Even a partial decomposition (where submodules preserve symbolic register sizes as params) would help visualize how symbolic programs are assembled.

That said, I understand that current build_composite_bloq methods often guard on int and thus opt-out of symbolic handling early. Maybe in the future, for a subset of Bloqs, we could explore supporting symbolic register types (or symbolic arrays of Bloqs) to enable higher-level visualization. Hopefully what I've written here makes sense, and thank you for your input!

[mpharrigan]

Yes, it would be nice to support more symbolic-aware decompositions that don't immediately split everything into bits! This would mean re-working the build_composite_bloq methods of the bloqs in question. The infrastructure part of Qualtran supports symbolically sized "wires", see e.g. Negate https://github.com/quantumlib/Qualtran/blob/main/qualtran/bloqs/arithmetic/negate.py#L28 which has an example with a symbolic bitsize on which you can call decompose_bloq.

The guards should only exist in places where the decomposition (as written) splits up wires or otherwise depends on having a concrete parameter.