-
Notifications
You must be signed in to change notification settings - Fork 11
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
Brouwer #46
Conversation
@@ -663,7 +663,6 @@ end | |||
Return whether or not `v` is a codeword of `C`. | |||
""" | |||
in(v::Union{CTMatrixTypes, Vector{Int}}, C::AbstractLinearCode) = iszero(syndrome(C, v)) | |||
∈(v::Union{CTMatrixTypes, Vector{Int}}, C::AbstractLinearCode) = iszero(syndrome(C, v)) |
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.
the repetition of in
causes a precompile error. Probably its there because of a merge error so I deleted one of them
rank and v have are in one-to-one correspondance and we can go between them with the functions | ||
_subset_unrank and _subset_rank. | ||
|
||
inds: an int array of length 3. It represents the indexs of w that were changed when updating |
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 iterator has maximum distance 2 meaning that at most 2 entries of the current v
are different from the previous v.
This means inds
will end each iteration holding at most 2 positive values.
The reason inds
has length 3 is each iteration changes the indexs of v
in two positions. Each change corresponds to one 'addition' and one 'subtraction' (but we're over F2 so those ops are the same). During the second change inds
sometimes has 3 positive values temporarily.
end | ||
|
||
function _update_indexs!(indexs::Vector{Int}, x::Int) | ||
if x == indexs[1] |
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.
the update we're doing here corresponds to binary addition at the index x
. If x
is already set in indexs
this corresponds to two binary additions. These cancel out so we remove x
from indexs
end | ||
end | ||
|
||
struct GrayCode |
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.
The rest of this file is the old GrayCode. I did not change anything except for adding one reference to the paper the algorithm was initially based on
@testset "SubsetGrayCode iterates over all weight k subsets of {1,..,n}" begin | ||
len = 15 | ||
weight = 7 | ||
sgc = CodingTheory.SubsetGrayCode(len, weight) |
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.
to keep SubsetGrayCode
simpler I did not add a mutate keyword. I could not see a need for it because if we need a collection of all subsets we can use subsets()
from Hecke
(its faster)
This PR adds a new iterator
SubsetGrayCode
that has useful features vs. the existingGrayCode
iterator.The reasons for using
SubsetGrayCode
are-so we iterate over the indexs of a binary vector that have changed rather than the entire vector
-so we can use rank/unrank functions
Respectively, these will let us speed up Brouwer's algorithm by eliminating matrix muls, and for multithreading will let us equalize the number of vectors visited per thread.
As a sanity check on the new iterator I benchmarked both iterators to make sure performance is in the same ballpark on a simple loop. Specifically, I tested with length=25, weight=12 which has about 5 million entries. I found they were close: GrayCode is slightly faster and SubsetGrayCode uses slightly less memory.
SubsetGrayCode:
GrayCode: