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?

[mpharrigan]

Actually, is this circular dependancy going to be a problem while trying to merge these two PRs across two packages? To merge this current, Qualtran PR; we need to depend on a release of Pennylane that includes this adapter. But that adapter needs a release of qualtran with Bloq.as_pl_op. Am I capturing this correctly?

[austingmhuang]

Yeah good question. For the CI on PennyLane's side, the PR depends on this specific fork/branch (see: .github/workflows/interface-unit-tests.yml. For Qualtran, we can do something similar where the CI specifically depends on the branch qualtran_pl in PennyLane rather than master.

Depending on which branch is merged first, we would just edit the CI to depend on main/master.

[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.