-
Notifications
You must be signed in to change notification settings - Fork 49
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
Zoo: [[2^j, 2^-j-2,3]] Gottesman /Quantum Hamming Code #238
Conversation
Iterative Decoder Attempted Packages Used: 1. QuantumClifford 2. LDPCDecoders 3. Distances
#how to use # Create two different instances of the quantum Hamming code #code1 = QHamming(5) # r = 5 #code2 = QHamming(7) # r = 7 # Get the parity check matrices for each instance #H1 = parity_checks(code1) #H2 = parity_checks(code2)
Package to be used: Linear Algebra # Example usage #n_i = [2, 3] # Valid example #k_i = [1, 2] #d_i = [1, 1] #r_i = [1, 1] #code = HypergraphProduct(n_i, k_i, d_i, r_i) # Access and use functionalities: #println("Code block size (n):") #println(code_n(code)) #println("X parity-check matrix:") #println(parity_checks_x(code)) #println("Z parity-check matrix:") #println(parity_checks_z(code))
Create hypergraphproductcode.jl
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 a pretty good start, thank you! I would suggest focusing just on implementing QHamming here, leave the rest for other PRs. Add tests and documentation, make sure it actually works. I left some stylistic comments in as well.
To keep this easier for me, I will mark this back to "draft" stage. When you are ready, please click "resolve" on my comments above and re-request a review. |
I ran some quick benchmarks on your routines. Here are plots of performance of the 3, 4, and 5 codes 3 and 4 look great, but I am a bit worried that there must be something wrong with 5. They all should have the same slope (the slope depends on the distance which is 3 for all Gottesman codes). I will need to do some debugging... |
Thanks for refinement. By class, I meant the error code class, but it's a family. Since the changes v.0.8.22 were not added from my branch on the master, so I thought to add this sentence. |
I see you are making a special case for j=3. Why? Which algorithm exactly did you use? The one in Gottesman's thesis or another one? |
I mentioned this point in my earlier comment when I mentioned about pedagogical details.
I utilized the symmetric structure and developed the algorithm myself that satisfied the checks for j>=4. Thus, defined j==3 as special case. This was convenient and much faster approach. I designed the algorithm by hand as I did draw many tables for j>=4, so I saw a visible symmetric structure. Hence, the algorithm proved correct when it satisfied j==4, and the symmetric structure is visible as well. Then I read his thesis again, the 4 pages from page 90 to 93, that Gottesman were describing some of the checks (not all), but I ended up implementing all the checks. The fact is that his approach/checks are not complete to design a general algorithm if we consider even j and odd j at the same time. So, had to come up with a general algorithm which includes his checks. This verified not only the results but the theory. |
It is really cool that you tried to design it by hand, but at this point I am fairly certain there is a mistake in. Do not get discouraged though, you have done it exactly the way in which you get to learn the most out of your mistake. One word of caution though: if you design something yourself, you have to always be extremely mistrustful of your own implementation. The issue does not seem to be particularly consistent. Maybe it fails only for odd powers. Here is the test including j=6. It works exactly as expected for j=6. Now the goal is to figure out what is the error for j=5. One way to try to figure that out is to implement someone else's version of the algorithm. Gottesman spells out exactly all the steps in section 3, paragraph 3-5, of this paper https://arxiv.org/pdf/quant-ph/9604038.pdf For the moment I will turn this again into a draft. We can not merge it with the j=5 bug. Also, it is possible there is no bug here. Maybe the bug is in the tool I use to test. I will make that one public later today. |
Please test for j=7, j=9, odd powers etc. as well. I am confident that the symmetric structure and algorithm holds otherwise, it would not have worked at all because it has to be spot on to get configuration in j==4 is somewhat complicated symmetry. I drew the tables by hand to verify the algorithm. I read details of section 3, paragraph 3-5, but the details he provides are not complete to implement a general class for works for all j values. No mention of different checks is mention here but he mention it in his thesis. The Question is: How do one expand from j==3 to j==4 or 5 onwards without implementing diffferent checks? That's why he suggests different checks in his thesis. He discuss the even and odd j details in his thesis Table 8.1 Page 91 from pages 90 to 95. Also, there is a 3x7 Hamming matrix inner structure as well which is not mentioned in the details. Gottesman codes are called extended hamming for this very reason. This inner hamming matrix 3x7 structure is missing for j==3 (another point that tells it's a special case). |
I probably will not be able to get a check for j>7, these are expensive to run. I disagree about the paper. It lists the complete algorithm. It is something like this: consider a fixed j and then set n=2^j (number of physical qubits) and k = n-j-2 (number of logical qubits) and c = j+2 (number of checks)
More explicitly: For parity check row R and qubit column Q you have to put the following Pauli:
This can be done easily with our library. You do not need to actually compute the three tables in advance, you can do everything on the fly:
By the way, in case you have not seen it before, extracting a bit from an integer can be done as: |
Thanks. I read the appendix of paper that you mentioned https://arxiv.org/pdf/quant-ph/9604038.pdf. The Table V gives Xi, Zi, and Yi. The algorithm produces the same Xi, Zi checks! I will recheck Yi (seem similar though, but I will check). It seems the the last row for odd js is not assumed to be same as even js which was assumed! It means that the last row for odd js as same as even js that's why - which can be fixed!! Some details in the appendix of same paper: My question is that although I agree that the paper you referenced provided similar starting details as in thesis, but the way Gottesman entertain [16,10,3]] adds new set of different details on top of the details the he provides in the previous paper. Why does he start from the same set of details and expound further in his thesis needs to be investigated? Kindly please have a look at the pages 90 to 95 as well. I will read both of the papers again, and try to find the hidden incongrueny! |
I have tried to fix the hidden bug. Please see the graphs There was assumption that about the last row that I assumed to hold for all cases j (even as well odd). Everything else is the same. For odd js: This agrees with the j==3 in structure as well! It will hold for all odd js.
G(3), G(4), G(5) |
I am unsure what you are saying -- I do not know whether you are talking about your algorithm or about the algorithm in the paper.
I have not read the appendix. It seems to be about a proof that the algorithm described earlier in the paper is correct. I was just looking at the definition of the algorithm in section 3.
That is pretty normal when someone writes a thesis that includes one of their paper from a few years earlier. I imagine (I am not sure), that the author simply wanted to provide some additional insight, so they structured the presentation a bit differently and choose a slightly different convention for bit ordering or error ordering.
I do not think there is mismatch in what they are doing in the two publications. One might have slightly different conventions from the other, but you already found other papers that also had slightly different conventions. I am very impressed you were able to find your bug so quickly! However I also need to worry about the maintainability of this piece of code (in a year or two you might not be involved in the project to fix other bugs). Because of this, I prefer we switch to the algorithm as described in Gottesman's paper:
Presumably the two should give the same answers (up to some reordering). At the end, that is the only way to be sure (or at least "a bit less unsure") that there is no other bug here. |
I am talking about the algorithm that is presented in the paper. The homegrown algorithm produces the same Xi, Zi checks.
I think that even and odd checks in Pages 92 and 95 are necessary, as in the paper, he does not consider that [[16,10,3]] even case and how its differs from the the initial odd case [[8,3,3]] that he describes in earlier paper prior to thesis. But he goes into detail in his thesis.
It's not about convention but about the type of the even and odd checks that results in a slightly differeny symmetric structure for even j values and odd j values. He dedicates 3 pages to the checks, meaning they are significant part of the algoritm!. My homegrown algorithm satisfies that.
While I understand your concens, Please rest assured as I have faith in the symmetry and intuition, it holds nicely and precisely it does satisfies the Table 8.1 on Page 91 of his thesis! That is a good cross-verification! I will always be available to maintain this code as I would like to keep on contributing to this initiative. It's just more fun to follow an intuitive approach as it makes me excited as it makes the learning more fun! The slight bug was there in my assumption of combining even and odd check at one place which I took care of. I knew about the assumption so it was not luck. Since, I approached the design from methodolody of his thesis, it's a standard reference! I don't think the shorter version will be bug free if checks are not included, otherwise he would not have dedicated 3 pages to them in his thesis. Gottesman concludes the section as "There may be other symmetries of these codes, as well." Please be assured! |
Your work is impressive, but this is not how assurances work, especially not in math and computer science. You should never trust your own code. The amount of trust you put in yours is how bugs happen. Verifying one case against a table is not a good verification (as we have seen already). There is never a way to be completely sure in the correctness of a piece of code, but there are reasonable ways to increase the probability that the code is correct. Here there are two pretty straightforward ways to do it:
Both of these are necessary before this gets merged. Obviously, you work as a volunteer for this and I can not demand anything -- you have already made a very helpful and valued contribution and I am grateful for it. You also shared a lot of resources that were very interesting, and this discussion has certainly been valuable for me. I thank you for all of these contributions!!! I will be happy to finish this on my own if you disagree about the approach I am taking. |
And there is a pretty easy way to convince me that the algorithm I am suggesting, the one from the paper, needs these extra checks -- write it and show that it does not pass the tests I just mentioned (the one with the length of the set of syndromes). |
Thanks for the two points. I'll read the paper that you referred and implement it. Can I include these two points in initial weeks of my proposal (to write an algorithm for the paper) as I need time to carefully read the paper and then focus on implementation as you want a exact paper implementation? That will help in more literature survey and spend time with the specific paper as I will spend next month in literature survey. |
The tables I defined in my comment.
You do not need to compute the tables in advance, i.e. no need to store them in memory. You do need to loop through the rows and columns, but entries can be computed on the fly.
For j=3, we have n=8 physical qubits, k=n-j-2=3 logical qubits, c=n-k=5 checks, which means the parity check tableau should indeed have 5 rows and 8 columns.
I will write it and upload it here in a couple of days when I get around to it. It is just 20ish lines. |
Thanks! I mixed the Tables provided in the algorithm that you mentioned namely tableX, tableY, tableZ tables on Page 17. That's why I was confused about where were the tables!
I see, then it will be way less lines since we are Pauli operators based on error type!! Indeed, it might be very short code them. I thought we needed to compute all the different combinations as were described in table 1. Thanks for clarification! |
here is the code
and here is the checks for it
|
Dear Professor Please see the output of j==4 [[16,10,3]], it does not match with what is presented in his thesis Table 8.1 Page 91 |
In fact, the first two bits of Xi must always be 01 but the out is showing 10.
But there is a fundamental design error according to my understanding of his thesis, M1..Mj , first two digits can't be X. Please see his comments below: I think there may be merit to the checks he mentioned in his thesis. Here is what the 16 10 3 Stabilizer is like:
The stabilizers does not match. There are very significant changes in the stabilizer |
Hi Feroz! I answer that question in the linked pull request. The stabilizers are equivalent because you can obtain one from the other by performing a row operation. |
Closing in favor of #240 which is a slightly updated version of this. |
Implementation for Gottesman Code