#18099: Prepare linear_code for inheritance
-------------------------------------+-------------------------------------
Reporter: dlucas | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.6
Component: coding theory | Resolution:
Keywords: sd66 | Merged in:
Authors: David Lucas | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dlucas/prepare_linear_code_for_inheritance|
8905552948a0896a46e587815cce539b6e60aae9
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by dlucas):
Hello,
I updated the description of the ticket.
Regarding the naming problem : from the programmer's point of view, having
a class named `AbstractSomething` makes sense (in my humble opinion) with
regards to inheritance. Usually, if you see an abstract class of
`something` you know that you need to inherit from this class when it
comes to the implementation of `something` (or its subfamilies).
Regarding the name of what we call `LinearCode`, we think it's the right
name for coding theorists. `LinearCode_generic` is not really clear. I'd
prefer to avoid this idea of using aliases, but if you tell me it's a more
Sage-consistent naming scheme, I'll take it.
>Why the ambient vector space is not part of the input of
AbstractLinearCode?
It is actually implied by the parameters: the ambient space is a vectorial
space over the base field of the code and of dimension the length of the
code. `base_field` and `length` are the two parameters in our abstract
class constructor, so every code knows its ambient space. Having both
`bsae_field`, `length` and `ambient_space` as class parameters is
redundant. We chose to pick `length` and `base_field` (and thus build the
ambient space from these parameters) but the inverse could make sense too.
It's really a matter of taste here `:)`
>What is the difference between base_ring provided by the Module and
base_field?
We noticed that some classes in Sage (like for instance `VectorSpace`)
have both `base_ring` and `base_field` methods implemented, the former
coming from the category framework and the latter specifically made for
the class, both returning the same result. We chose to follow that because
we thought it was consistent with Sage to do so. If it's not, I can remove
the `base_field` method!
>Coud you include in the docstring of the former AbstractLinearCode:
>the set of attributes that are provided by the class
>what should be done to implement a linar code when inheriting from it
>
>In particular, some methods of AbstractLinearCode assume the presence of
the attribute ._generator_matrix (like `__cmp__`).
Sure, I'll do that. Thanks for noticing that in `__cmp__`, because it
should not directly call the class parameter anymore but use the method
`generator_matrix()` instead. My mistake.
>Could you remove
>{{{
>
> + # sage: C.minimum_distance_upper_bound() # optional (net
connection)
> + # 3
> + # sage: C.minimum_distance_why() # optional (net connection)
> + # Ub(7,4) = 3 follows by the Griesmer bound.
>
>}}}
There is some commented lines in the files of the coding part of Sage,
along with some algorithms that could be more efficient. We definitely
want to clean up the whole coding library, which means:
- remove all these commented lines
- remove some deprecation warnings which are more than one year old
- enhance some algorithms and methods
If you agree, we would prefer to focus on integrated our new
functionnalities into Sage for now, and once it is done clean up all the
coding library based on what we noticed while working on the existing
code, and on the new input we might get.
David
--
Ticket URL: <http://trac.sagemath.org/ticket/18099#comment:21>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
