> Not that more recent additions to sage/coding are perfect, I recall > spending time untangling the mess on > https://trac.sagemath.org/ticket/20787 > more or less completely on my own, which gives a good example on how not > to re-implement old functionality ;-)
Did I personally offend you? Because it seems you're trying to offend me - mentioning a completely unrelated ticket, which I, mind, had nothing to do with. IMHO it is quite evident that the code quality, doc quality and functionality of sage/coding went up a lot during ACTIS. > How about we document what's undocumented > ... Luckily we're each allowed to work on what we personally find rewarding. > providing new interfaces to existing functions, but not replacing the code, > seems more meaningful "meaningful" is subjective. If you want to improve Sage with a minimal effort, sure you're right. But there's multiple reasons for replacing the code completely. It has a crappy interface, it's not well-written, and my suggestion would enhance it's functionality a lot. > Most of these code bounds are more general than linear. > While it might be that the focus of seemingly completed ACTIS INRIA Sage > coding theory project > was about linear codes, I don't think any special bias towards linear codes > is appropriate. Either you misunderstand me or you're attacking me again; I'll assume the first. ACTIS was about *algebraic* constructions and especially efficient decoding - we mostly didn't care at all about general bounds or general linear/non-linear codes (which were, functionality-wise in an OK shape already). There are bounds for general codes, and bounds for only linear codes. All I'm suggesting is to have, aside from "best-code-bounds" *also* to have a function for "best-linear-code-bounds", and stuff like that. If you call that a bias towards linear code, then yes, I definitely think that's appropriate, considering the major advantages and prevalence of linear codes. > Something we should do, I think, is to provide as much of what, currently > hardly updated any more, http://codetables.de/ > ... Note that codetables.de has constructive lower bounds, on top of the upper-bounds. Replacing codetables.de is a *huge* undertaking - especially the constructions - requiring Nathann'esque ardour. I completely agree that it would be great if Sage had this, but it's hardly on the same scale as improving the small set of bounds we currently support in Sage (which we'd need in any case). Best, Johan Dima Pasechnik writes: > On Tuesday, May 9, 2017 at 9:41:46 AM UTC+1, Johan S. H. Rosenkilde wrote: >> >> 'Peter Mueller' via sage-support writes: >> >> > The functions and their docs in codes.bounds.* still seem to be a mess >> (as >> > they have been since many years now). (...) >> >> Indeed, these bounds are a catastrophe. Names, order of parameters, and >> documentation is sorely lacking. In particular, none of the docs >> describe whether the bounds hold for only linear codes or not. >> > > Not that more recent additions to sage/coding are perfect, I recall > spending time untangling the mess on > https://trac.sagemath.org/ticket/20787 > more or less completely on my own, which gives a good example on how not > to re-implement old functionality ;-) > > > How about we document what's undocumented > on https://trac.sagemath.org/ticket/22961 > before deciding what to do then? > (most of the stuff is on wikipedia, it's just trivial addition of links) > > >> >> A way around the incompatibility issues is to completely replace the >> functions with a new set of functions with a more well-designed >> interface. For instance, each of the bounds can be used as bounds for >> any one of the code parameters, instead of just the dimension. Perhaps >> someone could think of a clever interface to allow this. Is there any >> precedence elsewhere in Sage? >> > > providing new interfaces to existing functions, but not replacing the code, > seems more meaningful > > >> Then the entire current module could just be deprecated. >> >> > (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. >> >> The doc here is clearly very lacking. I think it makes sense to allow >> querying only for linear codes (over fields), as the focus of Sage's >> current functionality is firmly based here. > > > Most of these code bounds are more general than linear. > While it might be that the focus of seemingly completed ACTIS INRIA Sage > coding theory project > was about linear codes, I don't think any special bias towards linear codes > is appropriate. > > Something we should do, I think, is to provide as much of what, currently > hardly updated any more, http://codetables.de/ > provides in Sage. You know, it has these infamous "missing entries", cf > e.g. the red-shaded part of > http://codetables.de/BKLC/Tables.php?q=4&n0=1&n1=256&k0=1&k1=256 > for which perhaps Sage can fill in gaps. > > I checked that Sage can improve some upper bounds in these tables, and > provide more entries, but the maintainer > of http://codetables.de/ was not replying to my emails suggesting to fix > this (perhaps, he waits for Magma people to > help him instead :-)) > > Dima > > >> A parallel set of functions >> (or by using optional arguments etc.) could then support non-linear >> codes over fields, or even codes over rings. >> >> There's also #16393 (https://trac.sagemath.org/ticket/16393), but I >> would suggest going much further in redesign than suggested there. And >> of course, the very old patch currently there is completely out of date. >> >> Best, >> Johan >> -- 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.
