#18099: Prepare linear_code for inheritance
-------------------------------------+-------------------------------------
Reporter: dlucas | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.6
Component: coding theory | Resolution:
Keywords: sd66 | Merged in:
Authors: David Lucas | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dlucas/prepare_linear_code_for_inheritance|
8905552948a0896a46e587815cce539b6e60aae9
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Description changed by dlucas:
Old description:
> For now, every family of linear code (eg: Hamming code) is a method which
> returns a `LinearCode` object. It would be nice to change this: every
> family of code should be an object.
>
> LinearCode's need to be initialised with some magic incantations for them
> to work as modules and in the category framework. This needs to be called
> by all sub-classes as well, and could be achieved by creating an abstract
> linear code class.
>
> Several private fields are also being set in the constructor which need
> to be set by all sub-classes. To avoid that subclasses need to know the
> name of these private fields (they should be accessed through public
> getters), we can instead set them using the abstract class constructor as
> well.
>
> So, every sub-family of linear will only need to inherit from the
> abstract class.
>
> Besides, a linear code gets his `base_field` using the `base_ring()`
> method coming from its category. Linear codes should have their own
> method to do that.
New description:
For now, every family of linear code (eg: Hamming code) is a method which
returns a `LinearCode` object. It would be nice to change this: every
family of code should be an object.
Besides, every linear codes needs to know its generator matrix to be
constructed. This is fine for linear codes without a specific algebraic
structure, but not for sub-families of linear codes.
For instance, it is possible to encode & decode words in Reed-Solomon
codes without the help of a generator matrix. With regards to this, the
user should be free to build the generator matrix for sub-families of code
(which can be both a time- and memory-consuming operation).
This is also true for the dimension of a code (which can be long to
compute for some sub-families).
However, some parameters (like the length of the code, or its base field)
are mandatory to every linear code, and subfamilies. They need to work
fine with the category framework as well.
We then propose the following design:
implement an abstract class , `AbstractLinearCode`, which will initialize
parameters used in every linear code, and make linear codes properly
interact as modules in the category framework in its constructor. Besides,
as all methods that were previously in linear codes need to work for all
subfamilies of codes, we propose to relocate them as methods of
`AbtractLinearCode`. With this design, every linear code and subfamily
will only need to inherit from this abstract class to get all the generic
methods and parameters initialized.
--
--
Ticket URL: <http://trac.sagemath.org/ticket/18099#comment:19>
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.
