KetBraSum

[tonybruguier]

This could be the first PR towards closing issue #3288.

[tonybruguier]

Hello,
Is this PR on the right overall direction? I'm happy to withdraw or start over if not.

[viathor]

Had a quick look and one thing I noticed is that the new class only allows to define projectors onto one state in the computational basis. In particular, we cannot project onto the plus state in single-qubit case or onto the span(|01>, |10>) subspace in two-qubit case.

Added @MichaelBroughton to comment on what we need for the TFQ use-case.

[tonybruguier]

Sorry I had misunderstood the requirements. I changed the API to accept more than one projection basis and also allow vectors like |+>.

Happy to modify/fix further.

[MichaelBroughton]

This looks great, before getting into a detailed review, I am curious how easily this could be extended to do things like:

q = cirq.GridQubit(0, 0)
my_paulisum = 0.5 * cirq.X(q) * cirq.Z(q) + 5 * cirq.Y(q)
my_paulisum_and_projector = my_paulisum + cirq.Projector([[1,0]])  # This maintains a compact representation.

This was an important role for projectors when we first opened the issue :)

[tonybruguier]

This looks great, before getting into a detailed review, I am curious how easily this could be extended to do things like:

q = cirq.GridQubit(0, 0)
my_paulisum = 0.5 * cirq.X(q) * cirq.Z(q) + 5 * cirq.Y(q)
my_paulisum_and_projector = my_paulisum + cirq.Projector([[1,0]])  # This maintains a compact representation.

This was an important role for projectors when we first opened the issue :)

I do not know yet (sorry, I'm still learning). In the original issue #3288 it was discussed to do in two PRs, so I was planning to wait for that. However, it would be nice for @viathor to comment. I'm happy to make any change, either here or in a subsequent PR.

For the other comments, I tried to address them so PTAL.

[MichaelBroughton]

Left some more comments. This looks good to me, but I will delegate to @viathor for final say on things.

[95-martin-orion]

Paging @balopat for re-review: what is the plan for this PR?

[viathor]

Friendly ping, @balopat, this probably needs your attention :-)

[balopat]

Yes, I need to sit down and think this through again.
Issues:

• naming: ketbrasum doesn't sit well
• I still don't have any answers around how this would really work when we mix operator representations as @MichaelBroughton wants to I.e. cirq.X(q0) + cirq.I(q2) + cirq.Z(q1) * |001><001| - do we support products? or just sums? I feel like instead of trying to get in something incremental we should prototype the final solution, play with it until we like the design, and then based on that get either incremental PRs out or just the whole thing in one go.

[95-martin-orion]

@balopat, should we bring this (or the related RFC: https://tinyurl.com/ketbra) to either the weekly sync or the internal design discussion for re-review? It's been open for a long time now, but seems to be chronically stuck behind design considerations.

[balopat]

@balopat, should we bring this (or the related RFC: https://tinyurl.com/ketbra) to either the weekly sync or the internal design discussion for re-review? It's been open for a long time now, but seems to be chronically stuck behind design considerations.

As @MichaelBroughton requested the projectors originally and is taking over the helm, I actually asked him to have a look into this and make a call.

[tonybruguier]

I added the entry for next week's meeting. I would like to have a net positive contribution (more work produced than help received), so happy to continue working on it, happy to hand it off to someone else, happy to drop it.

[MichaelBroughton]

I think unfortunately we may have had too many cooks in the kitchen on this one and became a little sidetracked on things. I think this might be worth starting over with a new PR chain with the following things:

For TFQ, we don't need the ability to do arbitrary KetBraSums we just need the ability to do projectors with computational basis states and nothing more (in fact general KetBraSums would be too hard for us to handle). The nice things about these projectors is that their expectation value is also very easy to evaluate on a real device by just counting the number of times you find the projector bit-string in your measurements.

With all that being said I think we should revert back to something like this where KetBras -> ProjectorStrings (like PauliStrings) and KetBraSum -> ProjectorSum (like PauliSum), so that we can keep hardware compatibility, with potential future integrations to things like Observable measurements, cirq.ProductStates, as well as the original behavior we wanted in TFQ. If we need more general outer product sums I think we should revisit KetBraSums at a later date and get ProjectorSums going first. What do you think @viathor , @balopat ?

[tonybruguier]

@MichaelBroughton I am withdrawing in favor of #4331