Make an interface to QEC libraries, specifically so that you have access to predefined codes

[Krastanov]

• https://www.cgranade.com/python-quaec/
• https://qecsim.github.io/
• https://github.com/qiskit-community/qiskit-qec
• https://panqec.readthedocs.io/en/latest/index.html
• https://github.com/PECOS-packages/PECOS

This can be based around package extensions and PythonCall interfaces, similar to how we are doing python-based decoders. E.g. see how we have implemented the pymatching decoder interface:

• In ECC/decoder_pipeline.jl

  QuantumClifford.jl/src/ecc/decoder_pipeline.jl

  Line 272 in 64f695c

  """A perfect matching decoder built around tools from the python package `pymatching` available from the julia package `PyQDecoders.jl`."""

• actually implemented in an extensions

  QuantumClifford.jl/ext/QuantumCliffordPyQDecodersExt/QuantumCliffordPyQDecodersExt.jl

  Line 92 in 64f695c

  function PyMatchingDecoder(c; weights=nothing)

• with the extension being dependent on this library that uses PythonCall to install what is needed https://github.com/QuantumSavory/PyQDecoders.jl

[Krastanov]

probably just reimplementing the few codes that are built in https://www.cgranade.com/python-quaec/stab.html#qecc.StabilizerCode.flip_code and adding more

[Krastanov]

this repository also has some related materials errorcorrectionzoo/eczoo_data#269

[Krastanov]

also:

• https://qecsim.github.io/
• https://github.com/qiskit-community/qiskit-qec
• https://panqec.readthedocs.io/en/latest/index.html

[Krastanov]

also https://github.com/PECOS-packages/PECOS

[Fe-r-oz]

also, keep an eye on: https://pypi.org/project/mwpf/

[Fe-r-oz]

also, https://github.com/yuewuo/fusion-blossom

[Fe-r-oz]

Maybe this is helpful, Loss-tolerant teleportation on large stabilizer states .

Stabilizer PathFinding: https://github.com/sammorley-short/spf

[Fe-r-oz]

• BP+OSD: A decoder for quantum LDPC codes: Besides the main decoder functionality, Hypergraph Product code is present along with capability to calculate the logical X and logical Z operators for CSS/QLDPC codes. This can be of use when doing correctness checks as well. The css_codemethod has the built-in functinality to calculate lx and lz. Do we need to upgrade the CSS method so that it can also keep track of lx and lz similar to functionality in css_code?

[Fe-r-oz]

• CodingTheory.jl: This package contains a lot of quantum and classical codes. Subsytem codes are also present along with examples of subsystem subcodes. It would be helpful in the ECC side and will help us focus more on circuit simulation side. It also contains minimum distance algorithms for calculating the minimum distance of quantum ldpc codes. The code distance for ldpc codes require sophisticated algorithms such as Integer Linear Programming (ILP) approachs which was used by Bravyi in his BBQLDPC paper. Has methods for weight enumerators for LDPC codes as well. This would be useful in correctness checks as well as there are codes present here as well. Furthermore, there is support for analysis for codes which can be helpful.
  @esabo, @Krastanov pinging you so that you can discuss this further!

[esabo]

I don't have any plans on doing anything with the circuit side of things. The eventual goal was to export my code objects to a different package for this. The only other one I know of was Yao, but I am happy to make my stuff compatible with yours. On the other side, my implementation of codes seems further along than what you've currently done, and it may be time saving to simply use mine. My package is aimed at code construction and analysis. The quantum side is less developed than the classical at the moment, but I am actively working on that. I would like to know what people in the field want the ability to do with (quantum) codes such that I can go implement that. Right now, the quantum side is just what's off the top of my head. From what I gather talking to many people, my two top priorities are 1) minimum distance algorithms and 2) automorphism groups. When I get these and finish the documentation, I'm going to write a white paper and submit it to the Julia package manager. It's open source and I'd be delighted to have other people contribute.

I noticed in particular you guys have done quantum Tanner codes. This is really cool. I haven't done this yet and do not see a point in reinventing the wheel if I (someone) can make your code there compatible with how I've structured things.

[Krastanov]

Hi, @esabo , thanks for reaching out. Your work is quite impressive and it would indeed be very valuable to us. One near term thing we can try to do is to make a pkgext in QuantumClifford that implements the APIs we need for all the codes you have already implemented. We have pretty minor needs: a function that provides the parity check matrix basically.

Our focus is fairly exclusively on quantum codes, but we occasionally need some progenitor classical code on which to build a quantum one.

We are also fairly open to moving anything we have related to codes to your library and just making your library a dependency for us. E.g. if we have (merged or as a PR) quantum codes that you do not have implemented yet, it makes a lot of sense to move them over to your repository. If you are interested in that, let me know and we can figure out a transition plan (nothing quick, it would probably take a while as we are all volunteers).

Concerning Yao: At least some time ago, Yao was using QuantumClifford as a Clifford circuit backend. Maybe they have their own now.

[Fe-r-oz]

Indeed, it makes sense as you utilize a pure Oscar framework to implement both quantum and classical codes.

@esabo, There is one classical code that comes to mind as well which CodingTheory might not have atm: The Goppa Codes. There are different formulations of these codes: One of the formulation uses riemann-roch (RR) theorem over genus 0. There are later papers that reformulates them as algebraic over RR with g=0 (this is where the Hecke constructors for riemann roch space might be helpful as Goppa code is technically one of the first AG codes. But the standard approach, the one given by Goppa, was is the one that is mentioned, for example, in Binary Goppa codes. I implemented it using the standard formalism but I think it can be further standardized to meet your requirements and to be compatible with the rest of the codes. Here is the PR: #266.

I would be happy to standardize and contribute Bivariate Bicycle quantum BBQLDPC code as well. Bravyi approach (finding the polynomials numerically gave rise to good BBQLDPC codes) may differ from your standardized approach of using polynomials so it is compatible with rest of quantum codes. PR: #352. (Thank you, you provided the answer to this. Indeed, your approach is more mathematically rigorous).

I would like to know what people in the field want the ability to do with (quantum) codes such that I can go implement that.

Maybe, this perspective on quantum codes from classical codes might be helpful: #311

[esabo]

@Krastanov Yeah, this all sounds good to me. I can easily export to Julia matrices. And yeah, I've never looked too deep into Yao but that's cool. Can you guys build detector models so I don't have to export to STIM?

@Fe-r-oz Well.....technically Goppa codes are there. Just build the cyclic code and then use the subfield subcode constructor. I don't yet have a dedicated Goppa codes constructor because I wasn't sure how to do the 1/(x - a) at the time. I think Oscar will do this automatically now if necessary. There are a number of named classical codes I think should have constructors before publishing the package. For example, with respect to cyclic codes, Fire codes, Goppa codes, alternate codes, multidimension cyclic codes, duadic codes, etc. Based on my existing framework and your PR, we can probably collapse Goppa codes down to about 20 lines or so.

[Krastanov]

We have the equivalent capabilities to the ones from stim's detector model, but I am not sure they are in the format you would want. Please feel free to create a new issue for that -- just copy some pseudo-code for the capability you want and I will either document the equivalent or implement it.