#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/jsrn/prepare_linear_code_for_inheritance|
4048b01c81b228326c7bbb1d977b67b8627f32da
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by jsrn):
Hi Vincent and David,
I was not clear enough earlier, it seems. What I meant about the category
stuff
was that I don't think we should touch it in this ticket at all (not even
removing the `self.Element = ...` thing. I for one have no idea what it
might or
might not break). It is a different kettle of fish and would require
cleanup
of several functions, etc. Also, as David mentions, it is really important
for
us that the generator matrix is not explicitly calculated except when
asked for
(possibly indirectly) by the user. If inheriting
`FreeModule_submodule_field`
would require us to explicitly calculate the generator matrix, I down-vote
that
solution. This whole discussion needs to be thought through properly in
another ticket.
Relatedly, I find it perfectly acceptable that lots of functionality
breaks in
subclasses of `AbstractLinearCode` if those subclasses don't override
`generator_matrix`; after all, those methods are default implementations
which
can and should be overridden in many cases. That being said, most code
families
*will* usually have a generator matrix implementation (based on encoders,
after
our future ticket on the matter).
David, you forgot to mention that you also fixed the `NOTE` thing, removed
the
`_repr_`, and reimplemented `base_field()` as suggested. I updated the
doc-string for `AbstractLinearCode` with some small stuff, and I changed
the error message in `AbstractLinearCode.generator_matrix`.
While doing so, I noticed the following: `__cmp__` and `__eq__` now breaks
for
`AbstractLinearCode` since they use `generator_matrix` which is not
defined.
That's of course unavoidable if the definition of code equality is that
they
describe the same sub-space. We have had a discussion on what comparison
semantics makes most sense for linear codes, and we should bring this to
Trac
soon. Our consesus was that it should mean equality of sub-spaces. In this
case, the `NOTE` in `AbstractLinearCode` should be removed. However,
that's for later, I guess.
David, will you create a ticket for fixing up the category stuff, so we
don't forget?
Best,
Johan
--
Ticket URL: <http://trac.sagemath.org/ticket/18099#comment:31>
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.
