Pennylane-Qualtran interoperability

[austingmhuang]

In this PR, we set out to define a new method as_pl_op() for the base Bloq class as well as several "basic gates" that have direct 1:1 translations with PennyLane operators. This is a work in progress and relies on another PR inside of PennyLane that contains the qml.FromBloq adapter class. We open this now for visibility and discussion purposes, but the work is still on-going.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[mpharrigan]

nice! will probably have to add some tests. We'll also need to add pennylane to the requirements, which I can help with (since we have a convoluted system for pinning the CI dependencies)

[austingmhuang]

nice! will probably have to add some tests. We'll also need to add pennylane to the requirements, which I can help with (since we have a convoluted system for pinning the CI dependencies)

For the tests, I'm not sure where I'm supposed to add them. I took a look qualtran/_infra/bloq_test.py but I get the feeling that that's probably not where to go... do you mind pointing me in the right direction 😄 ?

[mpharrigan]

Yeah, that's a good question. Usually we'd put them alongside the code for the adapter classes; but that will reside in the Pennylane repository.

I think in this case it will suffice to have some basic unit tests for the particular examples for which you implemented the method (which can live in the test files associated with those bloqs)

[mpharrigan]

You can also add a test to _infra/bloq_test.py with a very simple test of the fallback, adapter behavior. I know it's scary that there's nothing in there, but in this case it should be fine

[austingmhuang]

Hi @mpharrigan, I added some very basic unit tests for each of the atomic bloqs I wrote an as_pl_op function for. If you think there should be additional tests e.g. tensor_contract()/matrix(), feel free to let me know and I can add them as well (Comparing tensor_contract/matrix is also tested for in PL itself, but not quite for every single bloq). I think the PR is ready for review, but I'll need the CI running to be sure :)

[mpharrigan]

Sorry, since you're a first-time contributor I have to press the "approve running the CI" button every time you push a commit, sadly

[mpharrigan]

You can run the various scripts in the check/ directory to get an approximation of some of the CI checks. In particular, if you run

check/format-incremental --apply

it will apply the formatter to your code

check/mypy
check/pylint

will report typecheck and lint errors (but you have to fix thme)

[mpharrigan]

oh, I have to update our dependencies. I will do that tomorrow

[mpharrigan]

Can the [WIP] tag be removed from the title of the PR?

[austingmhuang]

oh, I have to update our dependencies. I will do that tomorrow

Perhaps the workflow file should be edited instead for this PR specifically to get the CI passing. We can then remove it when qml.FromBloq is merged into pennylane master.

[mpharrigan]

Yes, I can update our dependencies to that specific branch for the time being. I'll open an issue to switch it back to a proper release after the qualtran features are picked up in a release. Can you ensure that that branch will survive until the next pennylane release?

[mpharrigan]

alright, if you merge in main it should pick up the branch

[austingmhuang]

Yes, I can update our dependencies to that specific branch for the time being. I'll open an issue to switch it back to a proper release after the qualtran features are picked up in a release. Can you ensure that that branch will survive until the next pennylane release?

Awesome thanks. Yes the branch will survive until the next pennylane release. I'll let you know when it's ready to merge and we can coordinate the process.

[Jaybsoni]

Looks good to me for the most part. I left a few comments to be addressed. Otherwise its good from my side 👍🏼

One question for @mpharrigan, I am not sure how paranoid we should be about conventions? For most of the tests all we are checking is that if we map a Bloq using FromBloq, we get the expected PL operator. We DONT check if the Qualtran definition of an operation is the same as the PL one. For example, I noticed in the global_phase the extra factor of pi that is used in Qualtran. Should we compare the matrix produced via tensor_contract against the qml.matrix function?

[mpharrigan]

We DONT check if the Qualtran definition of an operation is the same as the PL one. For example, I noticed in the global_phase the extra factor of pi that is used in Qualtran. Should we compare the matrix produced via tensor_contract against the qml.matrix function?

My opinion is that we should test that they're equivalent (where feasible). In the global phase op, the as_pl_op method should take care of any pi differences, yes?

[austingmhuang]

My opinion is that we should test that they're equivalent (where feasible). In the global phase op, the as_pl_op method should take care of any pi differences, yes?

Yes, the as_pl_op method takes care of the pi difference.

[Jaybsoni]

We DONT check if the Qualtran definition of an operation is the same as the PL one. For example, I noticed in the global_phase the extra factor of pi that is used in Qualtran. Should we compare the matrix produced via tensor_contract against the qml.matrix function?

My opinion is that we should test that they're equivalent (where feasible). In the global phase op, the as_pl_op method should take care of any pi differences, yes?

Yes the as_pl_op method handles this, I guess my point was in general do we need to check that there aren't other sneaky factors of pi or (1/2) that crop up due to different conventions? Although now that I've looked at it some more, I am convinced we've covered our bases.

[austingmhuang]

We DONT check if the Qualtran definition of an operation is the same as the PL one. For example, I noticed in the global_phase the extra factor of pi that is used in Qualtran. Should we compare the matrix produced via tensor_contract against the qml.matrix function?

My opinion is that we should test that they're equivalent (where feasible).

For the tests, I purposefully avoided comparing tensor_contract with matrix because the behaviour of the two functions are not 100% equivalent. The shape of PL's matrix always has the shape of (2^len(wires), 2^len(wires)) whereas that's not true for tensor_contract. E.g. for GlobalPhase, the matrix() will be

array([[6.123234e-17-1.j, 0.000000e+00+0.j],
       [0.000000e+00+0.j, 6.123234e-17-1.j]])

whereas for qualtran's GlobalPhase().tensor_contract(), we can expect:

(6.123233995736766e-17+1j)

Regardless (cant hurt to have more tests), I've added a set of assertions to compare that the PL matrix matches the QT tensor_contract for most of the bloqs. For global phase, I used a manual test case instead of comparing directly to QT's tensor_contract.

[austingmhuang]

I think this PR looks pretty much ready. If you are okay with the PR @mpharrigan please merge 😺

[Jaybsoni]

Looks good from me 👍🏼