#21062: How to store information on codes build from other ones
---------------------------------+------------------------
Reporter: jlavauzelle | Owner:
Type: task | Status: new
Priority: major | Milestone: sage-7.3
Component: coding theory | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
---------------------------------+------------------------
Changes (by jlavauzelle):
* cc: dlucas, jsrn, cpernet (added)
Comment:
If I understand it well, the new coding theory framework aims at keeping
as much information as possible on the (algebraic) structure of the
manipulated codes. I also noticed that this structure is memorized even
after building a new code from older ones (I'll call this a "code
derivation"). For instance, puncturing (resp. extension) is made in a way
that the punctured (resp. extended) code keeps a pointer to the original
code (and this is useful for decoding, or getting bounds on the
parameters).
It's natural to think that in the future, Sage intents to have many other
linear code derivations (dual code, sum, product or intersection of two
codes, concatenation, trace code, subfield subcode, etc.). But I find a
bit messy to define a class for each kind of derivation, especially for
the sum and the dual code (I can't imagine a DualCode or a SumCode class).
If you agree with my feeling (of course it's arguable), maybe it would be
better to instanciate these derivations in a different way.
I propose the following. Let `C` be a derived code (e.g. the dual of the
intersection of two codes). When the user does this derivation, `C` won't
be a `DualCode` object, but an instance of the `LinearCode` class. Now, to
memorize where the derived code comes from, we could add to the
`(Abstract)LinearCode` class:
- an attribute `_derivation_tree` which stores the tree of operations
(the internal nodes of the tree) made on original codes (the leaves of the
tree) in order to get the derived code.
- a method `reduce()`, or `get_structured_representation()`, which
flattens the tree, that is, which builds an instance of a specific family
of code (e.g. `GRS` code) corresponding to the derivation.
For instance, if `C` is the dual code of the intersection of two codes,
then the attribute `_derivation_tree` will store the following tree :
{{{
Dual
|
intersection
| |
C_1 C_2
}}}
and the `reduce()` method will recursively try to give a structure to the
intersection of the two codes and to the dual of the resulting code (if
there is nothing to say, it outputs a `LinearCode` without specific
structure, that is, with an empty tree).
Well, maybe these considerations come a bit early in the development, but
I'll be glad to read your ideas about them.
Julien
--
Ticket URL: <https://trac.sagemath.org/ticket/21062#comment:1>
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.
