-
Notifications
You must be signed in to change notification settings - Fork 990
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
[Pasqal updates] New qubit classes #3133
Conversation
Good news, @balopat! I managed to make a smaller first PR than previously anticipated by only adding the new qubit classes. |
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.
This is looking really good @HGSilveri, it's the perfect size / scope.
Thank you for splitting it out!!!
I understand you based your design and comments based on GridQubit
- which is a good starting point. I only have some nits and one or two questions - but I think we are basically good to go.
cirq/pasqal/pasqal_qubits.py
Outdated
self.z = z | ||
|
||
def _comparison_key(self): | ||
return round(self.z, 9), round(self.y, 9), round(self.x, 9) |
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.
Why rounding the coordinates? And why to 9 digits?
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.
I don't recall exactly what prompted this, but I'm assuming it was some machine precision error. We end up using a lot of irrational numbers from triangular lattice coordinates, so I'm assuming there was some false negative.
As for the rounding, I think it is arbitrary, it could have more digits. I'm happy to change it to a higher value.
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.
Great - if you could recover that use case that would be useful - we should add it to the tests to protect this functionality. Otherwise someone might just remove this without failing tests.
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.
Turns out rounding to 9 was excessive, I increased the number of digits to 15 and introduced a test to back that up.
That's good to hear @balopat ! Thanks a lot for the quick review, I've addressed all your questions and nits. |
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.
Thank you! A couple more findings!
cirq/pasqal/pasqal_qubits.py
Outdated
self.z = z | ||
|
||
def _comparison_key(self): | ||
return round(self.z, 9), round(self.y, 9), round(self.x, 9) |
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.
Great - if you could recover that use case that would be useful - we should add it to the tests to protect this functionality. Otherwise someone might just remove this without failing tests.
cirq/pasqal/pasqal_qubits.py
Outdated
return cirq.protocols.obj_to_dict_helper(self, ['x', 'y', 'z']) | ||
|
||
def __add__(self, other: Tuple[float, float, float]) -> 'ThreeDQubit': | ||
if not (isinstance(other, tuple) and len(other) == 3 and |
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.
one last question: GridQubit
does have the functionality to add/substract GridQubit
s together in here:
Cirq/cirq/devices/grid_qubit.py
Lines 76 to 82 in adc8964
if isinstance(other, _BaseGridQid): | |
if self.dimension != other.dimension: | |
raise TypeError( | |
"Can only add GridQids with identical dimension. " | |
f"Got {self.dimension} and {other.dimension}") | |
return self._with_row_col(row=self.row + other.row, | |
col=self.col + other.col) |
Do you mind adding that with tests to be consistent?
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.
Actually, I've been discussing with the rest of the team and we reached the conclusion that these dunder methods for addition and subtraction of qubits or tuples to qubits don't really make sense for our case.
They were first added because the ThreeDGridQubit
class tried to mimic GridQubit
and were just left there for no particular reason. As the ThreeDGridQubit
class turned into ThreeDQubit
, it made increasingly less sense to have them, so I am now advocating for their removal. However, before I do so, I would like to know, do you have any objection or counter-argument to this?
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.
No counter argument / objection on my end - I prefer not having it at all then having it half-way implemented!
Hi @balopat! As I commented above, we are dropping the addition and subtraction magic methods. I went ahead and pushed a new commit without them, but I can always revert it in case you have an objection. If you do, please let me know and I'll address it asap. The other nits and requests have been addressed, so in case nothing else comes up, this one is hopefully good to go and we can move on to the next PR. |
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.
LGTM, thank you for all your work!
This the second child-PR of #3126 , following #3133 . - Generalizes `PasqalDevice`, removing ties to the physical placement of the qubits. - `PasqalDevice` now serves as the parent class of all future Pasqal devices, only enforcing constraints expected to exist on all future devices. - `PasqalDevice`can also be used as the device for submission of explicitly unconstrained circuits to Pasqal's devices. A new device class, `PasqalVirtualDevice`, will subclass the new `PasqalDevice` and recover the hardware constraints of the current `PasqalDevice` on a future PR.
This the first child-PR of quantumlib#3126 . - Introduces new Pasqal qubit classes: `ThreeDQubit`and `TwoDQubit` (a subclass of `ThreeDQubit`) - These new classes are intended to replace the original `ThreeDGridQubit`, which will be deleted on the next PR (where other classes' dependencies will be resolved). - In comparison with `ThreeDGridQubit`, these new classes allow for arbitrary placement of qubits in 3D or 2D space, instead of restricting them to a grid. This more closely resembles the capabilities of Pasqal devices.
This the second child-PR of quantumlib#3126 , following quantumlib#3133 . - Generalizes `PasqalDevice`, removing ties to the physical placement of the qubits. - `PasqalDevice` now serves as the parent class of all future Pasqal devices, only enforcing constraints expected to exist on all future devices. - `PasqalDevice`can also be used as the device for submission of explicitly unconstrained circuits to Pasqal's devices. A new device class, `PasqalVirtualDevice`, will subclass the new `PasqalDevice` and recover the hardware constraints of the current `PasqalDevice` on a future PR.
This the first child-PR of #3126 .
ThreeDQubit
andTwoDQubit
(a subclass ofThreeDQubit
)ThreeDGridQubit
, which will be deleted on the next PR (where other classes' dependencies will be resolved).ThreeDGridQubit
, these new classes allow for arbitrary placement of qubits in 3D or 2D space, instead of restricting them to a grid. This more closely resembles the capabilities of Pasqal devices.