Add for_loop to cudaq::kernel_builder and cudaq.Kernel

[amccaskey]

Enable expressions like this

auto [circuit, inSize] = cudaq::make_kernel<std::size_t>();
auto qubits = circuit.qalloc(inSize);
circuit.h(qubits[0]);
circuit.for_loop(0, inSize - 1, [&](auto &index) {
  circuit.x<cudaq::ctrl>(qubits[index], qubits[index + 1]);
});

and

circuit, inSize = cudaq.make_kernel(int)
qubits = circuit.qalloc(inSize)
circuit.h(qubits[0])
circuit.for_loop(0, inSize-1, lambda index : circuit.cx(qubits[index], qubits[index+1]))
counts = cudaq.sample(circuit, 5)

#53

[schweitzpgi]

Nice.

[bettinaheim]

Requesting changes due to missing documentation.

[bettinaheim]

@amccaskey Please create or link the issue with a brief RFC.
A couple of questions off the top of my head:

• Is there going to be a dedicate loop where we iterate over e.g. an array?
• What would it look like to iterate over a QuakeValue?
• Is the iterator always incremented by +1? Why not make it more general, and how would that look like?

[bettinaheim]

@anthony-santana Please also take a look.

[amccaskey]

• like

The iterator here is just +1 since I'm trying to use existing infrastructure from the bridge. We could of course add the ability to specify the step size, but I think we should file an issue and a separate PR for that.

You can definitely use this to iterate through an existing StdVecType QuakeValue. I have added support and a test for that with the latest commit, please check it out.

I will file the issue for this, which I forgot to do...

The requested changes have been addressed.

[bettinaheim]

• like

The iterator here is just +1 since I'm trying to use existing infrastructure from the bridge. We could of course add the ability to specify the step size, but I think we should file an issue and a separate PR for that.

You can definitely use this to iterate through an existing StdVecType QuakeValue. I have added support and a test for that with the latest commit, please check it out.

I will file the issue for this, which I forgot to do...

Thanks. I would suggest to have one issue filed that captures the complete feature (all loop constructs that intend to support in the near future), even if the implementation work is split into several PRs. Let's make sure we don't need to change anything about this builder API to support additional scenarios in the future.