#19623: Syndrome decoder is not a syndrome decoder
-------------------------------------+-------------------------------------
Reporter: dlucas | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-7.1
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 | 4d70e2c87e7c2e50171ee24ca7c6200ff29d0250
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Changes (by dlucas):
* status: needs_work => needs_review
* milestone: sage-7.0 => sage-7.1
Comment:
Hello,
I did the required changes:
- `covering_radius` and `minimum_distance` for the code are now internally
saved whenever found,
- `decoder_type` is updated accordingly, `decoding_radius` and
`maximum_error_weight` likewise.
- The lookup table is now computed at construction time to solve the
problem presented in comment 24.
- I also added `"dynamic"` to the list of types for this decoder.
I made some naming choices for the new decoder types here, which I like
you to discuss, especially `"might_create_decoding_error"` which is awful.
I did not have a better idea, sorry...
I commented my code as best as possible, because the chain of `if`
statements at the end of `_build_lookup_table` is pretty ugly.
I chose to not write getter methods for the internal `minimum_distance`
and `covering_radius`, because depending on how far it went into the
computation, it can fill these fields - or not. I preferred these to be
properly filled when #19959 will be ready instead of implementing
something clumsy. But I think this is somehow bizarre, as we might get
useful information and not pass it to the user. This choice is of course
open to discussion.
By the way, this question is more or less related, does anyone remember
what a `complete` decoder is? I cannot remember this... Which once again
proves I need to write a proper list of these types in the introductory
thematic tutorial.
Best,
David
--
Ticket URL: <http://trac.sagemath.org/ticket/19623#comment:26>
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.
