#21226 closed enhancement (fixed)
An Abstract Class for Rank Metric Codes
Reported by:  Arpit Merchant  Owned by:  ghemes4 

Priority:  major  Milestone:  sage9.2 
Component:  coding theory  Keywords:  
Cc:  David Lucas, Johan Rosenkilde, Dima Pasechnik, Xavier Caruso, Durand Amaury, Maxime Bombar, Volker Braun  Merged in:  
Authors:  Arpit Merchant, Marketa Slukova, Johan Rosenkilde  Reviewers:  Dima Pasechnik, Johan Rosenkilde, Xavier Caruso 
Report Upstream:  N/A  Work issues:  
Branch:  899d390 (Commits, GitHub, GitLab)  Commit:  
Dependencies:  Stopgaps: 
Description (last modified by )
We propose to implement AbstractRankMetricCode
, an abstract class for rank metric codes which will initialize the basic parameters that every rank metric code possesses. This will inherit from AbstractCode
class. Further, we propose to add rankmetric based methods to compute distance, weight and allow for matrix to vector (and reverse) conversions between representations. Finally, we create a generic representative class LinearRankMetricCode
as well as encoding (generator matrix, systematic) and decoding (nearest neighbour) methods.
Change History (53)
comment:1 Changed 6 years ago by
Branch:  → u/arpitdm/abstract_linear_rank_metric_code_class 

comment:2 Changed 6 years ago by
Commit:  → 7e4b3a3b6fb6b6bcce84f85007b0ae0574f5c37f 

comment:3 followup: 4 Changed 6 years ago by
Hello,
I won't comment extensively for now, as there's still a lot to do. I just have one small comment/remark to keep in mind for later: when you will work on documentation, remember to carefully explain which representation you chose (matrix vs. vector) and how to get the other one to be sure users do understand how this class works and what they should expect from it.
David
comment:4 Changed 6 years ago by
Replying to dlucas:
Hello,
I won't comment extensively for now, as there's still a lot to do. I just have one small comment/remark to keep in mind for later: when you will work on documentation, remember to carefully explain which representation you chose (matrix vs. vector) and how to get the other one to be sure users do understand how this class works and what they should expect from it.
Seconded. And remember to explain that this class *only* supports rankmetric codes which are linear over the big field!
Best, Johan
comment:5 Changed 6 years ago by
What's the state of this? What is missing? When do you plan to do it?
Best, Johan
comment:6 Changed 6 years ago by
I think the class should be call AbstractLinearRankMetricCode
by the way. It's terribly long, but the Linear
is important.
comment:7 Changed 3 years ago by
Authors:  Arpit Merchant → Arpit Merchant, Marketa Slukova 

Branch:  u/arpitdm/abstract_linear_rank_metric_code_class → u/ghemes4/coding/linear_rank_metric 
Commit:  7e4b3a3b6fb6b6bcce84f85007b0ae0574f5c37f 
Dependencies:  → #28073 
Description:  modified (diff) 
comment:8 Changed 3 years ago by
Commit:  → a251c61567015e7159d231a6b828ef617ee5566b 

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
64f446a  Merge branch 'develop' of git://trac.sagemath.org/sage into abstract_code

53e445b  added base_ring and length parameter to AbstractCode

5e6dffe  Fixed some dependencies. Category still set up wrong.

ba4fc53  Merge branch 'abstract_code' into t/28073/abstract_code

e8edfeb  Fixed unclean merge.

880aebb  Fixed default decoder/encoder dependencies. Set to None by default.

d115600  No category set up and base_field in AbstractCode. No encoder/decoder error msgs. Documentation and tests.

82fdc3c  Merge branch 'develop' of git://trac.sagemath.org/sage into rank_metric

5c0fd69  Merge branch 'develop' of git://trac.sagemath.org/sage into rank_metric

a251c61  Inheriting from Abstract Code. Encoding, decoding methods. Generic LinearRankMetricCode class.

comment:9 Changed 3 years ago by
Commit:  a251c61567015e7159d231a6b828ef617ee5566b → 05476b32a4a94be0d02eba67c9922217ccf7dc9f 

Branch pushed to git repo; I updated commit sha1. New commits:
05476b3  Generator matrix methods in AbstractLinearRankMetricCode

comment:10 Changed 3 years ago by
Owner:  set to ghemes4 

comment:11 Changed 3 years ago by
Commit:  05476b32a4a94be0d02eba67c9922217ccf7dc9f → 08b6e4f604eb23e53fdb60e7ee724c643b46b125 

