#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 | 2115bf45aadf6dcf104031cdcbd86a0787fb9def
Lucas | Stopgaps:
Report Upstream: N/A |
Branch: |
u/dlucas/encoder |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by jsrn):
Cool!
> On comment 6, I don't really get what you suggest. Do you propose to
somehow register the unencoder_matrix and the information_set, for
instance as some kind of class argument after their first computation?
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.
> On comment 9, I can't see what kind of other error can occur when
encoding a word. Either it's an element from the message space and
encoding goes well, either it's not and you get an error as illustrated in
the doctest of `encoder`. Or am I missing something here?
`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).
> On comment 19, I changed the `.. NOTE` block to a `.. WARNING` block to
make this remark even more visible on the doc of `AbstractLinearCode`.
Good idea.
> On comment 24, as `c` is not necessarily a codeword (if `nocheck =
True`, you can provide anything you want, as long as it belongs to the
ambient space), I did not change the `INPUT` line for `c`.
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.
> On comment 26, it's already the case. Maybe you meant "shouldn't include
the word "the" ", but in that case I think the error message would seem a
bit weird imho. I have no strong feelings on this though.
Yes, I meant "shouldn't" :-) It's debatable, I guess, but having "the"
doesn't seem to be convention in Sage:
{{{
sage: MatrixSpace(RR, 2, 3)
Full MatrixSpace of 2 by 3 dense matrices over Real Field with 53 bits of
precision
sage: PolynomialRing(GF(2),'x')
Univariate Polynomial Ring in x over Finite Field of size 2 (using NTL)
sage: Hom(RR, ZZ)
Set of Homomorphisms from Real Field with 53 bits of precision to Integer
Ring
}}}
Furthermore, the `_repr_` doesn't uniquely specify "the" code, but usually
gives a summary. Like for LinearCode or the soon-to-come GRS codes.
Best,
Johan
--
Ticket URL: <http://trac.sagemath.org/ticket/18376#comment:34>
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.
