Observables #213

Gistbatch · 2024-04-22T15:19:01Z

closes: #141

I started to develop this, and I have some open questions:

I've implemented a test for the RawRectangleTemplate. @nelimee, can you clarify if this is the intended behavior?
What should the scope of this Issue/PR be? Only build this for the available templates, including moves and so on.
How do we define midlines for uneven-sized templates, e.g., where the number of qubit rows is even?

Todos:

Add all templates
Write tests, including scaling
Figure out edge cases: Moving, uneven ...
Documentation

afowler · 2024-04-22T15:55:03Z

In my opinion there would be very little benefit and significant additional complexity allowing even code distances, so I would support not allowing this at all and consequently always having well defined mid lines. Best, Austin.

…

On Mon, Apr 22, 2024, 8:19 AM Philipp Seitz ***@***.***> wrote: closes: #141 <#141> I started to develop this, and I have some open questions: - I've implemented a test for the RawRectangleTemplate. @nelimee <https://github.com/nelimee>, can you clarify if this is the intended behavior? - What should the scope of this Issue/PR be? Only build this for the available templates, including moves and so on. - How do we define midlines for uneven-sized templates, e.g., where the number of qubit rows is even? Todos: - Add all templates - Write tests, including scaling - Figure out edge cases: Moving, uneven ... - Documentation ------------------------------ You can view, comment on, or merge this pull request online at: #213 Commit Summary - 4f5cd82 <4f5cd82> Add pytest as explicit dependency - a0ad6d9 <a0ad6d9> Add new abstract method to base template - 17db053 <17db053> Add initial rectangle implementation File Changes (4 files <https://github.com/QCHackers/tqec/pull/213/files>) - *M* requirements-dev.txt <https://github.com/QCHackers/tqec/pull/213/files#diff-2b4945591edfeaa4cf4d3f155e66d4b43d1bda7a55d881d5cf3107f1b05abbbc> (3) - *M* src/tqec/templates/atomic/rectangle.py <https://github.com/QCHackers/tqec/pull/213/files#diff-8b5421da61ed89127cacca5e2b190c31922a1c751c8197b0037126c1bde61b26> (43) - *M* src/tqec/templates/atomic/rectangle_test.py <https://github.com/QCHackers/tqec/pull/213/files#diff-9596ec56c970721b10b588d25b854f559278da999c8e57993fb6d4ee752374a9> (26) - *M* src/tqec/templates/base.py <https://github.com/QCHackers/tqec/pull/213/files#diff-3f1946f8f161e910c0c51cfbcae118a9e500fc25c8a93b908ac5ee5715d7f5eb> (17) Patch Links: - https://github.com/QCHackers/tqec/pull/213.patch - https://github.com/QCHackers/tqec/pull/213.diff — Reply to this email directly, view it on GitHub <#213>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKAXTAR2AFW3WUIWSIA7CLY6US7VAVCNFSM6AAAAABGS75KBKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2TMOBSGQYDSMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

nelimee · 2024-04-22T16:19:06Z

I've implemented a test for the RawRectangleTemplate. @nelimee, can you clarify if this is the intended behavior?

The output you fixed is dependent on the actual Plaquette implementation. What if the origin (i.e., (0, 0) point) was on the top-left of the Plaquette? Then both the output coordinates would change.
I cannot remember if we completely ruled out that case though.

In any case, I think this method needs the Plaquette instances to be able to function correctly and generically.

What should the scope of this Issue/PR be? Only build this for the available templates, including moves and so on.

For this PR, only build this for the available Templates. Moving will come after.

How do we define midlines for uneven-sized templates, e.g., where the number of qubit rows is even?

As Austin said, I would rule out that case. To do that, I would change the default_observable_qubits return type to ty.Sequence[tuple[cirq.GridQubit, int]] | None, returning None being a signal that the midline could not be computed.

Also, I think the implementations of default_observable_qubits might be factorisable. But let's have something working for the moment.

The rationale is to get the plaquette indices from the template and then compute the positions according to the plaquettes.

This construction is similar to the circuit generation

Gistbatch · 2024-04-23T12:10:56Z