Branch pushed to git repo; I updated commit sha1. New commits:
524efc8  Inheriting from Abstract Code. Encoding, decoding methods. Generic LinearRankMetricCode class.

77fc1e2  Generator matrix methods in AbstractLinearRankMetricCode

08b6e4f  Merge branch 'u/ghemes4/coding/linear_rank_metric' of git://trac.sagemath.org/sage into rank_metric

comment:12 Changed 3 years ago by
Cc:  Dima Pasechnik added 

comment:13 Changed 3 years ago by
Dependencies:  #28073 → #28073, #28209 

comment:14 Changed 3 years ago by
Commit:  08b6e4f604eb23e53fdb60e7ee724c643b46b125 → 12bb30f72616d49a2755693c73943e0660873b4e 

comment:15 Changed 3 years ago by
Finished up everything and added documentation and doc tests. Few notes:
I kept the parameter requirement that the length of the code has to be at most the degree of the extension.
I didn't manage to turn off the experimental warning, except for handling it in doc tests.
I will add a doctest for the method decode_to_code
when Gabidulin codes are in place.
There is no test for linearity over the big field and also no test for the finite field extension in the initialising parameters of AbstractLinearRankMetricCode
.
I also added a very slow algorithm for computing the minimum distance.
comment:16 Changed 3 years ago by
Status:  new → needs_review 

comment:17 Changed 3 years ago by
Commit:  12bb30f72616d49a2755693c73943e0660873b4e → 72df923bd65ea122a6b56ef7930e8f07569ecfb9 

Branch pushed to git repo; I updated commit sha1. New commits:
2bf73f8  Merge branch 'develop' of git://trac.sagemath.org/sage into t/28073/abstract_code

487e9e2  Category related methods added. Encoder/decoder documentation specified for linear codes.

40df01e  Finished up documentation.

b7cab95  Merge branch 'u/ghemes4/coding/abstract_code' of git://trac.sagemath.org/sage into rank_metric

25ca9b7  Merge branch 'develop' of git://trac.sagemath.org/sage into rank_metric

72df923  Documentation tree link and fixes. Updated Sage.

comment:18 Changed 3 years ago by
Dependencies:  #28073, #28209 → #28073 

comment:19 Changed 3 years ago by
Status:  needs_review → needs_work 

This looks very good! Though my list of comments below is long, I think that this first stab at the class is very good work :)
In the module doc of linear_rank_metric
:
 Add the following paragraphs:
This module allows representing rank metric codes which are linear over the big field `F_{q^m}`, i.e. the usual linearity condition when the codewords are considered in vector form. One can also consider rank metric codes which are only linear over `F_q`, but these are not currently supported in SageMath. Note that linear rank metric codes per the definition of this file are mathematically just linear block codes, and so could be considered as a :class:`sage.coding.linear_code.LinearCode`. However, since most of the functionality of that class is specific to the Hamming metric, the two notions are implemented as entirely different in SageMath. If you wish to investigate Hammingmetric properties of a linear rank metric code ``C``, you can easily convert it by calling ``C_hamm = LinearCode(C.generator_matrix())``.
 Remove the sentence "One of the main uses ...". This is subjective and very much subject to change :) Further, the main thrust of rank metric codes in the last 15 years are their applications in network coding, and not crypto.
 "The class
(...).LinearRankMetricCode
is a representative of ...". Perhaps this sentence should be something like
"The class
(...).LinearRankMetricCode
is the analog of(...).LinearCode
, i.e. it is a generator matrixbased representation of a linear rank metric code without specific knowledge on the structure of the code.
 "Gabidulin codes are ... studied at the moment". Just remove "studied at the moment". The sentence after could be reformulated to "These codes are the rankmetric analog of ReedSolomon codes".
 The headline
AbstractLinearCode
should beAbstractLinearRankMetricCode
.
 "However, using the encoder/decoder framework requires the vector
representation of codewords". This caveat is important but perhaps not
wellplaced here. I think I'd rather like to see it in the class doc of
AbstractLinearRankMetricCode
during a complete example of how to implement a code class.
 "so any linear code rank metric" > "so any linear rank metric code".
 Under Further references, I think the link to Wikipedia should be a proper citation inserted into the citation file, see http://doc.sagemath.org/html/en/developer/coding_basics.html
Dima, what do you say?
About the to/from matrix repr:
 The class
