#19623: Syndrome decoder is not a syndrome decoder
-------------------------------------+-------------------------------------
Reporter: dlucas | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-7.0
Component: coding theory | Resolution:
Keywords: | Merged in:
Authors: David Lucas | Reviewers: Julien Lavauzelle
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dlucas/generic_decoders | 54c02c3af22e896dd03759408b989f493415f26a
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by dlucas):
> So, firstly, I want to say that my comments actually make sense even as
a completely internal mechanism of SyndromeDecoder. That is, harvesting
the true minimum distance and covering radius while the lookup-table is
being build enables the decoder to give useful feedback to the user, such
as its decoding radius and a more precise decoder type.
Of course they are, I'm perfectly aware of that! I was not criticising the
usefulness of it, I was just saying it seems quite difficult and a bit out
of purpose in this ticket.
Secondly, I hope you realise that this is "just" yet another example of
the usefulness of a general mechanism for specifying upper- and lower-
bounds on the minimum distance of a code, and it shows that, indeed as
could have been expected, that minimum distance is *not* special in this
regard: there are other parameters for which me might want such a
mechanism (in this case, covering radius).
Definitely. `dimension` should be added to this list of lower- and upper-
bounds...
I realized that while working on shortened codes (and subfield subcodes as
well).
For the mechanism, why not working on a set of decorators? Or maybe a
generic decorator with arguments, like `bound` which can be set to
`lower`, `upper` or `exact` and an argument `parameter`, which can be set
to `minimum_distance`, `dimension` or `covering_radius`?
Once properly implemented, it should be easy to use, and very flexible
(adding new parameters would be very simple).
Note it's just an idea in the wind, I'm definitely no expert in
decorators, I just read the documentation in the bus 20 min ago `;)`But it
seems feasible. Anyway, I opened a follow-up ticket #19959.
--
Ticket URL: <http://trac.sagemath.org/ticket/19623#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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
