#18376: New encoding structure for linear codes
-------------------------+-------------------------------------------------
Reporter: | Owner:
dlucas | Status: needs_work
Type: | Milestone: sage-6.8
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers:
coding theory | Work issues:
Keywords: | Commit:
Authors: David | aa42238c6754cff63c5cc42e8d77e78b36074fbc
Lucas | Stopgaps:
Report Upstream: N/A |
Branch: |
u/dlucas/encoder |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by jsrn):
Hi Nathann,
I don't think I'm following your criticism. I'll try to comment on your
points.
> For a while, I tried to forget what you wanted to represent (easier for
me than for you), and it appeared to me that you were implementing class
inheritance backwards.
Yes, we are "forwarding" certain functions from (multiple) encoder classes
in *one* class `AbstractLinearCode`. The many classes that will inherit
from `AbstractLinearCode` will all inherit this forwarding. There is a
one-shot overhead in the implementation of `AbstractLinearCode` (in this
ticket) -- that's all.
> Look at it, it is quite surprising: here is the list of methods of an
encoder object I built:
> ...
> It is funny to notice two things:
> 1) All encoder methods can be called directly from the code (i.e. at the
moment there is no point to build the encoder object)
Yes, that's a feature: the encoder objects will be created behind the
scenes and the user will access them transparently through the code
object.
The "there is no point to build the encoder object" is unclear to me. In
the proposed ticket, the encoder object must be build behind the scenes,
or the code functions would not work. Note that there is an (at least)
one-to-many relation between code classes and encoders. This ticket is
about supporting that multiplicity of encoders in an elegant fashion;
elegance seen from the user perspective and future code class designers.
The proposed ticket puts as much of the boiler-plate as possible into
`AbstractLinearCode`, e.g. for selecting the right encoder, caching the
encoder (including whatever cached objects it has), etc. Furthermore it
puts in implementations of `encode`, `unencode` and `generator_matrix`
whose usability purposes we have already discussed. Note again that these
implementations will never be touched by sub-classes but will "just work".
> 2) Some code functions call the encoder's function, which leads you to
create one-line functions with 30 lines of doc each time.
"Each time" means *this ticket*. No more. All later codes will inherit
this forwarding and will never touch `encode`, `unencode` and
`generator_matrix`.
> If I just look at the code, it seems that you just want your code to
inherit the methods implemented in the encoder, i.e. generator_matrix,
encode, and unencode. Then you get this for free.
Are you suggesting killing off `Encoder` entirely? I think that
impoverishes the design a lot. That encoders are instances of classes
means that they have lots of power, e.g. caching and intro-spection. If
that's not what you're talking about, then I don't understand.
> If you find a way to make all these functions available at the level of
the code without having to copy/paste a lot of things, it would solve my
main (and perhaps only) objection about the classes' design.
Good, because that's how the current ticket is from the point of view of
new code classes and encoders :-) They will just inherit from
`AbstractLinearCode` or `Encoder` respectively, and these "copy/paste"
functions will be inherited.
Best,
Johan
--
Ticket URL: <http://trac.sagemath.org/ticket/18376#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.