RelativeFiniteFieldExtension
does a lot of computation the first time it is used (inverting anm * m
matrix) and the result is then cached. Your two functions throw away theRelativeFiniteFieldExtension
object each time they are called. You need to somehow cache that object between invocations of the function having the same base field and sub field.
One solution is to drop your globalscope functions and only have them inside
AbstractLinearRankMetricCode
. Then theRelativeFiniteFieldExtension
object can be placed as a private field of the code object after the first time it is used. In fact, I see now that you allow the user to supply thefield_extension
(which should be aRelativeFiniteFieldExtension
object) but you don't use it!
The downside is that it does make sense to have those functions outside the class. By using the @cached_method decorator or one of its friends, you might be able to more or less manually indicate that the
RelativeFiniteFieldExtension
object should be cached between invocations
to_matrix_representation
doesn't really needbase_field
since this is just the base field ofv
. Perhaps the argument order should be `v, sub_field=None, and if
sub_field` is not set, then the prime field is just assumed.
A similar thing holds for
from_matrix_representation
: here we need neither thesub_field
nor thebase_field
. However, thebase_field
should be possible to supply in case the user has constructed the big field using a specific irreducible polynomial, say.
For
rank_weight
andrank_distance
, we should use the same signature asto_matrix_representation
.
Note that both of these functions are severely limited in that they do not allow the user to select the basis of
GF(q^m)/GF(q)
. This is of course due to exactly that limitation inRelativeFiniteFieldExtension
, so it's not your fault, but it should be documented somewhere. This is not welldocumented inRelativeFiniteFieldExtension
either, I realise. Perhaps you could add the following paragraph to the class doc ofRelativeFiniteFieldExtension
, together with some shorter description of the same in your to/from matrixfunctions along with a reference to the doc ofRelativeFiniteFieldExtension
:
This class currently does not support choosing an arbitrary basis of `F_{q^m}` over `F_q`, but instead uses the following: if `q = p^s`, then let `1,\beta,\ldots,\beta^{sm}` be the power basis that SageMath uses to represent `F_{q^m}`. Then `1,\beta,\ldots,beta^{m1}` is a basis of `F_{q^m}` over `F_q`. This class uses that basis.
 The conformal checks in
rank_distance
should be before theto_matrix_representation
calls. (the number of columns is the length ofa
andb
and the number of rows is taken care of by the check onbase_ring
.
 You are missing INPUT blocks to many functions, in particular all the globalscope matrix functions.
In AbstractLinearRankMetricCode
:
 Class doc: "The current implementation (...) supports only the vector representation. This means that to use the encoder/decoder framework. one has to work with vectors". Let's shorten that instead as something like:
"This implementation principally uses the vector representation."
Most users wouldn't care about the technical detail of "the encoder/decoder framework". That's just stuff that should work :) Using the vector form is also a perfectly natural choice (and another would be to principally use the matrix form), and I don't think we really have to argue about it.
I'm OK with your "Instructions on how ..." block, but add also a reference to the
__init__
doc which actually contains an example forAbstractLinearRankMetricCode
.
 I think we should apply the same convention as in
(Abstract)LinearCode
, that a subclass ofAbstractLinearRankMetricCode
must supply a generator matrix. Then__iter__
and__hash__
can be defined onAbstractLinearRankMetricCode
.
This also means we don't have to override
__iter__
it in the examples.
This would be conformed to anyway by the refactor with
AbstractLinearCodeNoMetric
I suggest below.
 The
