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 sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
