-
-
Notifications
You must be signed in to change notification settings - Fork 561
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
TestSet Decoder for LinearCodes #21339
Comments
Branch: u/imarquez/groebner-decoder |
Commit: |
Changed branch from u/imarquez/groebner-decoder to u/danielaugot/groebner-decoder |
comment:4
Hi Irene, there was a very minor conflict (traling whitespace) in merging with develop. Daniel New commits:
|
Changed branch from u/danielaugot/groebner-decoder to u/imarquez/groebner-decoder |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:7
I will continue working in the documentation and extra functions in the following days. |
Changed branch from u/imarquez/groebner-decoder to u/mmarco/groebner-decoder |
Changed branch from u/mmarco/groebner-decoder to u/imarquez/groebner-decoder |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:11
New functions have been added: coset_leaders, coset_weight_distribution, covering_radius(without Magma), newton_radius and unique_decoding_radius(). Documentation now is correct |
comment:12
Sorry before is covering_radius (without the optional package of GUAVA) |
comment:13
Hello Irene, I actually implemented a version of We should benchmark your implementation and mine, and keep the fastest one. David |
comment:14
In the _insert_next_fq method, you treat these two different cases:
is it really what you want to do? wouldn't it make sense to just use the first case everywhere? |
comment:15
That whole helper-method can be simplified into an almost-one-liner: all error-vectors of weight 1 can be created as:
Now you want to extend Assuming
Best, |
comment:16
The keyword |
comment:17
Replying to @miguelmarco:
I think the
I think we should not return immutable vectors from coset leaders. The output might be used for further computations by the user and then it will create strange issues, which will be hard to debug. The less surprises we have for the user, the better it is.
This can be done I suppose, just for consistency.
I agree. This is not really a different algorithm. |
comment:18
If you care about the
Just as a quick model you might want to look at this: import collections
def coset_leaders_one(C):
H = C.parity_check_matrix().transpose()
K = C.base_ring()
q = K.cardinality()
def my_generator(v):
t = list(v)
for i, vi in enumerate(v):
if vi: break
for a in K:
if a:
t[i] = a
yield vector(t)
t[i] = 0
def normalize(s):
for si in s:
if si:
return tuple(s / si)
return tuple(s)
z = vector(K, C.length())
sz = normalize(C.syndrome(z))
S = {sz: z}
generators = collections.deque([my_generator(z)])
target_size = (q ** H.ncols() - 1) // (q - 1) + 1
while generators:
g = generators.popleft()
for v in g:
syndrome = normalize(v*H)
if syndrome not in S:
S[syndrome] = v
if len(S) == target_size:
r = [S.pop(sz)]
for s in S.values():
r.extend(a * s for a in K if a)
return r
if not v[0]:
generators.append(my_generator(v)) You can adapt this for the case where you want them all. |
comment:19
You might also look at this implementation: u/ylchapuy/coset_leaders |
comment:20
@sagetrac-ylchapuy Thank you for this implementation. If you have this implementation in a Ticket somewhere please try to get it in first, and make this ticket a dependency of the other one. Your implementation is several hundred times faster than this one. Meanwhile, I have been checking whether the coset leaders returned in your function "match" with the coset leaders returned by the implementation in this ticket. I haven't looked into it in detail, but there is a discrepancy. The discrepancy is not present for all codes though. sage: from coset_1 import coset_leaders_one
sage: from coset_2 import coset_leaders
sage: C = codes.ReedSolomonCode(7,5,GF(8,'a'))
/mnt/usb/Installations/sage/src/bin/sage-ipython:1: DeprecationWarning: codes.Re
edSolomonCode is now deprecated. Please use codes.GeneralizedReedSolomonCode ins
tead.
See http://trac.sagemath.org/18928 for details.
#!/usr/bin/env python
sage: L1 = coset_leaders_one(C)
sage: L2 = coset_leaders(C, "one")
sage: L2_2 = flatten(L2)
sage: L1bool = [False]*len(L1)
sage: L2bool = [False]*len(L2)
sage: Fqstar = C.base_ring().list()[1:]
sage: for i,w in enumerate(L1):
....: wlist = [_*w for _ in Fqstar]
....: for _w in wlist:
....: if _w in L2_2:
....: L1bool[i] = True
....: break
....: for i,v in enumerate(L2_2):
....: vlist = [_*v for _ in Fqstar]
....: for _v in vlist:
....: if _v in L1:
....: L2bool[i] = True
....: break
....:
sage: all(L1bool)
True
sage: all(L2bool)
False
sage: %time L1 = coset_leaders_one(C)
CPU times: user 6.67 ms, sys: 0 ns, total: 6.67 ms
Wall time: 6.02 ms
sage: %time L2 = coset_leaders(C)
CPU times: user 8.43 s, sys: 3.33 ms, total: 8.44 s
Wall time: 8.39 s
sage: len(L1)
64
sage: len(L2)
64
sage: len(L2_2)
64 |
comment:21
Replying to @ppurka:
The ticket where this should be done is #19913 . Sadly I won't have time to do more on this in the foreseeable future, but would be pleased if someone else is motivated enough to integrate this on his own. |
comment:22
And as a side remark, the code in the branch from comment:19 is even much better. 6 time faster on your example code:
and on a some bigger examples
I didn't try with the implementation from here... |
A new version of the ticket #14973 adapted to the new coding Theory framework
CC: @johanrosenkilde @sagetrac-dlucas @sagetrac-danielaugot
Component: coding theory
Keywords: sd75
Author: Irene Márquez-Corbella, Miguel Marco
Branch/Commit: u/imarquez/groebner-decoder @
76b83d7
Issue created by migration from https://trac.sagemath.org/ticket/21339
The text was updated successfully, but these errors were encountered: