Adding support for multi-qubit observable estimation #42

msohaibalam · 2020-02-07T07:00:52Z

Extends qpu.expval to handle multi-qubit observable estimation.

Handles the scenarios where (a) multi-qubit observable come in the Tensor format, and (b) pre-rotations are appropriately applied to all qubits so that we only need to measure the PauliZ operator.

Cleans up and consolidates the logic to remove code repetition between single and multi-qubit observable estimation.

A few things to note:

While the wiring is no longer needed in writing the preparation program, it is still needed when defining one's own readout errors on a qpu-as-a-qvm.
The same readout errors are defined on all the qubits via readout_error=[p00, p11] for simplicity. If we need the ability to define different readout errors on distinct qubits, we might choose to promote readout_error to be a list of lists in the multi-qubit case and handle that scenario separately.

…odifying docstring for tests

josh146

Looks great @msohaibalam! Excited for this. One thing that I've noticed is that the old operator estimation API doesn't support parametric compilation, whereas the new one developed by @karalekas does. @antalszava takes this into account in one of the previous PRs, by making operator estimation and parametric compilation mutually exclusive, but it would be great to port to the new API when stable/ready.

josh146 · 2020-02-07T16:49:14Z

pennylane_forest/qpu.py

+            # estimation
+            if isinstance(observable, Tensor):
+                observable = observable.obs[0]
+                wires = observable.wires


👍 I think I saw @antalszava mention this elsewhere, but we have just made an update to the logic in PennyLane core. If the user defines a tensor of a single observable Tensor(qml.PauliX(0)), the QNode will now smartly simply pass the observable to the device.

Oh yeah, this is just code from @antalszava's PR which I decided to build off instead of master. I'll merge in the new changes.

josh146 · 2020-02-07T16:57:49Z

pennylane_forest/qpu.py

+        # Multi-qubit observable
+        if len(wires) > 1:
+            # In this case, the observable must be a Tensor product
+            assert isinstance(observable, Tensor), "Multi-qubit observable is not in Tensor format"


Ah, this might not be the case! We allow qml.Hermitian(A, wires=w), where A.shape = [2**w, 2**w]. So the if statement should probably be

if len(wires) > 1 and isinstance(observable, Tensor):

Got it! It sounds like then that the check for observable.name == "Hermitian" should handle both the single-qubit and multi-qubit observable cases then. I'll make the change.

josh146 · 2020-02-07T17:01:22Z

pennylane_forest/qpu.py

+
+            # All observables are rotated to be measured in the Z-basis, so we just need to
+            # check which wires exist in the observable, map them to physical qubits, and measure
+            # the product of PauliZ operators on those qubits


josh146 · 2020-02-07T17:02:47Z

pennylane_forest/qpu.py

+                    symmetrize_readout=self.symmetrize_readout,
+                    calibrate_readout=self.calibrate_readout,
+                )
+            )


Something that @antalszava pointed out is that measure_observables will implicitly execute the circuit on the QPU. However, QVMDevice.generate_samples() has already done one execution, making it redundant. This could be solved by simply overwriting generate_samples() here to take into account operator estimation, or perhaps by our eventual goal of merging QVM and QPU 😆

Not sure I follow this point. Is the idea QVMDevice.generate_samples() being called before/while this particular call to measure_observables? (and if that's the case, it's not too clear to me where exactly this might be happening)

Yes, one missing piece here is that we have moved to a new API in PennyLane and this affects the plugins as well.

Following up on the previous #38, now ForestDevice inherits from QubitDevice. The PennyLane type of flow of logic involves evaluating a quantum circuit by calling on the execute method of the device (such is QPUDevice).

Each instance of the ForestDevice (now QPUDevice in our case) will currently inherit the same execute method as seen here (which is not redefined in any of the subclasses).

As per the logic in QubitDevice.execute, currently generate_samples is called, as the QPUDevice does not support analytic evaluation (it being a hardware). After this, statistics are extracted and therefore eventually we call on QPUDevice.expval which usually corresponds to QubitDevice.expval.

Now in our case, QPUDevice inherited the QVMDevice.generate_samples method, which makes the call on the QuantumComputer.run method. It will in the expval method, however, call on measure_observables as well.