@nelimee, I've updated this; let me know what you think.

If the midline is supposed to depend on the plaquettes, we need this information, so I built observable_qubits_from_template similar to the generate_circuit function. The template now only returns the row and column indices of the templates that have the observable qubits, by convention, above/left of the midline.

nelimee · 2024-04-26T15:34:04Z

If the midline is supposed to depend on the plaquettes

I do not get how you can generate correct results without any idea of the plaquette used. For the moment, all the plaquettes we use have the support

1   2
  5 
3   4

with:

cirq.GridQubit(-1, -1)
cirq.GridQubit( 1, -1)
cirq.GridQubit(-1, 1)
cirq.GridQubit( 1, 1)
cirq.GridQubit( 0, 0)

but (as far as I remember) we never explicitly said that was the only possible default. This means that a plaquette with the same support but with

cirq.GridQubit(0, 0)
cirq.GridQubit(2, 0)
cirq.GridQubit(0, 2)
cirq.GridQubit(2, 2)
cirq.GridQubit(1, 1)

is possible.
If that is the case, then we need to have access to that information, else the midline qubits will be completely wrong. I am missing something here?

I am making a few comments on the code before commenting again on the overall approach.

nelimee

I did not check thoroughly the code validity for the moment, but your tests help on that.
For the Template.get_midline_plaquettes method, I completely agree with the fact that we need a convention such as the one you used (plaquettes left of the vertical midline or above the horizontal midline). The two branches (depending on the value of the horizontal boolean) are very similar, maybe they can be "merged" in one more generic version.

nelimee · 2024-04-26T15:36:09Z

src/tqec/circuit/operations/operation.py

