#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):
I'm going to jump in on the discussion about whether to have
`my_code.encode()`, `my_code.unencode()` and `my_code.generator_matrix()`
or not. I've reflected on what you wrote Nathann, and though I'm not
impossibly against removing these functions, I still argue that they are
better retained.
The difference is really a matter of style and taste, and the opinion on
what we're optimising our interface for. These functions are "end-user"
functions, which can be compared to a top-level API for e.g. a library
design. Also there is it rather common to "forward" functions to make
common use cases slightly more obvious and convenient to the library user
(for instance, writing "randint(5)" instead of "Random().randInt(5)").
I agree that the difference between writing `my_code.encode(m)` and
`my_code.encoder().encode(m)` is not huge, but the latter exposes more
clearly the computer science way of implementing coding theory, where the
former more directly supports a "naive" view of things.
Coding theory is often taught in a way that codes and generator matrices
are very connected. Even many coding theory researchers would not make it
a primary concern to support multiple encoders and generator matrices for
a given code (e.g.: none of previours-Sage, GAP or Magma has this).
Forcing these users to write something like
`my_encode.encoder().encode(m)` shoves the view of multiple encoders down
their throat, whatever they want it or not. I could imagine that it would
add a "eew"-factor to their experience. For students in a coding theory
class, it would add a little extra distance between their classroom
experience and the software experience.
These are not kill-all arguments. So if the added overhead of having and
maintaining these shortcuts was large, I would vote against having them.
However, we are talking about three very small functions (and two more for
decoders in a later ticket), and no maintenance effort that I can see.
Johan
--
Ticket URL: <http://trac.sagemath.org/ticket/18376#comment:19>
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.
