Steane-Reed-Muller code #247
Conversation
|
Some ambiguities are now clear and resolved. The code size does fall to 0 at t = 4, r = 2 given the constraints he has set. He was trying to explain this in his paper.
This is what he said when he meant "To see more clearly why the method fails for k = 0, consider the following stabiliser for t = 2, r = 4:" on Page 5, 6. QuantumReedMuller(2,4) |
|
Improvements:
|
|
Improvements:
I have some ambiguities about the cases where the 'method fails are pointed when k =0' out by Steane, when the code size falls to zero, when it is suboptimal, and when it is less optimal, or close to optimal. (Resolved) Does this mean that being optimal is connected with the performance of the code itself? A suboptimal code then will perform less optimally in the tests as well. |
Fe-r-oz
changed the title
|
@Krastanov Please review the PR when you find convenient and when the time is right. Thank you! In the meantime, I believe it's good to have two or more consulting papers since the main paper is from 1999 as people have used different naming conventions later on, using |
So, I did a little investigation and I found out the it's correct that sub optimal and less optimal codes don't perform well with the min distance test. I took the all three examples from the paper and found out the following: What's shown below is the Dx and Dz, taking their bitwise or. The whole point of generating these matrices, as told by paper is to reduce the min distance. QRM (t, r) => (2, 5) Sub Optimal QRM (t, r) => (2, 4) Optimal QRM (t, r) => (1, 3) OPTIMAL That's why Steane point why there are sub optimal codes, and codes that perform less optimally. He says that ( 2, 5) is "close to optimal". In his words: "
|
|
Improvements:
|
That would be helpful. When making comparisons, please note the slight change in the matrix representation that Steane Used. Note how this matrix for RM(3,1) is represented from Left to Right. (2020 paper) For example, in this 2020 Paper the RM (3,1), notation (m,r) code is same as RM given that t=1, and r = 3 . But in Steane, it's represented from Right to Left! (1999 paper) |
Co-authored-by: Stefan Krastanov <github.acc@krastanov.org>
Co-authored-by: Stefan Krastanov <github.acc@krastanov.org>
|
I think it's the Steane notation that's out of place with other papers. Please note that m = 3, and r =1 (3, 1) provides matrix shown above, We can say it any way for RM (3 ,1) , (1, 3) , r here is 1, and m =3. But in steane paper, where he says r = 3 and t = 1 and gives the matrix that RM (3,1) (or RM (1, 3) however we want to call it). Note that r =3 and t =1 that corresponds to RM (3,1) or RM (1,3) given that r =1, m = 3 Therefore, There was no need to change the naming convention. Steane is using the RM(1,3)/ RM(3,1) matrix given that r =1 , m =3 but he is saying it's t =1 and r =3, same with the other two matrices. for t =2, r =4, t =2, r =5, Anyhow, I have made the notation consistent! |
|
Thanks a lot for your suggestions and your time! Note: I have added screenshot of Steane paper in above showing a difference in matrix representation as well. I hope this helps: Please have a look: #247 (comment) |
|
A reminder, please make one big push, not a ton of small pushes after each change. Otherwise a lot of mail spam and unnecessary (and computationally heavy) test runs are being generated each time. |
I have changed to steane convention of representation, so it will output the correct Stabilizer/H for values of t,r in exact same representation as that of Steane's :) Using Steane's convention, we can extract Gottesman codes from t=1, r=3 etc! The SteaneRM provides at t = 1, r = 3, this parity check Matrix H. This is exactly what is shown in the paper, He says this is [[8,3,3]] Gottesman code at j = 3 This H of Gottesman 3 is as follows, not in Steane form in which t=1,r =3 is defined: But Steane assumes the Steane convention for Gottesman codes as well, but the way Gottesman was defined, we had to do row operations to bring it into other form! That means, I would have to use Steane form of Gottesman code which is: |
Thanks for the reminder!! |
| stab = parity_checks(SteaneReedMuller(1, 3)) | ||
| H = stab_to_gf2(stab) | ||
| Hx, Hz = split(H) | ||
| gH = generate_gH(1, 3, Hx, Hz) | ||
|
|
||
| #Gottesman [[8, 3, 3]] | ||
| @test gH == [1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0; | ||
| 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1; | ||
| 0 0 0 0 1 1 1 1 0 0 1 1 0 0 1 1; | ||
| 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1; | ||
| 0 1 0 1 0 1 0 1 0 0 1 1 1 1 0 0] | ||
|
|
There was a problem hiding this comment.
I am confused by this check. Why is it so elaborate? Shouldn't it be simply:
for some_parameter in some_list
@test parity_checks(SteaneReedMuller(...)) == parity_checks(Gottesman(...))
end
There was a problem hiding this comment.
The hardcoded matrices you compare to are a bit dangerous. How can one know they are correctly copied from wherever they are copied?
There was a problem hiding this comment.
The reason I am worried about "elaborate" tests, is because if the test is not simple then you also need to worry about whether there are bugs in the test itself.
There was a problem hiding this comment.
The hardcoded matrix for j = 3 are taken from Steane's paper, Table 15 where he represents the stabilizer for Gottesman [8,3,3]] code.
Please #247 (comment)
The reason that this test will not work is that the size of Parity Check Matrix of Steane-Reed-Muller Code is different from the size of the Gottesman codes for the corresponding values of j.
@test parity_checks(SteaneReedMuller(...)) == parity_checks(Gottesman(...))
Steane explains in Table 14, 15, that the Stabilizer (1,3) of Steane-Reed-Muller Code is the Gottesman Code for j =3. But they have different sizes.
This is because Steane has appended Dx and Dz matrices, and we can extract the Gottesman code for the corresponding j from the Stabilizer (1,3) of Steane-Reed-Muller Code. Please have a look at the paper as well.
I have explained why canoncilize and stab_to_gf2 would not help here because the Gottesman code has a different basis as we had to do row operations to get to the convention that is represented in Gottesman thesis . In steane's paper, he has used a different convention for representing Gottesman codes (please see Table 15) . And through that convention, he laids the concept that Gottesman codes are subset of when stabilizer has t=1, r=3, 4, 5 ..
There was a problem hiding this comment.
Table 15 for Gottesman [[8,3,3]] is taken from Steane Paper: https://arxiv.org/pdf/quant-ph/9608026.pdf
There was a problem hiding this comment.
Steane explains in Table 14, 15, that the Stabilizer (1,3) of Steane-Reed-Muller Code is the Gottesman Code for j =3. But they have different sizes
Then compare the appropriate subsection of the code
I have explained why canoncilize and stab_to_gf2 would help here because the Gottesman code has a different basis as we had to do row operations to get to the convention that is represented in Gottesman thesis . In steane's paper, he has used a different convention for representing Gottesman codes. And through that convention, he laids the concept that Gottesman codes are subset of when stabilizer has t=1, r=3, 4, 5
If there is some canonicalization necessary then canonicalize! and potentially reordering of the columns should be enough. This currently looks much too complicated to be trusted as a test.
| end | ||
| end | ||
|
|
||
| function generate_gH(t, r, Hx, Hz) |
There was a problem hiding this comment.
What is this for? Seems very complicated.
There was a problem hiding this comment.
Since the Stabilizer of Steane-Reed-Muller code for t=1, r=3 has a size of 11 x 16 and the size of Gottesman code for j =3 is 5x8. They can't be compared even if we do canonicallize or stab_to_gf2. They are parity check matrices of different sizes.
So, we need to extract the code from the Stabilizer/H of Steane-Reed-Muller code. We note that Dx and Dz are used to minimize the minimum distance from 2^t to 2^t-1 so they serve that purpose. When we focus on Hx and Hz of the Stabilizer of Steane-Reed-Muller code, we can see how we can extract the Gottesman code! This is a general extraction routine that will work for any value of r = 3, onwards given that t=1.
There was a problem hiding this comment.
Why is all of this necessary if you just need to extract some subtableau from the SteaneReedMuller code? You can just write some_tableau[1:n, :] to extract the first n rows.
There was a problem hiding this comment.
You can just write some_tableau[1:n, :] to extract the first n rows.
Then compare the appropriate subsection of the code
It's not just as simple extract as it would appear. Please see the the Stabilizer for Reed-Muller-Code for (1,3) and compare with the Gottesman Stabilizer that he has presented for [[8,3,3]], we can easily see that it's not just simply extracting rows. Does it seem that simple extraction n rows work?
We have to carefully extract them, delete the Dx and Dz matrices, and then from the Gottesman rows. using canonicalize will not work in this case. I have tested using canonicalize to see whether it works in this context or not before making the function.
And the generate_gH(t, r, Hx, Hz) function correctly outputs the tableaue that the Table 15 presents.
| return (2^r + 2^r) - sum(binomial.(r, 0:t)) - sum(binomial.(r, 0:t - 1)) | ||
| end | ||
|
|
||
| function _steane_convention_qrm(mat) |
There was a problem hiding this comment.
What is this for? Any reason to prefer one convention over the other? Generally, I would prefer simpler code, even if it leads to a slightly different convention.
If this is for testing purposes (e.g. to compare a code of different family with different conventions), then it should live in the test file.
There was a problem hiding this comment.
This is the standard convention that is used by Steane in his paper. If we don't use steane convention, people would be confused.
By using this convention, it would help to maintain the code in the long run as it would be helpful as stabilizers in Steane's paper can be readily verifiable from the Steane paper. Please see this comment:
I have explained this a bit further here: #247 (comment)
using steane_convention_qrm, we can easily present the stabilizer results in a more readable and understandable way so the people who are following Steane's paper are not confused by the later papers, and so they can understand the stabilizers presented in table 14, 16, and 18 as well.
There was a problem hiding this comment.
I disagree that this makes things easier. This makes things harder to understand and review.
Correctness checks should be based on automated tests and property checking, not on manual verification with something in a paper (on the other hand verifying with the paper is a good initial check during development). After all, how do you know the paper does not have a typo.
There was a problem hiding this comment.
I have included the minimum distance test as a correctness test. Tests only works for optimal codes, not the less optimal codes, sub optimal codes or the codes for which the method fails meaning when code size falls to 0. All of this is pointed out by steane.
I included the steane convention just to resemble with the way of the paper. If you don't want to include the convention, it's okay.
Not using steane_convention_qrm would changes the order and result in complication of Gottesman code extraction as Steane as shown the Gottesman Code in his Convention. Please see the table 15. https://arxiv.org/pdf/quant-ph/9608026.pdf
And we extract rows without using the convention would result in more complication if we canonicalize. I have tried using the canoniclize and I have presented its output in the comment:
julia> using QuantumClifford: canonicalize!; stab_to_gf2(canonicalize!(parity_checks(Gottesman(3))))
5×16 Matrix{Bool}:
1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 0 1 1 0 0 1 1
0 0 1 1 0 0 1 1 0 1 0 1 1 0 1 0
0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0
0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
julia> stab_to_gf2(parity_checks(Gottesman(3)))
5×16 Matrix{Bool}:
1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
1 0 1 0 0 1 0 1 0 0 0 0 1 1 1 1
1 0 1 0 1 0 1 0 0 0 1 1 0 0 1 1
1 0 0 1 0 1 1 0 0 1 0 1 0 1 0 1
This is not how steane represents Gottesman codes. Kindly please see the comment: #247 (comment)
There was a problem hiding this comment.
Gottesman codes can be extracted carefully if they are presented in the notation Steane represents the Stabilizer for Reed-Muller Codes.
Please see:
There was a problem hiding this comment.
generate_gH(t, r, Hx, Hz) takes the value of t, and r, along with Hx and Hz and outputs the Gottesman Codes. There is a reason why the parameters are Hz and Hx of the corresponding SteaneReedMuller stabilizer and why we are not not passing H directly.
Simply extracting rows of the Stabilizer Tableau will not work. This can be seen if we see both the stabilizer of SRM code and corresponding Gottesman code.
| end | ||
|
|
||
| @testset "Test QRM(t, r) Matrix Minimum Distance" begin | ||
| for (t, r) in [(1, 3), (2, 4)] |
There was a problem hiding this comment.
Why are only these parameters tested?
There was a problem hiding this comment.
(1,3), and (2,4) are optimal codes. Their minimum distance is 3 and 6. And the test checks that, by checking the matrix H and by formula.
I have explained this in detail here: #247 (comment)
Steane has explained that (2,5) is a less optimal code. I included the tests for optimal codes that these are the codes that obey the minimum distance bound which is 2^t + 2^(t-1) that is set in his paper.
Please have a look at the comment. I have thoroughly investigated and explained that.
There was a problem hiding this comment.
Steane points out that the method he has described will result in less optimal codes, sub optimal codes along with the optimal codes. We can distinguish between the using the minimum distance test.
The (1,3), (2,4) pass the min distance test because they are optimal codes, as and (2,5) is close to optimal, but as we increase the value of t and r, the codes becomes sub-optimal. This is also presented in the conclusion of his paper.
There was a problem hiding this comment.
Please have a look at the comment. I have thoroughly investigated and explained that.
These comments will not be there when someone is trying to understand the tests. It is important to give this context to future readers in a succinct and easy to understand fashion.
There was a problem hiding this comment.
Please see this comment as well when the code size (k = 0 falls to zero) : #247 (comment).
|
Generally, aim to have the code be selfcontained. As you are preparing the pull requests you are making a lot of comments and separate commits which generate a lot of emails. I generally do not read these as it is difficult to distinguish what is important and what is just an autogenerated message or an unimportant tangential topic. Have your code be selfcontained so it can be understood on its own down the line, when someone is reading it in the future without having access to a long informal conversation in github (which would be difficult to read anyway). |
Thanks for your comments. I actually included those comments as notes as I read the steane paper as there were many points that were to be noted. And as I explored the paper more, it gathered up more notes. I believe it's better to have notes in a word document than github conversations |
|
You are free to keep notes however it is most convenient for you. Just make sure that things are available to the people that will be reading your code in the future, long after you have moved to other things (e.g. 10 or 20 years from now). |
|
It seems the following might be one of the main source of miscommunication is the following: This PR provides the following parity check matrix And the paper gives this for the corresponding generator matrix There seems to be a mismatch here. If I am reading the paper correctly, you have confused the generator matrix and the parity check matrix. |
Nope, I have not because if we go to the next pages, he represents them as Parity check matrices, not Generator matrices. Please see SRM (2, 4) , SRM (2, 5)
|
|
Whatever the paper is saying, your code is definitely not doing that. Check for instance the example I picked.
|
The code is definitely doing that. I can prove that pretty easily.
In the paper, Steane says the TOTAL ROWS are N +K. So, for t=1, r=3, the total rows must be 11 and 16 columns, Rows are NOT more than columns..
|
|
Please see:
|
|
What your are talking about is the generator matrix, not the parity check matrix. Please answer the following:
|
The parity check matrix for 1,3 Does not have more rows than columns. Please see, the parity check matrix H does not have more rows than columns.
YES He says the 'Stabilizer of the code', He is in turn talking about parity check matrices. He has shown the method of how to construct the stabilizer for the Steane-Reed-Muller codes and I have followed the paper. when we do
|
|
Rows of the Parity check Matrix for I have attached a few examples: The Gottesman (3) is also shown., Any code can be used to verify this. |
You are making a mistake in something pretty basic here. Please review some of the resources on error correcting codes before we continue with this conversation. Here is again the parity check tableau that your implementation is generating:
This has 8 columns, corresponding to 8 qubits. It has 11 rows, corresponding to 11 parity checks. If this is a code, it would have I guess you are looking at the matrix in binary (X and Z part side by side), but then you need two columns per qubit - one for the X operations and one for the Z operations. |
|
Moreover, the rows of your parity check matrix do not commute (e.g. the two last rows). This is another sign that the code is definitely wrong. I am actually very surprised that the tests did not catch this... I thought it was being checked automatically. |
|
I am surprised why the miscommunication arose It seems that you have not reviewd the Steane paper fully or maybe I am not explaining precisely? I followed his approach accordingly. Maybe, the miscommunication is between the paper constructs stabilizer and stabilizers are used in QuantumClifford |
I guess the miscommnication is the how the stabilizer is inherently defined in QuantumCLifford and how Steane is presenting them. I agree this will have error when we do circuit encoding because of the logic that you are using. |
|
I will have to close this for now. If you want to reopen the discussion please be explicit in explaining the following:
|
Commutativity property has to be satisfied. That's the reason why SteaneReedMuller (1,2) is not a quantum code.
No.
Please remember when you said,
So, this should give us H or G? Similarly, You asked me what's the parity check Matrix for parity_checks(SteaneReedMuller(1, 3))). I followed the same line of reasoning to conclude that it should give us H. The problem is the inherent definition of the Stabilizer and how it's used in the encoding ? |
|
Also, I believe the miscommunication arose because of the differeing conventions and how Steane approach the paper. That could be the reason. I am not sure why this miscommunication arose |
|
Dear Professor, I would like to open this request. My apologies for causing inconvenience. |
|
Fe-r-oz, I do not think we should attempt to do a GSoC together, I would not be an effective mentor for you. You are extremely talented, but without you contemplating the possibility that you can be wrong about something, I would not be able to trust that you have thoroughly checked your work. Both in this PR and in the previous PR on Gottesman codes you made mistakes, I pointed out the mistakes by focusing on fundamental properties that the codes have to obey, i.e. checks that are so universal that they should be true no matter the code, and you doubled down on saying that the papers say whatever you are saying. You certainly have implemented something based on these papers, but the interpretation of what you have implemented is wrong, the bigger picture understanding is missing. In this particular case, I have multiple times already said that you are producing generator matrices instead of producing parity check matrices. You have not shown understanding of the difference between these, which would have been fine on its own, but doubling down on your claims without checking is not fine. There is nothing wrong with Steane's approach, but the approach you are implementing simply does not produce the parity check matrix (it seems it is an intermediary step to producing the parity check matrix). I want to make sure that you get credit for the things you have already implemented. Please let me know how can I list you as one of the contributors at https://eccbench.areweentangledyet.com/contributors/ |
|
Dear @Krastanov , Please let's continue conversation on slack. |
|
Please open the PR so that we can finish it . I also want this PR to end well. The last two messages provides the source of miscommunication. I request your to please commit your time this summer as your mentorship is much needed. I am really committed as I tried best as I opened back to back 4 PRs in one month to demonstrate my commitment. Of course, I did mistakes in two PRs, and I am grateful for your time and commitment. Unfortunately, in this PR, there was miscommunication, and I am sorry for that. I hope to continue working on this PR. Please open this PR, I will incorporate your comments, and will focus on the universal properties when making tests. Suddenly closing the PR might not be the best route, please re-open so it can be finished. Please don't punish me this severely for the mistake. I will readily improve and not repeat the mistakes. Please see the last two messages. |
Dear @Krastanov, Please read through the last two messages. I have found the source of miscommunication! Gottesman casestudy In Gottesman codes, Gottesman captions as 'The Stabilizer of the [[16,10, 3]] Code. QuantumClifford Gottesman implements this Stabilizer when we write
In QuantumClifford, this is presented as follows: where we can write it a stabilizer form as XXXXXXXXXXXXXXXX => 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 etc. And if we do Example of Gottesman as case study: In QuantumClifford, this is a stabilizer Generator for Gottesman (4), This is in Steane paper but it's surprising why some properties are not satisfied.
As per your sentence, Gottesman(4) must give us the parity check matrix H which is given by its stabilizer Generator ?
The stabilizer gives the parity check matrix. Please see the last message!
Since the size of the Stabilizer Generator of Gottesman 4, we can say that if we look at the corresponding matrix of 1s and zeros, we can say that it has 32 columns and 6 rows that corresponds to parity checks. K = 6 - 32 = -26?? Steane-Reed-Muller Stabilizers Very similarly, in Steane paper, he is presenting the stabilizers of the codes as t =1, r =3 and t = 2, r=4, and t =2, r = 5. There, similarly, as we have seen in the Gottesman(4) example above, SteaneReedMuller (1,3) implements the Stabilizer Tableau that corresponds with the stabilizer
There, the QuantumClifford Stabilizer implements the Stabilizer which is the parity Tableau. . Hence, the parity_checks(SteaneReedMuller(1,3)) returns the stabilzier of the code at SteaneReedMuller(1,3) that is presented in his paper. It's returning me the stabilizer similar to Gottesman(4) that should give the parity check Tableau. The PR has implemented the Stabilizer Codes that represent stabilizers for Steane-Reed-Muller codes as shown in this paper that provides parity check Tableau given in Steane's paper. This PR shouldn't trashed out. Please open the PR so we can finish it. I followed the following algorithm as presented by Steane to construct Stabilizer: The steps to implement G are:
Maybe the issue is about misphrasing about what stabilizers of Given how the Stabilizer is constructed for any code, it requires two parameters right? Is the Job of the I believe the source of miscommunication is misphrasing The SteaneReedMuller, constructs the stabilizer of the given code at value of t, r and that should give it's parity check tableau. As for the -k qubits, I believe maybe since we have the bionomial formula, that's why we are having this discrepancy? Please let me know the wrong points here. I will look at the commutativity comment and universal properties that you point to. I am all ears. I have noted your points. I wanted to present my perception of the source of miscommunication. I hope that this helps. |
|
Dear @Krastanov Please see this as well He and Steane is calling them parity-check matrices, but you are phrasing them as 'Generator Matrics'?
If we follow the above definition of what a parity check matrix is, Steane's is presenting parity-check matrics not the 'Generator' Matrices!
Paper is talking about Parity check matrices, not the 'Generator' Matrices! Steane has not used the term 'Generator Matrix' at all in the paper. He is talking about stabilizers of the code that correspond to parity check matrix.
Also, please note the definition of Stabilizer H given in Steane paper: It's the same definition that is used in Quantum Clifford for Stabilizer.
The Stabilizer of the code is its parity check Tableau as you said. Note the symbol Fancy H sub t =2, r =4. That represents 'parity check Tableau' given the definition of the Stabilizer. Kindly Please let me now your comments. We can should investigate the weird properties of these parity check matrices, but they are parity check matrices, not the 'generator matrices' that is the assumption that you made yesterday. I hope that this at least clears some miscommunication. I am all ears. Let's resolve this as It would like to work on the PR |
|
I am locking this after a private conversation with Feroz |
Prof. Stefan,
Adding the implementation of Steane Reed-Muller(QRM) codes. Paper followed is by the Steane who discovered them.
ReedMullercodes are utilized as discussed in the paper!isCSSfunction that we implemented for CSS codes is insufficient to test whether QRM codes are CSS if they are CSS. This is because of the X, Z, Y we have in QRM because of Dx and Dz. Please see stabilizers 14, 16, 18 in Steane's paper. (Resolved)