+
+def observable_qubits_from_template(
+    template: Template,
+    plaquettes: list[Plaquette] | dict[int, Plaquette],


This will be less of an issue with #203 merged, but maybe

Suggested change

plaquettes: list[Plaquette] | dict[int, Plaquette],

plaquettes: Sequence[Plaquette] | Mapping[int, Plaquette],

to have the covariance of the typing annotations?

nelimee · 2024-04-26T15:38:47Z

src/tqec/circuit/operations/operation.py

+def observable_qubits_from_template(
+    template: Template,
+    plaquettes: list[Plaquette] | dict[int, Plaquette],
+    horizontal: bool = True,


Even though I am not always doing it, in general, I prefer to use enumerations with explicit names for boolean parameters. I find that easier to read when calling the function/method. Doing so would require to introduce something along the lines of

class Orientation(Enum): HORIZONTAL = auto() VERTICAL = auto()

and then the function can be used as

observable_qubits_from_template(template, plaquettes, Orientation.HORIZONTAL)

this is really minor though.

nelimee · 2024-04-26T15:39:21Z

src/tqec/circuit/operations/operation.py

+        template (Template): The template to get the default observable qubits from.
+        plaquettes (list[Plaquette] | dict[int, Plaquette]): The plaquettes to use to get the
+        acurate positions of the observable qubits.
+        horizontal (bool, optional): Whether to get the observable qubits from
+            the horizontal or vertical midline. Defaults to True -> Horizontal.


I am not sure the type annotations in the docstring are needed. To check in #211.
If not needed because Sphinx is able to read directly from the annotations in code, then we should remove them in the docstring as we will likely eventually forget to change the docstring and that will lead to outdated comments.

nelimee · 2024-04-26T15:48:16Z

src/tqec/circuit/operations/operation.py

+    try:
+        midline_indices = template.get_midline_plaquettes(horizontal)
+    except TQECException:
+        return None


I cannot remember what is the norm in Python, but I try to avoid exceptions for control-flow handling. Seeing it implemented, I think I do not agree with myself anymore. I wrote that

As Austin said, I would rule out that case. To do that, I would change the default_observable_qubits return type to ty.Sequence[tuple[cirq.GridQubit, int]] | None, returning None being a signal that the midline could not be computed.

but I now think that the TQECException should not be caught here but should rather go up in the stack. We can then simply document that the function/method raise TQECException when the Template dimensions are not compatible. Sorry for misleading you in the first place, this is my mistake.

nelimee · 2024-04-26T15:48:45Z

src/tqec/circuit/operations/operation.py

+    for index in midline_indices:
+        row_index, column_index = index


Might as well be written in one line:

Suggested change

for index in midline_indices:

row_index, column_index = index

for (row_index, column_index) in midline_indices:

nelimee · 2024-04-26T15:52:34Z

src/tqec/circuit/operations/operation.py

+        max_index = max(
+            plaquette.qubits.data_qubits, key=lambda q: q.position.y
+        ).position.y


Suggested change

max_index = max(

plaquette.qubits.data_qubits, key=lambda q: q.position.y

).position.y

max_index = max(q.position.y for q in plaquette.qubits.data_qubits)

should be equivalent here. I did not tested the above code though.

nelimee · 2024-04-26T15:55:59Z

src/tqec/circuit/operations/operation.py

+        TQECException: If the plaquettes are provided as a dictionary and 0 is in the keys.
+
+    Returns:
+        Sequence[tuple[cirq.GridQubit, int]] | None: The observable qubits and their offsets.


I am not sure the type annotations in the docstring are needed. To check in #211.

nelimee · 2024-04-26T15:56:12Z

src/tqec/templates/base.py

+        and to the left of the midline for the vertical case.
+
+        Args:
+            horizontal (bool, optional): Horizontal or vertical qubits. Defaults to True.


I am not sure the type annotations in the docstring are needed. To check in #211.

nelimee · 2024-04-26T15:56:17Z

src/tqec/templates/base.py

+            horizontal (bool, optional): Horizontal or vertical qubits. Defaults to True.
+
+        Returns:
+            list[tuple[int,int]]: The sequence of qubits and offsets.


I am not sure the type annotations in the docstring are needed. To check in #211.

nelimee · 2024-04-26T15:59:21Z

src/tqec/templates/atomic/rectangle.py

+            indices = self._indices[midline]
+            return [(midline, column ) for column, _ in enumerate(indices)]


Suggested change

indices = self._indices[midline]

return [(midline, column ) for column, _ in enumerate(indices)]

return [(midline, column) for column in range(len(self._indices[midline]))]

Or even

Suggested change

indices = self._indices[midline]

return [(midline, column ) for column, _ in enumerate(indices)]

return [(midline, column) for column in range(self.shape.x)]

afowler · 2024-04-26T16:04:43Z

Some reasonable restrictions. We already restrict ourselves to plaquettes with a rectangular footprint. The midline calculation is associated with a square 2kx2k template of such plaquettes. It would be reasonable to restrict ourselves to plaquettes with exactly four qubits in the four corners of the plaquette, then the midline calculation should depend on the shape of the plaquette, rather than the precise labeling of the qubits in the plaquette. Best, Austin.

…

On Fri, Apr 26, 2024, 8:34 AM Adrien Suau ***@***.***> wrote: If the midline is supposed to depend on the plaquettes I do not get how you can generate correct results without any idea of the plaquette used. For the moment, all the plaquettes we use have the support 1 2 5 3 4 with: 1. cirq.GridQubit(-1, -1) 2. cirq.GridQubit( 1, -1) 3. cirq.GridQubit(-1, 1) 4. cirq.GridQubit( 1, 1) 5. cirq.GridQubit( 0, 0) but (as far as I remember) we never explicitly said that was the only possible default. This means that a plaquette with the same support but with 1. cirq.GridQubit(0, 0) 2. cirq.GridQubit(2, 0) 3. cirq.GridQubit(0, 2) 4. cirq.GridQubit(2, 2) 5. cirq.GridQubit(1, 1) is possible. If that is the case, then we need to have access to that information, else the midline qubits will be completely wrong. I am missing something here? I am making a few comments on the code before commenting again on the overall approach. — Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKAXTCWTHPW2B4VAOCLI2TY7JXYDAVCNFSM6AAAAABGS75KBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZZGYZDMNZYG4> . You are receiving this because you commented.Message ID: ***@***.***>

Gistbatch · 2024-04-27T08:29:54Z

Using their coordinates, I take the qubits furthest to the right (bottom). This works only for rectangular shapes but has the advantage that this works independently of the orientation.
As an alternative, we could implement this as the default behavior in the plaquette, which can be overwritten.
I'll clean up the code once we've decided on the mechanism and implement the rest of the templates.

nelimee · 2024-04-29T06:34:50Z

then the midline calculation should depend on the shape of the plaquette, rather than the precise labeling of the qubits in the plaquette.

I agree, the issue here is that, in the current state of the code, the positions of the plaquette qubits can change all the positions. Basically, the positioning algorithm starts by positioning the origin of the top-left-most plaquette on the qubit (0, 0), all the other qubits position being ultimately determined relative to that position. That mean that in the 2 cases I presented above, all the qubits of the template are shifted by (1, 1). And we need exact coordinates for the midline.

This limitation should be quite easy to remove though, using the top-left corner of the plaquette instead of the origin in the first step would solve it on the current use-case.
Finally, this is very much an implementation detail for the moment, but it has implications on what the user see and experience, so we might want to change the current default anyway.

Using their coordinates, I take the qubits furthest to the right (bottom). This works only for rectangular shapes but has the advantage that this works independently of the orientation.
As an alternative, we could implement this as the default behavior in the plaquette, which can be overwritten.

Both approaches seems fine for me. The second one is likely more generic, but we are only interested in rectangular plaquette for the moment so this is not really a problem to implement a simpler, less generic, version.

Gistbatch · 2024-05-07T08:55:46Z

@nelimee, I'm confused about why the test keeps failing. Do you have any idea why this is the case? I can run it locally without this problem, and I'm not sure how to fix this as it seems it works completely fine with circuit_test which has a similar import structure.

nelimee · 2024-05-07T09:20:11Z

@nelimee, I'm confused about why the test keeps failing. Do you have any idea why this is the case? I can run it locally without this problem, and I'm not sure how to fix this as it seems it works completely fine with circuit_test which has a similar import structure.

This might be due to #198 being merged in main. I am not sure what https://github.com/actions/checkout is checking out, but it might be worth updating this branch with the latest changes from main and see if that resolves the issue.

nelimee

One suggestion to fix at least one test.

The other errors are expected as not all Template subclasses implement the get_midline_plaquettes method, which makes them abstract and non-instantiable

nelimee · 2024-05-07T11:08:51Z

src/tqec/circuit/observable_qubits.py

@@ -0,0 +1,96 @@
+from typing import Any, Mapping, Sequence


Suggested change

from typing import Any, Mapping, Sequence

from __future__ import annotations

from typing import Any, Mapping, Sequence

fixes some test issues.

Gistbatch · 2024-05-07T12:00:49Z

I've now implemented the midline definition for the existing template instances.
For the ComposedTemplate and its children, I'm wondering what the default behavior should be.
It seems impossible to know which qubits are on the midline without prior knowledge.
For example, the QubitSquareTemplate has a midline, but none of the associated template midlines coincide.
We could hard code this, but figuring out which templates to look at for qubits seems arbitrary and complex.
@afowler, @nelimee any suggestions?

nelimee · 2024-05-07T12:41:04Z

It seems at least hard, maybe impossible (there are likely instantiations of the CompositeTemplate that do not represent a valid code, and so do not have observables), to me too.
I will review the code as it is right now, let's wait for @afowler answer.

nelimee

In the future it might be better to define a method in Plaquette to get the "extremum" qubits in a provided direction. This would be even more general than the _get_edge_qubits and should be quite simple to implement using geometry. Also it would pave the way for non-square plaquettes (for which the edge qubits might not only be horizontal or vertical, say for example for an octagonal plaquette).

You also should document somewhere the convention you used w.r.t which plaquette is returned by the get_midline_plaquettes method (if horizontal, the plaquette on the left or on the right? same question for vertical) and so on which edge the qubits are taken from.

You should document somewhere that the qubits returned by the get_midline_plaquettes method are in the (row, column) format. Even better, maybe create or re-use a structure with named fields for that?

nelimee · 2024-05-07T12:44:57Z

src/tqec/circuit/observable_qubits.py

+
+def observable_qubits_from_template(
+    template: Template,
+    plaquettes: Union[Sequence[Plaquette], Mapping[int, Plaquette]],


Can be

Suggested change

plaquettes: Union[Sequence[Plaquette], Mapping[int, Plaquette]],

plaquettes: Sequence[Plaquette] | Mapping[int, Plaquette],

if we also include

from __future__ import annotations

This version (with |) is used across the code base, it might be better to stay consistent.

nelimee · 2024-05-07T12:45:37Z

src/tqec/circuit/observable_qubits.py

+        template (Template): The template to get the default observable qubits from.
+        plaquettes (list[Plaquette] | dict[int, Plaquette]): The plaquettes to use to get the
+        acurate positions of the observable qubits.
+        horizontal (bool, optional): Whether to get the observable qubits from
+            the horizontal or vertical midline. Defaults to True -> Horizontal.


As for the previous comments, I am pretty sure types do not have to appear in the docstrings.

I haven't updated docs and tests yet, I'll do this once functionality is fixed

nelimee · 2024-05-07T12:47:03Z

src/tqec/circuit/observable_qubits.py

+            (qubit.to_grid_qubit() + offset, 0)
+            for qubit in _get_edge_qubits(plaquette, horizontal)
+        ]
+    return list(set(observable_qubits))


Maybe sorting the qubits before returning them would help human readability in the final generated Stim file?

Suggested change

return list(set(observable_qubits))

return sorted(set(observable_qubits))

nelimee · 2024-05-07T12:48:06Z

src/tqec/circuit/observable_qubits.py

+            else qubit.position.x
+        )
+
+    max_index = max_index = max(


Suggested change

max_index = max_index = max(

max_index = max(

nelimee · 2024-05-07T12:54:33Z

src/tqec/circuit/observable_qubits_test.py

+    result = [
+        (cirq.GridQubit(3, -1), 0),
+        (cirq.GridQubit(3, 1), 0),
+        (cirq.GridQubit(3, 3), 0),
+        (cirq.GridQubit(3, 5), 0),
+        (cirq.GridQubit(3, 7), 0),
+    ]
+    assert sorted(obs, key=lambda t: t[0].col == result)


I am not sure to understand that part. If I understand it correctly, you are sorting obs with a comparator that I do not understand.
Maybe

Suggested change

result = [

(cirq.GridQubit(3, -1), 0),

(cirq.GridQubit(3, 1), 0),

(cirq.GridQubit(3, 3), 0),

(cirq.GridQubit(3, 5), 0),

(cirq.GridQubit(3, 7), 0),

]

assert sorted(obs, key=lambda t: t[0].col == result)

result = [

(cirq.GridQubit(3, -1), 0),

(cirq.GridQubit(3, 1), 0),

(cirq.GridQubit(3, 3), 0),

(cirq.GridQubit(3, 5), 0),

(cirq.GridQubit(3, 7), 0),

]

assert sorted(obs, key=lambda t: t[0].col) == result

is what you wanted?

nelimee · 2024-05-07T13:00:50Z

src/tqec/templates/atomic/square.py

+
+    def get_midline_plaquettes(
+        self, horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL
+    ) -> list[tuple[int, int]]:
+        midline_shape, iteration_shape = self.shape.x, self.shape.y
+        if midline_shape % 2 == 1:
+            raise TQECException(
+                "Midline is not defined for odd "
+                + f"{'height' if horizontal == TemplateOrientation.HORIZONTAL else 'width'}."
+            )
+        midline = midline_shape // 2 - 1
+        if horizontal == TemplateOrientation.VERTICAL:
+            return [(midline, column) for column in range(iteration_shape)]
+        return [(row, midline) for row in range(iteration_shape)]


Isn't this one already implemented by the AlternatingRectangleTemplate.get_midline_plaquettes? Why aren't you swapping midline_shape and iteration_shape depending on the orientation here?

since this is a square midline_shape == iteration_shape, and this class inherits from Template so we can't inherit the function.

Right, I missed that, thanks for the answer :)

nelimee · 2024-05-07T13:04:14Z

src/tqec/templates/stack.py

+            if (
+                horizontal == TemplateOrientation.VERTICAL
+                and template.shape.x == midline_shape
+            ):
+                template.get_midline_plaquettes(horizontal)


Suggested change

if (

horizontal == TemplateOrientation.VERTICAL

and template.shape.x == midline_shape

):

template.get_midline_plaquettes(horizontal)

elif (

horizontal == TemplateOrientation.VERTICAL

and template.shape.x == midline_shape

):

return template.get_midline_plaquettes(horizontal)

Gistbatch · 2024-05-23T15:04:38Z

I wrote tests for all the templates now.
I don't know what the intended behavior for the stacked template is.
Also, I left the CornerTemplate and StackedTemplate unimplemented.
I could hardcode the corner template similar to the qubit template if needed.
There isn't a good way of knowing what the midline is supposed to be for the stacked template, so I just left it.
The only option is to give all possible midlines to the user, and they have to piece them together themselves.

Gistbatch · 2024-05-24T10:57:28Z

@nelimee I'll merge this once you approve

nelimee

Some very minor comments, mostly about renaming horizontal to orientation.
There is also some duplication of code, but this can be addressed later.

A few other comments for the future of that feature:

I can see the _get_edge_qubits function being implemented in the PlaquetteQubits class. With a little bit of geometry, we could even implement something like PlaquetteQubits.extremum_qubits_in_direction(self, x: float, y: float). This can be thought about in a follow-up issue.
The more I think about the short-term and end goal of the community, the more I think I made a mistake by introducing StackedTemplate and ShiftedTemplate. These are 1. not really useful and 2. making a few PR more difficult than what they should be (this PR being a good example, another exploration work I have locally being another).

In the end, except the minor comments, I think this is a good first step to include automatic observable computation.

nelimee · 2024-05-27T11:20:45Z

src/tqec/circuit/observable_qubits.py

+def observable_qubits_from_template(
+    template: Template,
+    plaquettes: Sequence[Plaquette] | Mapping[int, Plaquette],
+    horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL,


Suggested change

horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL,

orientation: TemplateOrientation = TemplateOrientation.HORIZONTAL,

WARNING: should also be changed in the function body if changed here.

nelimee · 2024-05-27T11:21:04Z

src/tqec/circuit/observable_qubits.py

+        horizontal: Whether to get the observable qubits from
+            the horizontal or vertical midline. Defaults to True -> Horizontal.


Suggested change

horizontal: Whether to get the observable qubits from

the horizontal or vertical midline. Defaults to True -> Horizontal.

orientation: Whether to get the observable qubits from

the horizontal or vertical midline. Defaults to horizontal.

nelimee · 2024-05-27T11:23:08Z

src/tqec/circuit/observable_qubits.py

+
+def _get_edge_qubits(
+    plaquette: Plaquette,
+    horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL,


Suggested change

horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL,

orientation: TemplateOrientation = TemplateOrientation.HORIZONTAL,

WARNING: should also be changed in the function body if changed here.

nelimee · 2024-05-27T11:25:43Z

src/tqec/templates/atomic/rectangle.py

@@ -90,6 +91,23 @@ def to_dict(self) -> dict[str, ty.Any]:
    def expected_plaquettes_number(self) -> int:
        return 2

+    def get_midline_plaquettes(
+        self, horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL


Suggested change

self, horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL

self, orientation: TemplateOrientation = TemplateOrientation.HORIZONTAL

WARNING: should also be changed in the function body if changed here.

Gistbatch added 3 commits April 19, 2024 09:45

Add pytest as explicit dependency

4f5cd82

Add new abstract method to base template

a0ad6d9

Add initial rectangle implementation

17db053

Gistbatch added 4 commits April 23, 2024 13:54

Switch abstract method to indices

7e7b508

The rationale is to get the plaquette indices from the template and then compute the positions according to the plaquettes.

Implement sample midline function for rectangle

f05bddb

Implement function to ge observable qubits from template

b342c3c

This construction is similar to the circuit generation

Move test accordin to new structure

e66b5a5

nelimee reviewed Apr 26, 2024

View reviewed changes

Gistbatch added 6 commits May 7, 2024 09:46

Add first batch of fixes

2bae306

Move function to avoid circular import

096aa90

Fix plaquette import

37ec4e8

Move test to avoid import error

0b220a7

Use fixture instead

d357d54

Use relative import

de7b88e

Gistbatch added 5 commits May 7, 2024 10:28

Merge branch 'main' into observables

e3e2483

Update test to functional style

8073864

Fix ptype hint

622ee21

Add midline plaquettes

b6af8c1

Add midlines for square

3317416

nelimee reviewed May 7, 2024

View reviewed changes

Add midline plaquettes for stack template

1b42bb2

Gistbatch added 4 commits May 7, 2024 13:29

Fix rectangle with unequal sidelength

f04a522

Fix square orientation

964277d

Implement midline for shifted template

9c922ec

Add not implemented error to make tests pass

8f8742e

nelimee reviewed May 7, 2024

View reviewed changes

Gistbatch added 11 commits May 7, 2024 16:04

Apply suggestions

fdc01e4

Remove type hints in docstrings

bb27dba

Merge branch 'main' into observables

f1bac10

Add qubit template midline

ebacea7

Fix logic mistace in rectengular templates

df85a1a

Improve test with scaling

829093a

Add exception testing to test

15913fc

Add tests for rectangle

237a4aa

Add test for corner square

37380ca

Implement stack test

a046540

Add test for shifted template

4e88c3f

Gistbatch marked this pull request as ready for review May 23, 2024 15:04

Merge branch 'main' into observables

007d684

nelimee approved these changes May 27, 2024

View reviewed changes

Gistbatch added 2 commits May 28, 2024 11:20

Rename argument "horizontal" to "orientation"

779c5b4

Move _get_edge_qubits to PlaquetteQubits

ca3bf33

Gistbatch merged commit 1a63daa into main May 28, 2024
6 checks passed

Gistbatch deleted the observables branch May 28, 2024 09:34

	plaquettes: list[Plaquette] \| dict[int, Plaquette],
	plaquettes: Sequence[Plaquette] \| Mapping[int, Plaquette],

		for index in midline_indices:
		row_index, column_index = index

	for index in midline_indices:
	row_index, column_index = index
	for (row_index, column_index) in midline_indices:

		indices = self._indices[midline]
		return [(midline, column ) for column, _ in enumerate(indices)]

	indices = self._indices[midline]
	return [(midline, column ) for column, _ in enumerate(indices)]
	return [(midline, column) for column in range(len(self._indices[midline]))]

	plaquettes: Union[Sequence[Plaquette], Mapping[int, Plaquette]],
	plaquettes: Sequence[Plaquette] \| Mapping[int, Plaquette],

	return list(set(observable_qubits))
	return sorted(set(observable_qubits))

	horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL,
	orientation: TemplateOrientation = TemplateOrientation.HORIZONTAL,

		horizontal: Whether to get the observable qubits from
		the horizontal or vertical midline. Defaults to True -> Horizontal.

	self, horizontal: TemplateOrientation = TemplateOrientation.HORIZONTAL
	self, orientation: TemplateOrientation = TemplateOrientation.HORIZONTAL

Observables #213

Observables #213

Conversation

Gistbatch commented Apr 22, 2024

afowler commented Apr 22, 2024 via email

nelimee commented Apr 22, 2024

Gistbatch commented Apr 23, 2024

nelimee commented Apr 26, 2024

nelimee 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

afowler commented Apr 26, 2024 via email

Gistbatch commented Apr 27, 2024

nelimee commented Apr 29, 2024

Gistbatch commented May 7, 2024

nelimee commented May 7, 2024

nelimee left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Gistbatch commented May 7, 2024

nelimee commented May 7, 2024

nelimee 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

Gistbatch commented May 23, 2024

Gistbatch commented May 24, 2024

nelimee 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

nelimee left a comment •

edited

Loading