#19653: New decoders for Generalized Reed-Solomon codes
-------------------------------------+-------------------------------------
Reporter: dlucas | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-7.1
Component: coding theory | Resolution:
Keywords: | Merged in:
Authors: David Lucas | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dlucas/grs_decoders | 8673ac587f4e8bece38fc7027c96eef9771c7eec
Dependencies: #18928, #19897 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by dlucas):
> Damn. It's related to this sick semantics that the parent of a vector is
the subspace. That's also causing trouble in the channels. We should try
to fix that at the root, i.e. experiment with the scaffolding code at
linear code construction time. Didn't Vincent write something about how to
do this in the old sage-devel thread where we discussed the bug?
Ah, in the meanwhile I changed this method to something based on encoding
a random element from the message space of the default encode of a code.
Probably not the best way to do it, I'm aware of that.
I made the other changes, but
> I think the line `R(S.list_from_positions(xrange(0, l0+1)))` can, and
should, be written `R(S[:l0+1])`
which I tried, but it did not work.
--
Ticket URL: <http://trac.sagemath.org/ticket/19653#comment:43>
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.
