- edited description
Problems with `linear_code.py`
Problems
Doc-strings
The module doc for linear_code.py
is not a module doc: it reads like a Wikipedia page on linear codes followed by a commented list of functions.
Methods whose doc-string should be improved:
assmus_mattson_designs
: Too long and terrible beginning.divisor
: Bad (what'sA_i
?)__eq__
: Goodis_permutation_automorphism
: Typo. Doesn't return 1 or 0 but True and False.minimum_distance
: Too longmodule_composition_factors
: Does not really explains what it doespermutation_automorphism_group
: Too long *puncture
: Unhelpful.automorphism_group_gens
,_canonize
,canonical_representative
: Very poor documentation-
'support': Should be described without referring to 'spectrum'.
-
code2leon
: (Renamed and rm from global namespace in #21165) wtdist_gap
: (Deprecated from global name space now)min_wt_vec_gap
: (Renamed and rm from global namespace in #21165)best_known_linear_code_www
: (Fixed and moved in #21165)covering_radius
: (Fixed in #21165)spectrum
: (Fixed in #21165. Made alias weight_enumerator)sd_duursma_data
: (Deprecated in #21165)sd_duursma_q
: (Deprecated in #21165)sd_zeta_polynomial
: (Deprecated in #21165)
Methods whose doc-string refers to people and shouldn't:
This is not exhaustive!
is_permutation_automorphism
spectrum
minimum_distance
Naming and location
Methods whose name is bad (but is aptly placed in linear_code.py
and whose existence is justified):
module_composition_factors
: Okshortened
: Badcode2leon
: (Fixed in #21165)wtdist_gap
: (Fixed in #21165)min_wt_vec_gap
: (Fixed in #21165)
Methods that should exist but should be moved elsewhere
code2leon
: (Fixed in #21165)wtdist_gap
: (Fixed in #21165)min_wt_vec_gap
: (Fixed in #21165)best_known_linear_code
: (Fixed and moved in #21165)best_known_linear_code_www
: (Fixed and moved in #21165)sd_duursma_data
: (Deprecated in #21165)sd_duursma_q
: (Deprecated in #21165)sd_zeta_polynomial
: (Deprecated in #21165)
Functionality requiring Guava
The following functions do not work without Guava. It would be nice to have working implementations of these things.
bounds_minimum_distance
: Mandatory. Note: moved in #21165covering_radius
: Mandatory (resolved with Trac #19913)
Functions that work only on binary codes
Perhaps we should have a BinaryLinearCode
.
The following list is not exhaustive.
assmus_mattson_designs
: Does not even check for binary!is_permutation_equivalent
: Seems to fail when codes are not over the same non-F2
field and of the same length. No check.
Other Issues
assmus_mattson_designs
: Return type is insane!characteristic
: Should be removed. Equivalent toC.base_ring().characteristic()
.extended_code
: Should be superseded by a class. Trac #20124.minimum_distance
: Some commented lines seem to refer to removed code (beforecached_method
)LinearCode
argumentminimum_distance
: Is no longer respected when callingminimum_distance
.module_composition_factors
: No return value, only prints. Example is totally not useful and doesn't actually test anything.permutation_automorphism_group
: Seems very complicatedshortened
: Should be superseded by a class. *standard_form
: Can be implemented a lot simpler (using
self.information_set`). Should support a flag for returning the column permutation used.sd_duursma_q
: (Deprecated in #21165)
Automorphism code
Functions automorphism_group_gens
, _canonize
, canonical_representative
,
all have very poor documentation for input and output.
The output is poorly typed (for e.g. canonical_representative
it is a tuple
with multiple stuff in it). The type is poorly explained. It is not clear how to
interpret the output of canonical_representative
. It is not clear how to
actually obtain an automorphism from automorphism_group_gens
.
is_permutation_equivalent
should perhaps use canonical_representative
instead (with appropriate transformation group set)? Do timing tests.
permutation_automorphism_group
should perhaps use canonical_representative
instead (with appropriate transformation group set)? Do timing tests.
Won't Fix
__getitem__
: This is very complicated, and we could just use__getitem__
over vector space. However, the current iterator over codes is a lot faster than the iterator over row spaces! The__getitem__
is slightly slower, but__getitem__
and__iter__
should match. I think__iter__
should be the priority, and since this is currently faster than vector space's, we should keep our.
Comments (7)
-
reporter -
reporter - edited description
Finished rewriting
-
reporter - changed title to Problems with `linear_code.py`
-
reporter - edited description
Notes on the self-dual Duursma functions
-
reporter - edited description
-
reporter - edited description
Found some more problems
-
reporter - edited description
Trac #21165 fixes many of the issues with linear code.
- Log in to comment