Thanks for the detailed explanation @antalszava! It seems to me this won't be the last time generate_samples and measure_observables will conflict ;) , mostly because they're both trying to generate samples!

My gut feeling is also that even if we do merge the QVM and QPU classes, we'll still be faced with the choice of either over-riding generate_samples to use measure_observables, or port over all the logic of error mitigation over to generate_samples (and/or its helper functions). I'm not sure how I can over-ride it here though, would appreciate input on that!

I'm not sure how I can over-ride it here though, would appreciate input on that!

I think it's a good question, and not entirely trivial --- I say we merge this as is, and make a new issue to determine how to avoid this conflict!

That sounds good to me. I've created a new issue here: #45.

josh146 · 2020-02-07T17:03:20Z

tests/test_qpu.py

+        res = circuit_tensor(p)
+        exp = circuit_obs(p)
+
+        assert np.allclose(res, exp, atol=2e-2)


Borrowed code from @antalszava's PR :)

josh146 · 2020-02-07T17:03:56Z

tests/test_qvm.py

        assert dev.circuit_hash in dev._compiled_program_dict
        assert len(dev._compiled_program_dict.items()) == 1

-    @flaky(max_runs=10, min_passes=1)
+    @flaky(max_runs=5, min_passes=3)


While not best practice for unittests, we've found flaky really nice for stochastic quantum integration tests 😆

Seems like a nice tool!

Co-Authored-By: Josh Izaac <[email protected]>

… of wires

msohaibalam · 2020-02-08T02:20:52Z

Thanks for the feedback, @josh146 and @antalszava! I'm done making changes and updates, so please give this another look when you can.

Re: operator_estimation not handling parametric compilation, yes that is unfortunately a feature currently lacking, and one of the aims of the new API (once it's ready) is to include precisely this functionality.

josh146

This looks great @msohaibalam, thanks for the help getting it over the line! I've left a few comments, but nothing major.

josh146 · 2020-02-09T20:40:00Z

pennylane_forest/qpu.py

+            # API has been executed. This new API provides compatibility between parametric
+            # compilation and operator estimation.
+            warnings.warn("Parametric compilation is currently not supported with operator"
+                          "estimation. Operator estimation is being turned off.")


How come this is showing up as a change, has the location been moved?

I changed this to have the same format as on the master branch.

josh146 · 2020-02-09T20:40:14Z

pennylane_forest/qpu.py

-from pyquil.quil import Pragma, Program
+from pyquil.operator_estimation import (Experiment, ExperimentSetting,
+                                        TensorProductState, group_experiments,
+                                        measure_observables)


Nice to have the updated import locations!

josh146 · 2020-02-09T20:44:08Z

pennylane_forest/qpu.py

+        if observable.name == "Hermitian":
+            # <H> = \sum_i w_i p_i
+            Hkey = tuple(par[0].flatten().tolist())
+            w = self._eigs[Hkey]["eigval"]
+            return w[0] * p0 + w[1] * p1


This might not be needed, as the call to super().expval(observable) already takes into account this case 🙂

Great! Removing this code block.

josh146 · 2020-02-09T20:44:27Z

pennylane_forest/qpu.py

+            return w[0] * p0 + w[1] * p1
+
+        # `measure_observables` called only when parametric compilation is turned off
+        elif not self.parametric_compilation:


In which case, this can simply become if not self.parametric_compilation:

josh146 · 2020-02-09T20:44:59Z

pennylane_forest/qpu.py

+                pauli_obs = sI()
+                for wire in observable.wires:
+                    qubit = wire[0]
+                    pauli_obs *= sZ(self.wiring[qubit])


josh146 · 2020-02-09T20:46:16Z

pennylane_forest/qpu.py

+                    symmetrize_readout=self.symmetrize_readout,
+                    calibrate_readout=self.calibrate_readout,
+                )
+            )


I'm not sure how I can over-ride it here though, would appreciate input on that!

I think it's a good question, and not entirely trivial --- I say we merge this as is, and make a new issue to determine how to avoid this conflict!

…out parametric compilation

antalszava and others added 13 commits February 3, 2020 23:30

Adding logic for single observable Tensor, adding integration test; m…

8c98712

…odifying docstring for tests

Comment

09bd061

Remove print statements

0a7ff28

