[RFC] Introduce cudaq::pauli_word type to the language

[amccaskey]

A powerful mechanism for circuit synthesis would be to accept cudaq::spin_op as input to a quantum kernel and use that with a synthesis operation like exp_pauli. Fully supporting spin_op via the AST Bridge and MLIR is a large task. An easier stepping stone that would enable a wide range of use cases (ones we are already seeing) is to introduce a cudaq::pauli_word type. This type would model a single term in a spin_op. For example, the spin_op op = x(0) * y(1) - 2.0 * z(0) z(1) would contain 2 pauli words, specifically X0 Y1 and Z0 Z1 (I propose we ignore the coefficient as part of our cudaq::pauli_word type, coefficients can be extracted from a spin_op and passed separately as a std::vector<double>). So the type would effectively provide an opaque type that map to a ptr<i8> in the AST Bridge and be compatible with our existing ExpPauliOp.

__qpu__ void test(double theta, std::vector<cudaq::pauli_word> paulis) {
  cudaq::qvector q(2);
  for (auto &p : paulis)
    exp_pauli(theta, q, p);
}

void useTest() {
  spin_op op = ... ;
  auto words = op.to_pauli_words();
  auto results = cudaq::sample(test, M_PI_2, words);
}

kernel, thetas, paulisArg = cudaq.make_kernel(list[float], list[cudaq.pauli_word])
qubits = kernel.qalloc(2)
kernel.x(qubits[0])
kernel.for_loop(
     0, paulisArg.size(),
     lambda idx: kernel.exp_pauli(thetas[idx], qubits, paulisArg[idx]))

Note this is related to PR #1062. It seems smarter to force this type of input to be a separate type in the language rather than a catch-all const char *.

[justinlietz]

For example, the spin_op op = x(0) * y(1) - 2.0 * z(0) z(1) would contain 2 pauli words, specifically X0 Y1 and Z0 Z1 (I propose we ignore the coefficient as part of our cudaq::pauli_word type, coefficients can be extracted from a spin_op and passed separately as a std::vector<double>).

I think there is a lot of value in having additional pauli types. To properly model a single in a spin_op, would we support all of the math operations that can be done between two spin_op_terms?

• If yes: we should pad the bit representation (in binary symplectic form) with 2 extra bits to represent the 4 different phases that can arise from composing two elements of the pauli group (spin_op_terms) e^{k i pi /2}, k = 0, 1, 2, 3 corresponding to {+1, +i, -1, -i}. This would have value in other operations like seeing if paulis can commute or not. If these are used to construct a spin_op, the phase could be pulled into the term's coefficient at construction time and the phase bits set to zero.
• If no: If there's no math, then we're not really modeling a single term in spin_op, but this would still be a useful handle for kernel construction and spin_op construction.

As for naming, I think "pauli_word" is a good descriptor for the latter case where the lack of math/phase support is perhaps suggested in the name. If there is math support, then perhaps it could be called a "pauli_element" or something suggestive of the fact that these are elements of the n-qubit Pauli group with support for math/phases.

[bettinaheim]

RFC needs updating to capture the complete API available from both C++ and Python.

[bettinaheim]

Closing this as supported to the extend that it was defined here.