Create ApplyLthBloq as a simple SELECT oracle

[charlesyuan314]

This bloq provides a simple way to coherently index into a list of bloqs that have identical signature and all THRU registers. Unlike the more specialized Select oracles that are currently available, it makes no additional assumptions on the behavior of these bloqs and deduces necessary register sizes automatically.

This bloq essentially implements ApplyL from #721. It will be used to implement linear combinations of block encodings.

[tanujkhattar]

What's the motivation of this bloq with these restrictive constraints? Where will this be used?

[charlesyuan314]

This bloq will be used to implement linear combinations of block encodings given a list of those constituent block encodings and their corresponding coefficients.

Before creating this bloq, I checked the existing implementations of Select oracles, and did not find any whose interface simply accepts a list of bloqs and coherently indexes into that list as needed for the block encoding.

I could be wrong, but the constraints here (all ops in the list have the same signature of only THRU registers) are strictly weaker than certain other existing Select oracles (e.g. ApplyGateToLthQubit, which additionally requires the gates to be single-qubit).

Is there a way in which you find these constraints to be inappropriately restrictive?

[charlesyuan314]

As you mentioned in your main comment:

Wouldn't the restriction that all block encodings in the LCU should have the same signature be restrictive?

Could you give an example of this condition being overly restrictive? Our quantum interface for block encodings already requires these signatures to be identical up to the sizes of ancilla and resource registers. In this case, the implementation of the LinearCombination block encoding is responsible for harmonizing these registers --- I've implemented that logic as part of a later PR.

The reason I didn't generalize the logic to harmonize registers and put it into this bloq is because the logic seems to be case-dependent. For example, the bits of the ancilla register are reused among the constituent block encodings, but it's unclear whether this should hold of arbitrary other registers in the signatures of bloqs that ApplyLthBloq selects from.

[tanujkhattar]

Suppose you want to construct a block encoding for an SK model hamiltonian. The hamiltonian is represented as

$$ H = \sum_{i < j} w_{i, j} Z_{i} Z_{j} $$

We can rewrite the hamiltonian as a summation over a single contiguous index $k$ that goes from $0$ to $\frac{n(n-1)}{2}$ s.t.

$$ H = \sum_{k} w_{k} Z_{k, 0} Z_{k, 1} $$

Now I have an LCU over $\frac{n(n-1)}{2}$ terms. Here each term is a Unitary block encoding with U=ZZ gate; i.e. Unitary(U=ZZ, alpha=1, ancilla_bitsize=0, resource_bitsize=0, epsilon=0). The system_bitsize would be 2 since the unitary acts on 2 qubits.

Now, if I do the more "intuitive" thing and simply construct an array of size $K=\frac{n(n-1)}{2}$ where each element is a unitary block encoding as described above and pass it to your LCUBlockEncoding bloq to construct a block encoding for my hamiltonian, then I'll get a wrong result. This is because the current interface does not encode information about "which qubits you want to apply the i'th bloq on". To encode this information, I'll have to wrap all these unitaries in a wrapper which encodes in the information about Z_{k, 0} Z_{k, 1} such that each bloq acts on all the $K$ qubits instead of only two qubits and then pass this list of wrappers to the LCUBlockEncoding interface.

Instead of forcing users to wrap every term of the LCU in a wrapper that acts on the entire system register; we can also provide an abstraction which accepts a Bloq and maybe an ndarray of indices that tell you on which subset of qubits from your system register you want to apply the bloq on to construct the block encoding.

But I'm just curious to understand better if you've already thought about this problem and have a preferred approach one way or the other.

Before creating this bloq, I checked the existing implementations of Select oracles, and did not find any whose interface simply accepts a list of bloqs and coherently indexes into that list as needed for the block encoding.

This is because all existing Select oracles are for specific problem instances where we have more problem specific information about "where to apply the i'th bloq" and so we didn't need a generalized version of indexing into the i'th bloq given a list of bloqs.

[charlesyuan314]

Instead of forcing users to wrap every term of the LCU in a wrapper that acts on the entire system register; we can also provide an abstraction which accepts a Bloq and maybe an ndarray of indices that tell you on which subset of qubits from your system register you want to apply the bloq on to construct the block encoding.

Thanks for giving the example. It makes sense and was not a case that I had previously considered.

If it's OK with you, I'd like to add support for such unitaries that act over distinct parts of the system register in a follow-up PR after this one.

[mpharrigan]

Thanks for the write-up @tanujkhattar . If I understand it correctly, you're objecting to wrapping each operation so it has a consistent set of registers. This introduces a level of indirection; but makes a very conceptually simple bloq composition. If I understand it correctly, it would additionally unblock having a symbolic decomposition of a SELECT oracle which has myriad benefits

[tanujkhattar]

If I understand it correctly, you're objecting to wrapping each operation so it has a consistent set of registers

Quoting from my comment above "But I'm just curious to understand better if you've already thought about this problem and have a preferred approach one way or the other."

I am not objecting to anything. I was just pointing out that we will have cases where the LCU block encoding would be composed of parts which act on different parts of the system. We should either provide a wrapper or an abstraction to capture which bloq acts on which part of the subsystem. Both of these would be fine ways of doing things.

If we use a wrapper, we also risk exposing an API that users can use incorrectly -- see my example above on following the more intuitive approach and how that leads to a bloq which doesn't raise an error on construction but is an incorrect bloq encoding.

[tanujkhattar]

Left a round of comments. Curious to learn more about the motivation for this Bloq. I believe the motivation for this bloq is to implement bloq encoding for a linear combination of block encodings? Wouldn't the restriction that all block encodings in the LCU should have the same signature be restrictive?

I would also suggest to update the existing ApplyGateToLthQubit instead of adding a new ApplyLthBloq since this seems like a generalization of the one that exists (with a caveat that we need a wrapper which would have a signature acting on "all" qubits but would decompose into specific subsets of operations acting on a subset of target qubits) -- but I'm happy to accept this as a new Bloq as well.

[charlesyuan314]

I would also suggest to update the existing ApplyGateToLthQubit instead of adding a new ApplyLthBloq since this seems like a generalization of the one that exists (with a caveat that we need a wrapper which would have a signature acting on "all" qubits but would decompose into specific subsets of operations acting on a subset of target qubits)

I agree that something like that wrapper would be needed to implement this functionality by generalizing the existing ApplyGateToLthQubit. I'm happy to think about this more once we reach agreement on the nature of and restrictions on the signatures of the constituents in ops. Tracking in the comment thread above.

[charlesyuan314]

I made the suggested changes to feature an NDArray of bloqs to iterate over.

After merging this PR, I plan to create an issue to track support by ApplyLthBloq for sub-bloqs acting over different subsets of the system register. Afterwards, it would be possible to consider merging the capabilities of ApplyLthBloq and ApplyGateToLthQubit.

[mpharrigan]

This LGTM. @tanujkhattar do you have any additional notes?

[tanujkhattar]

LGTM % comments.

[charlesyuan314]

I've addressed all of the latest round of comments.