Correct test to have PauliY in there

3f4700e

Modify test parameter

cffc01d

Modifying flaky parameters, modifying tolerance value, docstrings

ef8f323

Adding flaky runs to hermitian test case

5c5c5c3

Toggle flaky numbers

b47da97

Modify test such that no SWAP erros may be outputted

580c1fc

Remove print stmt

aa3a83a

Revert tensor obs case QPUDevice.expval

44daf8b

Add warning to the user, add test for it

54afa6e

First pass at multi-qubit observables

ef725c5

msohaibalam added the work in progress label Feb 7, 2020

msohaibalam requested a review from josh146 February 7, 2020 07:01

antalszava added 6 commits February 7, 2020 07:10

Test on wires expval with operator estimation

c5b2ab9

Merge conflicts

ccfac04

Comments

f600b0d

Test remvoe space

0b37674

Linting

2543343

Test docstring

56d015d

josh146 requested changes Feb 7, 2020

View reviewed changes

antalszava and others added 8 commits February 7, 2020 13:51

Changing tests

3a1075e

Changing PyQvm test settings

66b46c0

Update pennylane_forest/qpu.py

9833f9a

Co-Authored-By: Josh Izaac <[email protected]>

Update pennylane_forest/qpu.py

6ac28e2

Co-Authored-By: Josh Izaac <[email protected]>

Merging in updates to PR 41

a6800d0

Moving assert condition for multi-qub osbervables into loop condition

d7a2cf4

Minor clean-up

8199b96

Moving check for Hermitian observables at same level of check for no.…

c85eddb

… of wires

msohaibalam added 6 commits February 7, 2020 17:08

Multi qubit observables with and without readout errors

6c17106

Testing for multi-qubit readout mitigtation

961bd43

Removing unnecessary dict

6fbdf1b

Cleaning up single-qubit case

f530281

Same preparation program for single and multi qubit observables

61e382e

Consolidating and cleaning up logic for expval

e981bdc

msohaibalam added review-ready and removed work in progress labels Feb 8, 2020

josh146 approved these changes Feb 9, 2020

View reviewed changes

msohaibalam mentioned this pull request Feb 11, 2020

Remove sample collection redundancy in QPUDevice.expval #45

Open

msohaibalam added 7 commits February 11, 2020 13:42

Removing white space

b493ded

Keeping same format as master

ebdfb14

No need to separately perform logic for Hermitian observable

e625855

Comments for clarity

ecd1f15

Adding flaky decorator to tests

68be8ea

Spreading shots budget across 20 diff expts; adding similar test with…

7a13507

…out parametric compilation

Resolving merge conflicts with master

45826f5

msohaibalam merged commit 3dab35e into master Feb 18, 2020

msohaibalam deleted the multi_qub_observable branch February 18, 2020 03:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adding support for multi-qubit observable estimation #42

Adding support for multi-qubit observable estimation #42

msohaibalam commented Feb 7, 2020 •

edited

Loading

josh146 left a comment

josh146 Feb 7, 2020

msohaibalam Feb 7, 2020

josh146 Feb 7, 2020

msohaibalam Feb 7, 2020

josh146 Feb 7, 2020

josh146 Feb 7, 2020

msohaibalam Feb 7, 2020

antalszava Feb 7, 2020

msohaibalam Feb 8, 2020

josh146 Feb 9, 2020

msohaibalam Feb 11, 2020

josh146 Feb 7, 2020

msohaibalam Feb 7, 2020

josh146 Feb 7, 2020

msohaibalam Feb 7, 2020

msohaibalam commented Feb 8, 2020

josh146 left a comment

josh146 Feb 9, 2020

msohaibalam Feb 11, 2020

josh146 Feb 9, 2020

josh146 Feb 9, 2020

msohaibalam Feb 11, 2020

josh146 Feb 9, 2020

msohaibalam Feb 11, 2020

josh146 Feb 9, 2020

josh146 Feb 9, 2020

Adding support for multi-qubit observable estimation #42

Adding support for multi-qubit observable estimation #42

Conversation

msohaibalam commented Feb 7, 2020 • edited Loading

josh146 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msohaibalam commented Feb 8, 2020

josh146 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msohaibalam commented Feb 7, 2020 •

edited

Loading