#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          |  b2b9e8270a95e7478760532827be04cecb906510
   Dependencies:                     |     Stopgaps:
-------------------------------------+-------------------------------------

Comment (by dlucas):

 Thank you for your comments.

 But now another problem arises, namely how to design a generic mechanism
 to inform codes about some of their "properties".

 Consider you have a code and you perform syndrome decoding.

 If you already computed its minimum distance, you can fill `decoder_type`
 at construction time. If you did not, you will fill it while building the
 table of syndromes and you have to inform the code that it now knows its
 minimum distance.
 This can be done for instances of `LinearCode` as they have a class
 argument `minimum_distance` but how to do that properly for other codes
 (e.g. `GeneralizedReedSolomonCodes`) that do not possess this class
 parameter?

 The same issue arises with covering radius, but for any code this time, as
 there is no class with a `_covering_radius` parameter.

 I might again be completely missing the spot here, but it does not appear
 to me as a simple mechanism to implement, especially if we want something
 generic. I'm working on it, so for now
 I did not change `maximum_error_weight` nor `decoding_radius`.

 All the other requested changes has been made. Leaving this in
 `needs_work` for now.

--
Ticket URL: <http://trac.sagemath.org/ticket/19623#comment:18>
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.

Reply via email to