this is now https://trac.sagemath.org/ticket/22961
On Monday, May 8, 2017 at 3:44:12 PM UTC+1, Peter Mueller wrote: > > The functions and their docs in codes.bounds.* still seem to be a mess (as > they have been since many years now). Here a few findings from a recent > attempt to use them in class: > > (1) If the code parameters are n = length, d = minimum distance, and q = > size of the alphabet, there seems to be no system about the order of the > arguments n, q, and d in these functions. For instance plotkin_upper_bound > and others expect the arguments in the order n, q, d, > while codesize_upper_bound and others expect the arguments in the order n, > d, q. > > (2) To make the inconsistencies in (1) even worse, the docs of many of > these functions *do not* tell the order of the arguments; instead one has > to look into the source code, or figure it out with small examples. > > (3) Even if there is a doc which tells about the arguments, then it may > contain some other nonsense. For instance hamming_upper_bound says that q > is the size of a field, while this bound actually holds for any finite > alphabet of size q. > > (4) Again, there seem to be wrong bounds. For instance, > codesize_upper_bound(19,10,2) yields 8, while there are easy examples of > size 16, and it is known that there are even codes of size 20. Looking into > the source code reveals that codesize_upper_bound erroneously uses the > Griesmer bound, which works for linear codes only. > > I'm not sure how to fix the mess in (1) without breaking compatibility. > Maybe a solution could be to enhance these functions with keyword arguments. > > -- Peter Mueller > -- You received this message because you are subscribed to the Google Groups "sage-support" 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-support. For more options, visit https://groups.google.com/d/optout.
