Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
draft: Fix how wire mapping is handled by the QuantumComputer device #147
base: master
Are you sure you want to change the base?
draft: Fix how wire mapping is handled by the QuantumComputer device #147
Changes from 2 commits
d766303
de6ea2d
dee6a43
328796b
21dd7bf
3e91dd4
dd2961d
15cc3e2
5dcb34f
3d396a9
46a0092
641c267
d89d1b6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check notice on line 32 in pennylane_rigetti/qc.py
codefactor.io / CodeFactor
pennylane_rigetti/qc.py#L32
Check notice on line 112 in pennylane_rigetti/qc.py
codefactor.io / CodeFactor
pennylane_rigetti/qc.py#L112
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose of this is to map the Pennylane wires on the operations to the internal wiring. Currently,
Wires(self.wiring)
just returns the Pennylane wires, since converting a dictionary to a wires object uses the keys of the dictionary, so this just maps custom wire labels to custom wire labels.I believe we want to preserve the previous behaviour mapping to consecutive integers. I think the
if-else
clause here may have been a relic - sinceself.wiring
on master is justdict(enumerate(self.qc.qubits()))
andself.num_wires
isself.num_wires = len(self.qc.qubits())
, I can't think of a circumstance whereWires(self.wiring) != Wires(range(self.num_wires))
. Correct me if I'm wrong, but seems like we don't want the backend wire labels here, but rather the enumeration of the wires, since its for the operations.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current implementation leads to this behaviour, which I believe is incorrect:
With the above suggested change I instead get:
Does that look like the expected program for this circuit? Or have I misunderstood the program format for gates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, definitely not what we wanted. However, after refactoring around this idea, I ran into another issue.
When updating as suggested, the correct program gets generated:
However, upon processing the samples, pennylane throws an out of bounds exception:
After digging into the implementation of
expval
, this appears to be because pennylane indexes into the sample array using the label of the device qubit. I would expect pennylane to index into the sample array not by using the label literally, but rather by enumerating the device wire labels and doing a reverse lookup to find it's relative position in the sample array. Is my assumption incorrect here? Is there some other way I should be providing the data? Could this be a bug in pennylane?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, okay, I misunderstood how you want the program to look. I assumed that the qubit specification for the RX operator would be the index, not the qubit number. In that case, the issue is that we are trying to use this function for two different and incompatible things.
The version I suggested in my initial comment will work for the part of PennyLane where you are encountering an issue, but will not work for generating the program for Rigetti. You've updated it to work for the Rigetti program, but not for PennyLane post processing 😅
There are two separate types of wire mapping we are interested in here. One is the conversion between the wires on the (software) device and consecutive indexing in PennyLane. The other is the conversion between the wires on the (software) device and the qubit numbers expected by the hardware backend. This function used (and is expected by the PennyLane device interface) to do the first thing, and you've updated it to do the second.
In other words, the dictionary generated by this function IS (or at least should be) the reverse lookup table for mapping wire label to relative position in the sample array. It should not include the qubit numbers at all, but only the (software) device wire labels and the consecutive integers. I.e. a 3 wire device with
wires=["a", "b", "c"]
, this function should return{"a": 0, "b": 1, "c":2}
.I don't think the plugin actually needs a custom implementation of this method, it can inherit from the PennyLane device base class. Where it does need a custom implementation is for mapping to hardware instructions, that will need to be done in a separate function, instead of overwriting this existing PennyLane function.
I'm going to make a branch of off this with a proposed solution. It seems like this same assumption was made in the parent class, i.e. that "custom wire labels" (this is what we call it whenever users don't have consecutive integers starting with 0 as their wire labels) in PennyLane don't currently translate to the Rigetti plugin.
Let's see if my suggestion fixes this, and also if it breaks other things, and then take it from there!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure you want the operators to be specified by qubit label and not by index? That's not currently the behaviour on
master
from what I can see.