#21226 closed enhancement (fixed)
An Abstract Class for Rank Metric Codes
Reported by: | arpitdm | Owned by: | gh-emes4 |
---|---|---|---|
Priority: | major | Milestone: | sage-9.2 |
Component: | coding theory | Keywords: | |
Cc: | dlucas, jsrn, dimpase, caruso, gh-Adurand8, gh-mbombar, vbraun | 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) | 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 rank-metric 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 5 years ago by
- Branch set to u/arpitdm/abstract_linear_rank_metric_code_class
comment:2 Changed 5 years ago by
- Commit set to 7e4b3a3b6fb6b6bcce84f85007b0ae0574f5c37f
comment:3 follow-up: ↓ 4 Changed 5 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 in reply to: ↑ 3 Changed 5 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 rank-metric codes which are linear over the big field!
Best, Johan
comment:5 Changed 5 years ago by
What's the state of this? What is missing? When do you plan to do it?
Best, Johan
comment:6 Changed 5 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 20 months ago by
- Branch changed from u/arpitdm/abstract_linear_rank_metric_code_class to u/gh-emes4/coding/linear_rank_metric
- Commit 7e4b3a3b6fb6b6bcce84f85007b0ae0574f5c37f deleted
- Dependencies set to #28073
- Description modified (diff)
comment:8 Changed 20 months ago by
- Commit set to 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 20 months ago by
- Commit changed from a251c61567015e7159d231a6b828ef617ee5566b to 05476b32a4a94be0d02eba67c9922217ccf7dc9f
Branch pushed to git repo; I updated commit sha1. New commits:
05476b3 | Generator matrix methods in AbstractLinearRankMetricCode
|
comment:10 Changed 20 months ago by
- Owner changed from (none) to gh-emes4
comment:11 Changed 20 months ago by
- Commit changed from 05476b32a4a94be0d02eba67c9922217ccf7dc9f to 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/gh-emes4/coding/linear_rank_metric' of git://trac.sagemath.org/sage into rank_metric
|
comment:12 Changed 20 months ago by
- Cc dimpase added
comment:13 Changed 20 months ago by
- Dependencies changed from #28073 to #28073, #28209
comment:14 Changed 20 months ago by
- Commit changed from 08b6e4f604eb23e53fdb60e7ee724c643b46b125 to 12bb30f72616d49a2755693c73943e0660873b4e
comment:15 Changed 20 months 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 20 months ago by
- Status changed from new to needs_review
comment:17 Changed 19 months ago by
- Commit changed from 12bb30f72616d49a2755693c73943e0660873b4e to 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/gh-emes4/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 19 months ago by
- Dependencies changed from #28073, #28209 to #28073
comment:19 Changed 19 months ago by
- Status changed from needs_review to 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 Hamming-metric 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 matrix-based 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 rank-metric analog of Reed-Solomon 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
well-placed 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 global-scope 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 well-documented 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 matrix-functions 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^{m-1}` 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 global-scope 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 rank-metric 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 doc-test 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 sub-field. 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 rank-metric encoders, and just useLinearCodeGeneratorMatrixEncoder
andLinearCodeSystematicEncoder
(after suitable modifications in their doc and perhaps adding a doc-test 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 19 months 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 19 months ago by
- Dependencies changed from #28073 to #28350
comment:22 Changed 19 months ago by
- Commit changed from 72df923bd65ea122a6b56ef7930e8f07569ecfb9 to 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 19 months ago by
- Status changed from needs_work to 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 19 months ago by
- Commit changed from d4d3e89225c99905740c59610d8fb3c51973ed03 to 1e32a0cadd9fba911695d4a975a06b115abc5adf
Branch pushed to git repo; I updated commit sha1. New commits:
1e32a0c | Super method of LinearRankMetricCode includes basis.
|
comment:25 Changed 19 months ago by
- Commit changed from 1e32a0cadd9fba911695d4a975a06b115abc5adf to 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/gh-emes4/coding/no_metric' of git://trac.sagemath.org/sage into rank_metric
|
0a115d0 | Removed zero method. Added field extension method.
|
comment:26 Changed 18 months ago by
- Cc caruso added
comment:27 Changed 18 months ago by
- Cc gh-Adurand8 added
comment:28 Changed 13 months ago by
- Branch changed from u/gh-emes4/coding/linear_rank_metric to u/caruso/coding/linear_rank_metric
comment:29 Changed 13 months ago by
- Commit changed from 0a115d0f608465d1f59cdd2068add8669df912e7 to 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/gh-emes4/coding/linear_rank_metric' of git://trac.sagemath.org/sage into rank_metric_codes
|
comment:30 Changed 13 months ago by
As I already said on #28350, I'd like to see the work of gh-emes4 merged, and then more hacking can start.
Aside from this, I'm all for more general fields to be possible.
comment:31 Changed 8 months ago by
- Cc gh-mbombar added
comment:32 Changed 8 months ago by
- Branch changed from u/caruso/coding/linear_rank_metric to u/dimpase/coding/linear_rank_metric
- Commit changed from 5ea97acc7b4ab1d9d4d1346872b7b92985cb0e71 to ffb82979425927ee12a53ddb3da9d66a53b473a8
- Reviewers set to Dima Pasechnik
- Status changed from needs_review to positive_review
comment:33 Changed 8 months ago by
comment:34 Changed 8 months ago by
- Reviewers changed from Dima Pasechnik to Dima Pasechnik, Johan Rosenkilde
Awesome!
comment:35 Changed 8 months ago by
- Milestone set to sage-9.2
comment:36 Changed 8 months ago by
- Status changed from positive_review to needs_work
The method sage.coding.linear_code_no_metric.__eq__
misses doctests.
comment:37 Changed 8 months ago by
- Reviewers changed from Dima Pasechnik, Johan Rosenkilde to Dima Pasechnik, Johan Rosenkilde, Xavier Caruso
comment:38 Changed 8 months 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 8 months ago by
- Branch changed from u/dimpase/coding/linear_rank_metric to u/jsrn/coding/linear_rank_metric
comment:40 Changed 8 months ago by
- Commit changed from ffb82979425927ee12a53ddb3da9d66a53b473a8 to 5f46031a26bee3eb4a57c17b611c29c451e45525
- Status changed from needs_work to 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 7 months 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 7 months ago by
Note also that the patchbot reported some warning (pyflakes, pycodestyle and blocks).
comment:43 Changed 7 months ago by
- Status changed from needs_review to 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 7 months ago by
- Status changed from positive_review to 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:45 Changed 7 months ago by
hmm, is \beta
the problem, or \ldots
, or both?
comment:46 Changed 7 months 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 7 months 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 utf-8)
comment:48 Changed 7 months ago by
- Branch changed from u/jsrn/coding/linear_rank_metric to u/dimpase/coding/linear_rank_metric
- Commit changed from 5f46031a26bee3eb4a57c17b611c29c451e45525 to 899d3900180c956773f3d34c53b96483aa95c57f
- Dependencies #28350 deleted
- Status changed from needs_work to positive_review
comment:49 Changed 7 months ago by
- Branch changed from u/dimpase/coding/linear_rank_metric to 899d3900180c956773f3d34c53b96483aa95c57f
- Resolution set to fixed
- Status changed from positive_review to closed
comment:50 Changed 7 months ago by
- Commit 899d3900180c956773f3d34c53b96483aa95c57f deleted
the last commit did not make it into the beta, or got overwritten
comment:51 Changed 7 months ago by
- Cc vbraun added
Volker, something went missing with this merge, e.g. the last commit, 899d390, did not get merged.
comment:52 Changed 7 months ago by
This ticket isn't in any relased beta yet. 899d390018 will be in 9.2.beta7 which I'm releasing right now
comment:53 Changed 7 months ago by
OK - it was confusing that it was marked as closed already.
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.