#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 jsrn):
> 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.
You were saying a lot on how the code-parameter mechanism had issues and
was difficult, and possibly implied that it was out of place. You didn't
comment on the fact that my suggestions still made sense for
`SyndromeDecoder` completely isolatedly.
But I do realise that this ended up being a larger kettle of fish than we
originally intended. In case you're against implementing the decoding
radius and covering radius thing, *internally in SyndromeDecoder* for now,
I would say the only sensible semantics/documentation are:
- `decoding_radius` returns `maximum_error_weight`. It's main docstring
remains
as it is, while the Note is, of course, removed. Possibly add a Note
saying
something like "When correcting beyond half the minimum distance,
correct
unique decoding is not always possible. This decoder returns a codeword
of
minimum distance to the received. In particular, if
`maximum_error_weight` is
beyond the covering radius of the code, decoding of this many errors is
guaranteed to be incorrect.".
- `maximum_error_weight` is capped at `n-k` in the constructor.
On an unrelated note, I also noticed: The docstring of `SyndromeDecoder`
should explain in 2-3 lines what the decoder does. There's a "a" missing
before "syndrome" in the first line.
> Definitely. `dimension` should be added to this list of lower- and
upper-bounds...
Yes, I remember now.
> 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.
Hmm, yes it's an interesting idea. I could imagine that the decorator be
backed by some functions that should be callable directly. What we
discussed on this ticket would likely use those functions and not a
decorator (since `SyndromeDecoder` is another object than the code itself,
and since `_build_lookup_table` has the potential to discover 0, 1 or 2
parameters of the `Code`.
Best,
Johan
--
Ticket URL: <http://trac.sagemath.org/ticket/19623#comment:22>
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.
