[BUG] Adjoint breaks Qualtran integration

[cvjjm]

Expected behavior

qml.to_bloq() should yield valid bloqs also for quantum functions that contain adjoint operations.

Actual behavior

Trying to call t_complexity() on a bloq made from a quantum function with adjoint leads to an Exception deep inside Qualtran:

AssertionError: Input register _QReg(qubits=(2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19), dtype=QAny(bitsize=18)) not found, suggesting a bug

Additional information

No response

Source code

import pennylane as qml
from qualtran.cirq_interop.t_complexity_protocol import t_complexity

bitstrings = ['100000101100000110', '010100110100111010']
angle_wires = [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]

def qrom_qfunc():
    # qml.QROM( # witout adjoint it works
    qml.adjoint(qml.QROM)(
        bitstrings=bitstrings,
        control_wires=[0],
        target_wires=angle_wires,
        work_wires=[],
    )
bloq = qml.to_bloq(qrom_qfunc)
tc = t_complexity(bloq)
print(tc)

Tracebacks

System information

Name: pennylane
Version: 0.43.0
Summary: PennyLane is a cross-platform Python library for quantum computing, quantum machine learning, and quantum chemistry. Train a quantum computer the same way as a neural network.
Home-page: 
Author: 
Author-email: 
License-Expression: Apache-2.0
Location: /fs/home/cvjjm/.conda/envs/.../lib/python3.13/site-packages
Requires: appdirs, autograd, autoray, cachetools, diastatic-malt, networkx, numpy, packaging, pennylane-lightning, requests, rustworkx, scipy, tomlkit, typing_extensions
Required-by: covvqetools, pennylane_lightning, qualtran

Platform info:           Linux-5.14.0-427.13.1.el9_4.x86_64-x86_64-with-glibc2.34
Python version:          3.13.9
Numpy version:           1.26.4
Scipy version:           1.16.2
JAX version:             None
Installed devices:
- lightning.qubit (pennylane_lightning-0.43.0)
- default.clifford (pennylane-0.43.0)
- default.gaussian (pennylane-0.43.0)
- default.mixed (pennylane-0.43.0)
- default.qubit (pennylane-0.43.0)
- default.qutrit (pennylane-0.43.0)
- default.qutrit.mixed (pennylane-0.43.0)
- default.tensor (pennylane-0.43.0)
- null.qubit (pennylane-0.43.0)
- reference.qubit (pennylane-0.43.0)

Existing GitHub issues

• I have searched existing GitHub issues to make sure the issue does not already exist.

[CatalinaAlbornoz]

Hi @cvjjm , thank you for reporting this.

It looks like my colleague Diego may have found a workaround, but we'll take a deeper look and get back to you next week.

Thanks again for opening this issue!

[DSGuala]

Hi @cvjjm , thanks for opening the issue. We may have a PR coming with a fix in the following days.

In the meantime, some workarounds are to use qml.adjoint(qml.QROM)(...) outside of the function or to turn map_ops to False.

Option 1, creating a PennyLane operation outside of the function:

op = qml.adjoint(qml.QROM)(
        bitstrings=bitstrings,
        control_wires=[0],
        target_wires=angle_wires,
        work_wires=[],
    )
bloq = qml.to_bloq(op)
tc = t_complexity(bloq)

>>> print(tc)
T-count:   -4
Rotations: 0
Cliffords: 0

Option 2, setting map_ops=False for a slightly different result:

def qrom_qfunc():
    # qml.QROM( # witout adjoint it works
    qml.adjoint(qml.QROM)(
        bitstrings=bitstrings,
        control_wires=[0],
        target_wires=angle_wires,
        work_wires=[],
    )
bloq = qml.to_bloq(qrom_qfunc, map_ops=False)
tc = t_complexity(bloq)

>>> print(tc)
T-count:   0
Rotations: 0
Cliffords: 67

[cvjjm]

This is helpful and good to hear you are working on a fix.

One thing that caught my eye: Your example prints T-count: -4. I don't think a negative T gate count makes sense, so something isn't quite working as it should...

[austingmhuang]

This might be a bug on Qualtran's side instead. When I manually construct the adjoint of QROM like so:

import numpy as np
from qualtran.bloqs.data_loading.qroam_clean import QROAMClean

data1 = np.arange(2, dtype=int)
data2 = np.arange(2, dtype=int) + 1
qroam_clean_multi_data = QROAMClean.build_from_data(data1, data2, log_block_sizes=(1,))
t_complexity(qroam_clean_multi_data.adjoint()) # TComplexity(t=-4, clifford=0, rotations=0)

I get T:count -4 as well. I can submit an issue on Qualtran and get their opinion -- I could be mis-using the QROAMClean Bloq potentially.

It seems like this bug is fixed on main.

[DSGuala]

Linking the negative T gate count Qualtran issue here. Looks like it's solved in Qualtran main branch 🙂