linq.translator v 2.0: qubit operators and q.circuit bidirectional conversion

[ValentinS4t1qbit]

When we designed Tangelo, we wanted to make sure users would not feel stuck with it, and would still be able to leverage the features from their favorite frameworks if that's what worked best for them.

We are starting to hear back from a few people with existing projects in Qiskit for example, who would like to import their Qiskit Pauli operators and quantum circuit to Tangelo.

Gradually adding the "missing" conversion functions for quantum circuits (e.g making the translation bidirectional) and making functions to do the same with qubit operators would be neat. These functions are usually very straightforward and just require to traverse and parse an object. We just hadn't users requesting them explicitly so far.

Maybe we could develop the "missing" conversion functions, and if that works attempt to provide a higher-level interface that easily makes the user pick a source format and select a target format. As long as we have bidirectional conversion functions to/from Tangelo format, then we can translate any source available into any target format available. The original "translate_x" functions would still be available, so that nothing breaks in user code. We could then try to slowly deprecate the feature in the future.

from tangelo.linq import translate_circuit

# Assume qiskit_c is a circuit in Qiskit format and we want a circuit in Qulacs format.
qulacs_c = translate_circuit(qiskit_c, source='qiskit', target='qulacs')

Under the hood, translate_circuit could go through the Tangelo format. It looks at source and target and calls the right functions (we could use a dictionary to map keywords to function to call, and if statements to catch invalid combinations or handle cases where source or target is tangelo format):

# assume input is Qiskit circuit, referred to as source_c
tangelo_c = translate_qiskit_to_tangelo(source_c)
target_c = translate_qulacs(tangelo_c)
return target_c

I don't expect performance issues to arise for the indirect conversion (algorithmic preparation of circuits and simulation of circuits tends to be the most expensive steps), but once we have this it's easy to write "direct" conversion functions if the need arises later on. I just don't want to go and develop all 2-format combinations of functions and add/change n of them every time a new format is introduced or an existing format changes.

Qubit operator conversion could be handled through a similar interface (translate_pauli_op ?). These changes could be seen as a natural evolution for the translator module, and part of the "linq 2.0" work.

===================

Any thoughts / comments ? If someone is interested to work on this, don't hesitate. I think it should be straightforward, and is a rather straightforward opportunity to practice rather simple python, get familiar with what established packages use, and go through the PR process.

[alexfleury-sb]

I like the target and source keywords idea. It reminds me of the OpenBabel user interface.

On the subject of QubitOperator, the main difference between openfermion and qiskit is (respectively) the use of tuples (without defining I) and string (with the I specification). For example, the conversion from a tangelo QubitOperator to a qiskit format is easy:

H_list = list()
for term_tuple, coeff in H.terms.items():
    term_string = str()
    term_dict = dict((x, y) for x, y in term_tuple)
    for n in range(n_qubits):
        term_string += term_dict.get(n, "I")
    H_list += [(coeff.real, term_string)]

[ValentinS4t1qbit]

Yeah, we actually used to have target and source in older versions of what became linq, which I think were removed to just keep code simple with what we had.

And your code snippet supports my point: the conversion between different formats is usually very straightforward. Traverse, parse. Repeat for different source / target formats.

Overall, I think it's not a big work: a first pull request could leave some formats out (I wouldn't mind leaving Q# out of that first PR, I am not sure who is using it these days, especially since Azure Quantum now supports Cirq / Qiskit / openqasm formats) and focus on the main formats, and provide a higher-level interface.

[alexfleury-sb]

Work about the translation of qubit operators is in progress in #196. For now, it will support qiskit <-> tangelo (or openfermion) qubit operators.

[alexfleury-sb]

Got some progress done in the refactoring in my fork (https://github.com/AlexandreF-1qbit/Tangelo/tree/translator_v2). I will push that to a PR soon!

[alexfleury-sb]

FYI: #223 is in review and soon to be merged.

[ValentinS4t1qbit]

The work has been done, and is detailed in our release notes.

We'll support more formats etc as needed, or if users reach out about them.

[ValentinS4t1qbit]

Looks like I forgot to close this back then