add-2BGA-codes #18
add-2BGA-codes #18
Conversation
|
|
The codes were successfully added I just think that I now need to add some extra code for the graphs and descriptions. |
modified: _0.helpers_and_metadata/code_metadata.jl modified: _2.markdown_generation_pass/figures.jl
modified: _0.helpers_and_metadata/code_metadata.jl modified: _0.helpers_and_metadata/helpers.jl modified: _0.helpers_and_metadata/code_metadata.jl modified: _0.helpers_and_metadata/helpers.jl
|
@EDesec , this is great! I made an extra wrapper tool so that it is easier to categorize multiple codes even if they are using the same constructor from QuantumClifford. For our next meeting (Tuesday 25th) could you update the names and descriptions of these objects? |
There was a problem hiding this comment.
inline I added a bunch of comments that will hopefully help
make sure you do a pull on this branch before you continue contributing to it so that you have all the changes I have made
also update your QuantumClifford and PyQDecoders as I made some minor quality of life improvements to them (these improvements should be public tonight)
|
|
||
|
|
||
|
|
||
| PutAGoodNameHereAboutGenBicCodes = PrettyCodeFamilyWrapper( |
There was a problem hiding this comment.
start here -- give this variable a, more descriptive name
|
|
||
|
|
||
| PutAGoodNameHereAboutGenBicCodes = PrettyCodeFamilyWrapper( | ||
| :PutAGoodNameHere, |
There was a problem hiding this comment.
and basically copy the name as a symbol here (prepended with :)
| :C₂₇ => ([0 , 1, 3, 7], [0 , 1, 12, 19], 27), | ||
| :C₃₀ => ([0 , 10, 6, 13], [0 , 25, 16, 12], 30), | ||
| :C₃₅ => ([0 , 15, 16, 18], [0 , 1, 24, 27], 35), | ||
| :C₃₆ => ([0 , 9, 28, 31], [0 , 1, 21, 34], 36), | ||
| :C₃₆K₁₀ => ([0 , 9, 28, 13], [0 , 1, 3, 22], 36), |
There was a problem hiding this comment.
this dictionary is my workaround for packing a bunch of precomputed complicated expressions -- compare it to the args term in code_metadata.jl to see how it is used
| PutAGoodNameHereAbout2bga = PrettyCodeFamilyWrapper( | ||
| :PutAGoodNameHereAbout2bga, |
There was a problem hiding this comment.
same here, use better more descriptive names
And given some of your other comments, maybe actually split this in two separate wrappers, if they need different description
| PutAGoodNameHereAboutGenBicCodes => Dict( | ||
| :family => [(:C₂₇,), (:C₃₀,), (:C₃₅,), (:C₃₆,), (:C₃₆K₁₀,)], # Subscripts correspond to the structures of the GB codes in table one [lin2024quantum](@cite) # Note K₁₀ was added because of repeated C₃₆ # | ||
| :decoders => [BitFlipDecoder, PyBeliefPropDecoder], | ||
| :setups => [CommutationCheckECCSetup], | ||
| :ecczoo => "https://errorcorrectionzoo.org/c/generalized_bicycle", | ||
| :errrange => (eᵐⁱⁿ, eᵐᵃˣ, steps), | ||
| :description => "The generalized bicycle codes (GBCs) extend the original bicycle codes by using two commuting square n × n binary matrices A and B, satisfying AB + BA = 0. The code is defined using the generator matrices: G_X = (A, B), G_Z = (Bᵀ, Aᵀ)" | ||
| ), | ||
|
|
||
| PutAGoodNameHereAbout2bga => Dict( | ||
| :family => [(:A1, :B1), (:A2, :B2), (:A3, :B3), (:A4, :B4), (:A5, :B5), (:A6, :B6), #TODO add some sort of naming convention to this family other than the same thing that the bivariate group has # | ||
| (:A₇₂, :B₇₂), (:A₁₉₆, :B₁₉₆), (:A₂₈₈, :B₂₈₈), (:A₁₀₈, :B₁₀₈), (:A₃₆₀, :B₃₆₀), (:A₇₅₆, :B₇₅₆)], #TODO the (A,B) cluster goes to the 2BGA group and the other cluster goes to the bivariate group need some way to distinguish those two | ||
| :decoders => [BitFlipDecoder, PyBeliefPropDecoder, PyBeliefPropOSDecoder], | ||
| :setups => [CommutationCheckECCSetup], | ||
| :ecczoo => "https://errorcorrectionzoo.org/c/2bga", | ||
| :errrange => (eᵐⁱⁿ, eᵐᵃˣ, steps), | ||
| :description => "The two-block group algebra (2BGA) codes extend the generalized bicycle (GB) codes by replacing the cyclic group with a general finite group, which can be non-abelian. The stabilizer generator matrices are defined using commuting square matrices derived from elements of a group algebra: H_X = (A, B), H_Z^T = [B; -A] where A and B are commuting ℓ × ℓ matrices, ensuring the CSS orthogonality condition." | ||
| ) |
There was a problem hiding this comment.
after you are done updating the code_wrappers.jl file to use better names, update the corresponding entries here
In particular, be careful to double check that the ecczoo link still make sense and that the descriptions are up-to-date.
In the descriptions, put references to the papers from which these are taken.
| # Put in the 2 block group-algebra codes and generalized_bicycle_codes # | ||
| # Families are from the test files for the individual codes # |
There was a problem hiding this comment.
after the descriptions are updated, these and other comments can be removed; after you are done with these tasks, make sure to remove any stray comments you might have left
| ## ENV variables | ||
|
|
||
| - if `ENV["ECCBENCHWIKI_QUICKCHECK"]!=""` we will run very few samples per code, useful to check for overall correctness |
There was a problem hiding this comment.
note that this is useful to do a quick pass of over the entire database to make sure nothing is broken -- basically it forces the code evaluators to use as minimal as possible number of samples.
You can run it as:
julia> ENV["ECCBENCHWIKI_QUICKCHECK"]="true"; include("wiki_database_passes.jl"); run_evaluations(CodeMetadata.code_metadata;)
If you want to submit an unfinished piece of work in order to get comments and discuss, please mark the pull request as a draft and ping the repository maintainer.
Please address only one topic or issue per pull request! Many small PRs are much easier to review and merge than one large PR.
Before merging, all changes and new functionality should be marked in the CHANGELOG file, but feel free to just leave your CHANGELOG notes in the PR description, to avoid merge conflicts with other requests modifying that file. The maintainer will add these CHANGELOG notes for you if you do so.
Before considering your pull request ready for review and merging make sure that all of the following are completed (please keep the clecklist as part of your PR):
If possible, keep your git history not too wild (rebase and squash commits, keep commits small and semantically separated) so that review is easier.