Changes between Version 13 and Version 19 of Ticket #18099


Ignore:
Timestamp:
04/07/15 11:22:12 (7 years ago)
Author:
dlucas
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #18099 – Description

    v13 v19  
    1 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.
     1For 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.
     2Besides, 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.
     3For 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).
     4This is also true for the dimension of a code (which can be long to compute for some sub-families).
    25
    3 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.
     6However, 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.
    47
    5 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.
     8We then propose the following design:
    69
    7 So, every sub-family of linear will only need to inherit from the abstract class.
    8 
    9 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. 
     10implement 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.
     11