#20705: Classes for Reed Muller Codes
-------------------------------------+-------------------------------------
Reporter: panda314 | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-7.3
Component: coding theory | Resolution:
Keywords: | Merged in:
Authors: Parthasarathi | Reviewers: David Lucas
Panda | Work issues:
Report Upstream: N/A | Commit:
Branch: | 13cda90026b28644ed1c018d7628ea1e007cd4ef
u/dlucas/classes_for_reed_muller_codes| Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by panda314):
Replying to [comment:34 jsrn]:
No problem with comments :) . Will work on them. Some doubts/explanation.
1. Well i guess they are so because of the length of line restrictions and
the automated formatter did everything 'strictly'. 249--255 is indeed ugly
will change that. 70--75 seems fine though.
2. Oh. I guess i will remove the linear_code.py path and use '//' instead
of '/' in binomial sum. Might be faster too because of integer divisions
instead of rational numbers.
21. Isn't it sum upto 'k' that we need?
22. Directly iterating involves enumeration over the subset redundantly if
i am not mistaken. Used the iterator to do the generation in one scan.
24. So given the term prod!^m_{i=1} x!^(d_i)_i, exponent is the set
{!{1}*d_1 {2}*d_2 ...{m}*d_m}. In which case i believe that the generator
matrix is correct (it matches with polynomial evaluation).
Will use the prod function instead.
Well everything else makes sense. Will implement them :)
> 22. In `ReedMullerVectorEncoder.generator_matrix`, you should iterate
directly over `exponents`: `for exponent in exponents: ...`.
> 1. In `ReedMullerVectorEncoder.generator_matrix` and other places,
perhaps `base_field_tuple` should simply be called `points`.
> 1. There should be a method to get the list of points used for
evaluation.
> 1. I don't think `ReedMullerVectorEncoder.generator_matrix` is correct:
you are indexing in the point `x` using `exponent`. But you *should* be
computing `prod_{i=1}^m x[i]^exponent[i]`. Using `reduce(mul,...)` in this
instance is less clear than using `prod(...)`.
> 1. In doc for `ReedMullerPolynomialEncoder` it says "polynomial field",
but it should be "polynomial ring". It should say that `polynomial_ring`
is optional.
> 1. Copy-paste error: it says something about `If code is not GRS code
...`.
> 1. The polynomial in the example of `ReedMullerPolynomialEncoder.encode`
is badly formatted.
> 1. The failing example of `ReedMullerPolynomialEncoder.encode` with poly
of too high degree could be with a poly where each variable has OK degree,
but the total degree is bad, e.g. `x0^2*x1`.
>
> Otherwise, good job! Don't worry about the volume of my comments. David
has fond memories of tickets where I similarly put him through the wringer
;-)
>
> Best,
> Johan
--
Ticket URL: <http://trac.sagemath.org/ticket/20705#comment:35>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
