-
Notifications
You must be signed in to change notification settings - Fork 48
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
Make an interface to QEC libraries, specifically so that you have access to predefined codes #14
Comments
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 |
this repository also has some related materials errorcorrectionzoo/eczoo_data#269 |
also, keep an eye on: https://pypi.org/project/mwpf/ |
Maybe this is helpful, Loss-tolerant teleportation on large stabilizer states . Stabilizer PathFinding: https://github.com/sammorley-short/spf |
|
|
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. |
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. |
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 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).
Maybe, this perspective on quantum codes from classical codes might be helpful: #311 |
@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 |
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. |
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:
QuantumClifford.jl/src/ecc/decoder_pipeline.jl
Line 272 in 64f695c
QuantumClifford.jl/ext/QuantumCliffordPyQDecodersExt/QuantumCliffordPyQDecodersExt.jl
Line 92 in 64f695c
The text was updated successfully, but these errors were encountered: