Change the `scale`/`k`/`dimension` definition across the library

[nelimee]

Template and TemplateOrchestrator instances are currently scaled to a given dimension (or scale, or k, all these symbols refer to same quantity for the moment) with the scale_to method.

This k is defined as the number of plaquettes in one of the scalable dimensions or the Template. With an example, for the ScalableQubitSquare, k is defined as the number of plaquettes in the x dimension of the inner ScalableAlternatingSquare (or equivalently the y dimension, both are always equal). For k == 4, the following template is constructed:

.  .  1  .  1  .
2  3  4  3  4  .
.  4  3  4  3  5
2  3  4  3  4  .
.  4  3  4  3  5
.  6  .  6  .  .

The current definition of k is not standard and might be an API issue for future users that might have hard times understanding the rationale behind this decision (there is none except that it was fixed like that at the very early stage of code development).

It would be nice to change, at least in user-facing parts of the library, the meaning of this parameter to something that is more understandable. Options are the following:

1. The equivalent of k // 2 as was initially proposed in the course slides. This would force the user to generate "valid" codes. As noted by Austin, the current ScalableCorner construction is generating an invalid code for odd k (drawn below is k == 3):

   .  .  1  .  .  .  .  .  .  .
   2  3  4  3  .  .  .  .  .  .
   .  4  3  4  5  .  .  .  .  .
   2  3  4  3  .  .  .  .  .  .
   2  3  4  3  .  .  .  .  .  .
   .  4  3  4  6  .  7  .  7  .
   2  3  4  8  9  8  9  8  9 10
   .  4  8  9  8  9  8  9  8  .
   2 11  9  8  9  8  9  8  9 10
   .  . 12  .  . 12  . 12  .  .

2. Change k by code_distance. This option may be the easiest one to understand for people with a background in QEC. In fact this is what is done in the Normalise the API between stim and tqec section of the logical_qubit_memory_experiment.ipynb notebook.

In am open to more ideas for options, and would love to have feedback on the different options provided here.

[afowler]

Checking whether a code realizes a particular distance is nontrivial. It is certainly possible to construct circuits that propagate errors badly and have poor code distance despite being rather large. I would recommend focusing on the original definition of k as specified in the lectures, as this removes the need to get unusual sizes of grid working, and defers the study of the actual code distance realized to later, which I feel is appropriate. At the moment we are designing a tool to enable people to create scalable quantum circuits, but there is no guarantee that that scalable quantum circuit will achieve a particular code distance. That will come out of later analysis.

On Wed, Jan 10, 2024 at 12:36 AM Adrien Suau @.***> wrote:

Template https://github.com/QCHackers/tqec/blob/f6f29323ebf2544ae576c6866167026adbfa6359/tqec/templates/base.py#L50 and TemplateOrchestrator https://github.com/QCHackers/tqec/blob/f6f29323ebf2544ae576c6866167026adbfa6359/tqec/templates/orchestrator.py#L55 instances are currently scaled to a given dimension (or scale, or k, all these symbols refer to same quantity for the moment) with the scale_to https://github.com/QCHackers/tqec/blob/f6f29323ebf2544ae576c6866167026adbfa6359/tqec/templates/orchestrator.py#L340 method.

This k is defined as the number of plaquettes in one of the scalable dimensions or the Template. With an example, for the ScalableQubitSquare https://github.com/QCHackers/tqec/blob/f6f29323ebf2544ae576c6866167026adbfa6359/tqec/constructions/qubit.py#L8, k is defined as the number of plaquettes in the x dimension of the inner ScalableAlternatingSquare https://github.com/QCHackers/tqec/blob/f6f29323ebf2544ae576c6866167026adbfa6359/tqec/templates/scalable/square.py#L8C7-L8C32 (or equivalently the y dimension, both are always equal). For k == 4, the following template is constructed:

. . 1 . 1 . 2 3 4 3 4 . . 4 3 4 3 5 2 3 4 3 4 . . 4 3 4 3 5 . 6 . 6 . .

The current definition of k is not standard and might be an API issue for future users that might have hard times understanding the rationale behind this decision (there is none except that it was fixed like that at the very early stage of code development).

It would be nice to change, at least in user-facing parts of the library, the meaning of this parameter to something that is more understandable. Options are the following:

1. The equivalent of k // 2 as was initially proposed in the course slides. This would force the user to generate "valid" codes. As noted by Austin, the current ScalableCorner https://github.com/QCHackers/tqec/blob/f6f29323ebf2544ae576c6866167026adbfa6359/tqec/constructions/corner.py#L13 construction is generating an invalid code for odd k (drawn below is k == 3):

   . . 1 . . . . . . . 2 3 4 3 . . . . . . . 4 3 4 5 . . . . . 2 3 4 3 . . . . . . 2 3 4 3 . . . . . . . 4 3 4 6 . 7 . 7 . 2 3 4 8 9 8 9 8 9 10 . 4 8 9 8 9 8 9 8 . 2 11 9 8 9 8 9 8 9 10 . . 12 . . 12 . 12 . .

2. Change k by code_distance. This option may be the easiest one to understand for people with a background in QEC. In fact this is what is done in the Normalise the API between stim and tqec section of the logical_qubit_memory_experiment.ipynb https://github.com/QCHackers/tqec/blob/main/notebooks/logical_qubit_memory_experiment.ipynb notebook.

In am open to more ideas for options, and would love to have feedback on the different options provided here.

— Reply to this email directly, view it on GitHub https://github.com/QCHackers/tqec/issues/36, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKAXTEWCIF2Y6UNXJALKMTYNZHKRAVCNFSM6AAAAABBUMIZWWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3TGOBWGA4TCMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[nelimee]

I'll leave this issue open for a few days if someone wants to try to tackle it. It might be a good and simple way to start developing in the code base and learn about some of its internal implementation.

If nobody expressed the desire to implement that in a few days, I'll make it.

[inmzhang]

I would like to work on this but since I just got started with the project, it might take some time to familiar myself with the overall project and its detailed implementation. If you are ok with the time of waiting, please feel free to assign this to me.

[nelimee]

Note that #59 might change a lot of things on the backend side, you might want to wait for it to be merged before writing code. If you have any question, feel free to ping me :)