Rename parameters of codes from coding_test
Issue #18
resolved
I noticed that all the functions from coding_test (e.g. functions inside grs_decoders.py) call directly code.n or code.k instead of using helper functions. Plus, n or k should be renamed properly, like _dimension or _length.
One question : do you think it's a good idea to create helper function for every parameter?
For grs, it will mean 5 helper functions : space()
, column_multipliers()
, evaluation_points()
, length()
and dimension()
.
It's of course way more elegant, but also heavier.
Comments (3)
-
-
reporter I definitely agree with you, just wanted to confirm my intuition :)
-
- changed status to resolved
deprecated
- Log in to comment
dimension()
etc. surely needs to be there. Users will access them.Whether some method inside the GRS-class uses a private field
_dimension
, or callsself.dimension()
is to some degree up to taste and our expectations of use, I guess.LinearCode
is a base class for everything else, for instance, so we don't want to depend on private fields anywhere: if we did so, those functions would not work if we sub-classedLinearCode
in a way that didn't have that field. For instance, it takes work to calculate the correct dimension of a Goppa code, so we don't want to set a field_dimension
for Goppa codes. If the user callsdimension()
or a function depending thereof, sure, we'll compute it.On the other hand, I can see the artificial-ness of writing some local code inside GRS code which calls
self.length()
instead of accessingself._length
. Probably, we are never going to subclass GRS codes in a way where it wouldn't know its own length at construction time.I don't think it's much work to begin many methods of the GRS code class with
n, k = self.length(), self.dimension()
, and then be done with it. That's at least consistent.