Add Always metabloq to simplify decompositions with compute-uncompute pairs

[anurudhp]

It's getting quite tedious to override bloqs with a cv: Optional[int] attribute, and writing a lot of if-else logic to wire the controlled version correctly. IgnoringCtrl is an alternate idea I had that should hopefully simplify writing bloq decompositions. It:

• has a "trivial" ctrl system: passes the controls through (like _BookkeepingBloq)
• has the same signature as the subbloq

The user simply has to wrap their compute-uncompute bloqs in IgnoringCtrl and the rest should work automatically. Caveat: will produce wrong results (simulation and costs) if not correctly wrapped, so should be used with caution. But is probably slightly less error-prone as it avoids code duplication: the previous solution with cv requires the user to carefully repeat the same logic in the if-else branches (one with and one without controls).

@mpharrigan thoughts? Do you think this is a good idea?

fixes #1413

upd: renamed to Always

[mpharrigan]

Thanks! I'll have to take a close look at this, and I may have some doc changes or naming suggestions since it will be especially important to communicate why and when this construct makes sense

[mpharrigan]

I suspect the "right" thing to do would be to have a Compute-Uncompute metabloq, but that's probably a lot of work. I have to think whether a construct like this could solve the immediate issue without introducing too much tech debt.

[mpharrigan]

Yeah, I think this makes me slightly too uncomfortable. The meta-bloq doesn't make sense on its own. If I tell you I have a Controlled(x) or Adjoint(x), that's an object you might actually want. Of course, we do have bookeeping bloqs including AutoPartition(x, ...). Even that makes sense as an object: it's x with a modified signature. The proposed metabloq is trying to "tag" the existing bloq object with a signal that can be interpreted by the default "controlled" infrastructure.

• I think having a Conjugate(U, V) metabloq makes sense as an object you'd want to have.
• I'm trying to brainstorm if there is a "cleaner" way to signal to the controlled infrastructure how to handle cases like this without adding a metabloq

[mpharrigan]

One thought would be to have an attribute on the prepare bloq that tells it whether it's part of a compute/uncompute pair, and it can decide whether to control itself based on that. This constrains the hackiness-surface to the issue at hand rather than giving a new bookkeeping bloq that could be used arbitrarily.

In this case, it might be tricky because the prepare bloq is nested in parameter attributes. Just a thought

[anurudhp]

I think having a Conjugate(U, V) metabloq makes sense as an object you'd want to have.

Yep, this should be added at some point (#1221). A few issues that complicate it:

• Figuring out the signature is a bit tricky, and we may need to AutoPartition the bloqs U, V to map the registers correctly.
• A lot of decompositions right now look like

bb.add(U, ...)
# add many bloqs (on different registers)
bb.add(U.adjoint(), ...)

so it forces writing a new bloq to pass as V.

• Multiple compute-uncompute pairs will be nested now, as opposed to a simpler straight-line decompositions before. This may make it a bit unreadable.

One thought would be to have an attribute on the prepare bloq that tells it whether it's part of a compute/uncompute pair, and it can decide whether to control itself based on that.

This also seems to be the way quipper does it, for example.
I think being nested should not be a problem, the intermediate bloqs may still be controlled, but the control would get ignored when the decomp reaches the prepare bloq.
Edit: Ah in case you meant setting the flag at a higher level, when the prepare is nested, yeah that would be a problem.

[mpharrigan]

"nested" in the sense that the bloq is passed as an attribute, so the decompose method would have to set the 'always' flag on the subbloq (i.e. prepare)

---

Another place where we want to "always" do a bloq that isn't part of compute/uncompute is something like AddK where we control the loading of k into an ancilla register but always do the Add. This wouldn't be handled by a compute/uncompute abstraction; so maybe we do need something like this current PR.

Calling it Always(x) also makes it sound more reasonable to me. "ignore control" is the how, "always x" is the what. Like I was ruminating above, it makes me comfortable if we have an actual thing we're handling rather than merely a behavior. Maybe AutoPartition should have been named Partitioned or something

You could use an Always(x) in the decomposition of a Conjugate ("Conjugated"?) metabloq

[anurudhp]

I like the naming convention. Maybe just one minor thought, Always seems a bit non-descriptive of what the behaviour is. I guess we want it to convey "always apply the bloq as-is". Also, it could be misunderstood that it ignores adjoints.

I wonder what would be a better name. 🤔

[mpharrigan]

Looks good

• let's refine the documentation a bit, since this is an unfamiliar concept in textbook quantum algorithms
• can you open an issue to port more things to use it, particularly AddK

[mpharrigan]

some final wording suggestions