#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):

 Sorry if wrote my answer in a confusing manner, I'm not against
 implementing the mechanism to discover the minimum distance and the
 covering radius and dynamically update decoder type, I was against
 implementing the generic mechanism here. Your suggestions definitely make
 sense here, I just jumped directly into the bigger picture instead of
 focusing on this instance of the problem. My bad!
 I think we actually agree on this. I'll do that in the morrow.

 > Hmm, yes it's an interesting idea. I could imagine that the decorator be
 backed by some functions that should be callable directly.

 That's what I have in mind. I read more carefully the documentation, it
 seems interesting to do, and definitely possible.
 The reason I thought about decorators in the first place is because, we,
 as usual, want a mechanism which has the best genericity/simplicity ratio.
 And with a decorator, if one wants to implement his own methods, one only
 has to add a decorator over some specific methods, which is definitely
 simple! Well, if you (or Julien, or anyone) can see a better mechanism,
 please tell me!

 David

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