MyRankMetricCode
example is basically a stripped version ofLinearRankMetricCode
. Perhaps we should make it into an easy specific family, e.g.
sage: from sage.coding.linear_rank_metric import AbstractLinearRankMetricCode sage: class RankRepetitionCode(AbstractLinearRankMetricCode): ....: def __init__(self, base_field, sub_field, length): ....: sage.coding.linear_rank_metric.AbstractLinearRankMetricCode.__init__(self, base_field, sub_field, length, 1, "GeneratorMatrix", "NearestNeighbor") ....: beta = base_field.gen() ....: self._generator_matrix = matrix(base_field, [[ beta^i for i in range(length) ]]) ....: def generator_matrix(self): ....: return self._generator_matrix ....: def _repr_(self): ....: return "[%d, %d] my rankmetric repetition code over GF(%s)" % (self.length(), self.dimension(), self.base_field().cardinality())
Note that I didn't test this code. As long as `length <= base_field/sub_field
then this code should have minimum rank distance
length`.
 Currently the method
field_extension()
returnsNone
when the user didn't supply a specificfield_extension
. In the refactor of this issue mentioned above, make sure that this method always makes sense.
 In the doc of
extension_degree
you could add the sentence "This is also the number of rows in the matrix form of a codeword ofself
.".
 Some method rename suggestions:
distance > rank_distance_between_vectors weight > rank_weight_of_vector to_matrix > matrix_form_of_vector from_matrix > vector_form_of_matrix
All their docs are sorely missing INPUT blocks.
 The question is whether
minimum_distance
should be calledminimum_rank_distance
? I'm torn between disliking the redundancy but liking the "explicit is better than implicit". Dima, what's your opinion?
 In
minimum_distance
, usesage.rings.infinity.infinity
(possibly with capital letter?) instead offloat('inf')
.
 In docs: "code word" > "codeword".
 There's after all a fair amount of code duplication with
AbstractLinearCode
I'm thinking that we should make a classAbstractLinearCodeNoMetric
which contains the methods:
`ambient_space`, `base_field`, `basis`, `dimension`, `generator_matrix`, `parity_check_matrix`, `syndrome`, `__contains__`, `information_set`, `is_information_set`, `dual_code`, `__getitem__`, `systematic_generator_matrix`, `gens`, `__iter__`, `is_permutation_automorphism`, `is_self_dual`, `is_self_orthogonal`, `is_subcode`, `cardinality`, `permuted_code`, `rate`, `redundancy_matrix, `standard_form`, `__hash__`
Not only is this a lot of saved copied code, it also adds a lot of service to the current proposed rank metric codes!
This could inherit from
AbstractCode
, and bothAbstractLinearCode
andAbstractLinearRankMetricCode
inherits fromAbstractLinearCodeNoMetric
.
To properly test these methods both for linear codes and linear rank metric codes, perhaps we should add a
_test_abstractcode_methods
function in `AbstractLinearCodeNoMetric? that can then be run in a doctest for bothLinearCode
andLinearRankMetricCode
usingTestSuite
(see the documentation forTestSuite
to know what I mean). A test at this level of abstraction would often be nothing but calling the method and making sure it doesn't throw an exception, but a few of them could be slightly more interesting (like C.dual().dual() == C).
 We should follow the same convention as in
AbstractLinearCode
that the dimension is not given at construction time. For some codes it can be expensive to determine the dimension, e.g. for algebraic geometry codes. When designing these classes we were very careful that you don't pay for what you don't use, so construction is usually cheap, and then you pay only when calling whatever methods. Note that if you introduceAbstractLinearCodeNoMetric
as suggested above, then we have to follow this convention anyway.
In LinearRankMetricCode
:
 The reason the
__init__
argumentgenerator
is not calledgenerator_matrix
is that we also accept e.g. a code or a vector space. That's why we have the complicatedtry...except
block. Please fix the INPUT doc.
 Perhaps the order of arguments should be
__init__(generator_matrix, sub_field)
andsub_field
could be optional, defaulting to the prime field ofbase_field
.
 In
_repr_
and_latex_
we should include the subfield. So perhaps the printing should be something like:
[3, 2] linear rank metric code over GF(64)/GF(4)
 After introducing
AbstractLinearCodeNoMetric
perhaps we can completely avoid the two special rankmetric encoders, and just useLinearCodeGeneratorMatrixEncoder
andLinearCodeSystematicEncoder
(after suitable modifications in their doc and perhaps adding a doctest where they are invoked with aLinearRankMetricCode
.). I think this will work, but I'm not completely sure.
 In
LinearRankMetricCodeNearestNeighborDecoder.decode_to_code
, you could benefit from introducingC = self.code()
.
comment:20 Changed 3 years ago by
Concerning my text added to the module doc, one can actually convert to a linear code simply by doing C_hamm = LinearCode(C)
.
comment:21 Changed 3 years ago by
Dependencies:  #28073 → #28350 

comment:22 Changed 3 years ago by
Commit:  72df923bd65ea122a6b56ef7930e8f07569ecfb9 → d4d3e89225c99905740c59610d8fb3c51973ed03 

Branch pushed to git repo; I updated commit sha1. Last 10 new commits:
ef7b797  Merge branch 'develop' of git://trac.sagemath.org/sage into t/28073/abstract_code

9608a23  Documentation and example fixes.

5230b19  Merge #27634

318b444  Module inheritance. Ambient_space and __call__ changes.

3996761  Merge commit '8b01cc5df9e1508250976b08b4d2212aecb02927' of git://trac.sagemath.org/sage into t/28073/abstract_code

a4582a3  Merge branch 'develop' of git://trac.sagemath.org/sage into t/28073/abstract_code

4dbc878  documentation fix

45cf76e  Class linear_code_no_metric. Moved stuff from linear_code.

f7d9438  Merge in 28350, Linear Code No Metric

d4d3e89  No Metric changes. Removed Relative Finite Field Extension, added vector_space method and basis option. Doctests and documentation. Deleted rank metric specific encoders.

comment:23 Changed 3 years ago by
Status:  needs_work → needs_review 

I made all the changes in Johan's comment.
Also merged in Linear Code No Metric and deleted the duplicate stuff.
I removed Relative Finite Field Extension and replaced it with vector_space
method, which also allows the user to choose a basis, which is now an initialising parameter for AbstractLinearRankMetricCode
and LinearRankMetricCode
. I just noticed that I forgot to add the basis
parameter in the Super
method of LinearRankMetricCode
, will fix that now.
I ran make ptestlong
and there were no errors.
comment:24 Changed 3 years ago by
Commit:  d4d3e89225c99905740c59610d8fb3c51973ed03 → 1e32a0cadd9fba911695d4a975a06b115abc5adf 

Branch pushed to git repo; I updated commit sha1. New commits:
1e32a0c  Super method of LinearRankMetricCode includes basis.

comment:25 Changed 3 years ago by
Commit:  1e32a0cadd9fba911695d4a975a06b115abc5adf → 0a115d0f608465d1f59cdd2068add8669df912e7 

Branch pushed to git repo; I updated commit sha1. New commits:
3917048  Merge branch 'develop' of git://trac.sagemath.org/sage into rank_metric

01d9a3d  Merge branch 'develop' of git://trac.sagemath.org/sage into t/28350/abstract_linear_code_no_metric_class

226ffbf  Added no metric to coding documentation index. Moved zero method from AbstractLinearCode. Changed base_field check.

bd31704  Merge branch 'u/ghemes4/coding/no_metric' of git://trac.sagemath.org/sage into rank_metric

0a115d0  Removed zero method. Added field extension method.

comment:26 Changed 3 years ago by
Cc:  Xavier Caruso added 

comment:27 Changed 3 years ago by
Cc:  Durand Amaury added 

comment:28 Changed 3 years ago by
Branch:  u/ghemes4/coding/linear_rank_metric → u/caruso/coding/linear_rank_metric 

comment:29 Changed 3 years ago by
Commit:  0a115d0f608465d1f59cdd2068add8669df912e7 → 5ea97acc7b4ab1d9d4d1346872b7b92985cb0e71 

I merged with sage 9.1.beta2.
Let me also point out that #21413 (about general field extensions) is now merged. I think it would be nice to rely on it in order to allow for more general fields than finite fields. Any thoughts?
New commits:
d49390e  merged version 9.1.beta1

80ff011  Add function hash

dbaaaa1  Merge branch 'develop' into t/28350/coding/no_metric

5ea97ac  Merge branch 'u/ghemes4/coding/linear_rank_metric' of git://trac.sagemath.org/sage into rank_metric_codes

comment:30 Changed 3 years ago by
As I already said on #28350, I'd like to see the work of ghemes4 merged, and then more hacking can start.
Aside from this, I'm all for more general fields to be possible.
comment:31 Changed 2 years ago by
Cc:  Maxime Bombar added 

comment:32 Changed 2 years ago by
Branch:  u/caruso/coding/linear_rank_metric → u/dimpase/coding/linear_rank_metric 

Commit:  5ea97acc7b4ab1d9d4d1346872b7b92985cb0e71 → ffb82979425927ee12a53ddb3da9d66a53b473a8 
Reviewers:  → Dima Pasechnik 
Status:  needs_review → positive_review 
comment:33 Changed 2 years ago by
Authors:  Arpit Merchant, Marketa Slukova → Arpit Merchant, Marketa Slukova, Xavier Caruso 

comment:34 Changed 2 years ago by
Reviewers:  Dima Pasechnik → Dima Pasechnik, Johan Rosenkilde 

Awesome!
comment:35 Changed 2 years ago by
Milestone:  → sage9.2 

comment:36 Changed 2 years ago by
Status:  positive_review → needs_work 

The method sage.coding.linear_code_no_metric.__eq__
misses doctests.
comment:37 Changed 2 years ago by
Authors:  Arpit Merchant, Marketa Slukova, Xavier Caruso → Arpit Merchant, Marketa Slukova 

Reviewers:  Dima Pasechnik, Johan Rosenkilde → Dima Pasechnik, Johan Rosenkilde, Xavier Caruso 
comment:38 Changed 2 years ago by
The __eq__
method is also incorrect: two codes (= vector spaces) may be equal though their generator matrices are not. I'm fixing this.
comment:39 Changed 2 years ago by
Branch:  u/dimpase/coding/linear_rank_metric → u/jsrn/coding/linear_rank_metric 

comment:40 Changed 2 years ago by
Authors:  Arpit Merchant, Marketa Slukova → Arpit Merchant, Marketa Slukova, Johan Rosenkilde 

Commit:  ffb82979425927ee12a53ddb3da9d66a53b473a8 → 5f46031a26bee3eb4a57c17b611c29c451e45525 
Status:  needs_work → needs_review 
I've fixed the issue with __eq__
by implementing and documenting a correct version. Then sage.coding.linear_code.AbstractLinearCode
had a redundant (and less efficient) implementation of __eq__
that I removed. I also moved __ne__
from that class to AbstractLinearCodeNoMetric
.
Using ./sage coverage
, I found that linear_rank_code
had another method decode_to_code
with no doctests. I added one. I discovered then that two other doctests of that file were running very slowly (>10 s), so I just changed the tests to a smaller ones which runs much faster.
New commits:
150d834  Example for coding.linear_code_no_metric.__init__

5f32a03  Merge branch 'u/dimpase/coding/linear_rank_metric' of git://trac.sagemath.org/sage into 21226_abstract_rank_metric

4a770f8  Fix __eq__ and __ne__ for AbstractLinearCodeNoMetric, and remove it from AbstractLinearCode

9ef1e9c  Add doctest to coding.linear_rank_metric.LinearRankMetricCodeNearestNeighborDecoder.decode_to_code

5f46031  Make doctests of sage.coding.linear_rank_metric run 50 times faster

comment:41 Changed 2 years ago by
Thanks.
Since I haven't really looked into the code of this ticket, I let Dima give again a positive review if appropriate.
Btw, I'm wondering: is it preferable to implement __eq__
, __ne__
, etc. or _richcmp_
? I believed that the latter solution was better, but I'm not sure.
comment:42 Changed 2 years ago by
Note also that the patchbot reported some warning (pyflakes, pycodestyle and blocks).
comment:43 Changed 2 years ago by
Status:  needs_review → positive_review 

Thanks. First time I missed the _eq_ problem, as I thought it's just some kind of Python3 formality. Looks OK now.
comment:44 Changed 2 years ago by
Status:  positive_review → needs_work 

PDF docs don't build:
[docpdf] l.4668 \(1,^^H [docpdf] eta,\ldots,^^Heta^{sm}\) be the power basis that SageMath uses to
comment:46 Changed 2 years ago by
I'm not 100% sure but I think it comes from \beta
. However, I don't know what's wrong.
Besides, reading this doctest, I find that it's not very clear; for instance, what is q
is implicit and not obvious, I would say. Moreover, the two notations GF(q)
and F_{q}
are used to refer to the same object (namely, the finite field with q elements) and I think that they are both incorrect, the correct one being \GF(q)
.
comment:47 Changed 2 years ago by
by the way, there are typos  beta vs \beta in 6 places.
Perhaps \beta must be added to some silly list... (and/or written in utf8)
comment:48 Changed 2 years ago by
Branch:  u/jsrn/coding/linear_rank_metric → u/dimpase/coding/linear_rank_metric 

Commit:  5f46031a26bee3eb4a57c17b611c29c451e45525 → 899d3900180c956773f3d34c53b96483aa95c57f 
Dependencies:  #28350 
Status:  needs_work → positive_review 
comment:49 Changed 2 years ago by
Branch:  u/dimpase/coding/linear_rank_metric → 899d3900180c956773f3d34c53b96483aa95c57f 

Resolution:  → fixed 
Status:  positive_review → closed 
comment:50 Changed 2 years ago by
Commit:  899d3900180c956773f3d34c53b96483aa95c57f 

the last commit did not make it into the beta, or got overwritten
comment:51 Changed 2 years ago by
Cc:  Volker Braun added 

Volker, something went missing with this merge, e.g. the last commit, 899d390, did not get merged.
comment:52 Changed 2 years ago by
This ticket isn't in any relased beta yet. 899d390018 will be in 9.2.beta7 which I'm releasing right now
More to follow.
New commits:
added a very basic constructor, a couple of basic getter methods and deleted a couple of methods from ALC class. added some rank distance, rank weight, to_matrix_representation and from_matrix_representation.