#18376: New encoding structure for linear codes
-------------------------+-------------------------------------------------
Reporter: | Owner:
dlucas | Status: needs_review
Type: | Milestone: sage-6.9
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers:
coding theory | Work issues:
Keywords: | Commit:
Authors: David | 154cc6f676ebd0f531bba1d6b282f55f246ba180
Lucas | Stopgaps:
Report Upstream: N/A |
Branch: |
u/dlucas/encoder |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by dlucas):
>I'm suggesting that `_unencoder_matrix` returns a tuple consisting of the
matrix and the information set. Then `unencode` can be changed to use that
matrix and information set, which is promised to work together. Right now,
if `code.information_set` returns a different set next time it's called,
then `unencode` will break since it uses the matrix for the first
information set.
Got it! Change done.
>`Encoder.encode` is allowed to be a partial function over its message
space (as explained in `Encoder.message_space`). This is not clear in the
doc string of `Encoder.encode`. Presumably, a special type of error is
supposed to be thrown if one tries to encode a value outside the allowed
portion of the message space (say if I try to encode a polynomial of
degree 2k in a [n,k] GRS code).
Ok. I added a `.. NOTE` block to explain this. And suggested to use
`EncodingError` if one tries to encode a word which is not in the message
space.
>Well, yes, the function won't explode if you give it `c` which is not a
codeword and set `nocheck = True`, but that's *not at all* the intention
of that function, and it's also not the intention of `nocheck = True`.
>The function is undefined - and thus useless - on this input!
>I think that the description of `c` should reflect the intended use of
the function. Not the widest possible type for which the function won't
explode.
Agreed. I changed the doc.
For comment 26, as keeping the "the" is not convention in Sage and as I
stick to the Sage's way of doing things, I deleted it.
Best,
David
--
Ticket URL: <http://trac.sagemath.org/ticket/18376#comment:36>
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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
