Rename parameters of codes from coding_test

[David Lucas]

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.

[Johan Rosenkilde]

1. The access methods, such as dimension() etc. surely needs to be there. Users will access them.

2. Whether some method inside the GRS-class uses a private field _dimension, or calls self.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-classed LinearCode 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 calls dimension() 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 accessing self._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.

[David Lucas]

I definitely agree with you, just wanted to confirm my intuition :)

[Johan Rosenkilde]

deprecated