>> >> Generalisation. Sometimes that judgement is an error, sometimes it's >> not. >> > > Unless there is a majority, or even better, a consensus, for doing this, > I'd much prefer improving the existing code. It's much more incremental, > and thus less error-prone (although more boring, of course).
I think it's useless to discuss this further. I see your point, though it would be stronger if the current code was better tested and of higher quality to begin with. I don't know if you see my point, but it's not important; if I get motivated enough to implement what I'm thinking about, it will bring about new useful functionality as well, so with proper testing it should be merged in Sage. >> AFAIK we are missing numerous code constructions and code manipulations. >> To properly supersede codetables.de, we would also need the search >> algorithm for finding good derived codes from base constructions. >> > > Well, yes, we need something like "best_code_sage_knows(*,linear=True)" > function > for a given set of parameters. What I mean is that "the best code Sage knows" could be e.g. a BCH code punctured somewhere, then extended, then Plotkin-summed with something and then the dual of that. See e.g. (http://codetables.de/BKLC/BKLC.php?q=2&n=24&k=17). Finding exactly that sequence of code modifiers requires some sort of worklist algorithm where the currently best known codes are applied all known modifiers. The same is true for the lower and upper bounds of Brouwer's tables. > IMHO much more urgent project than redoing from scratch what already is > there. You pointedly keep missing my point, but oh well... Best, Johan Dima Pasechnik writes: > On Wednesday, May 10, 2017 at 12:17:25 PM UTC+1, Johan S. H. Rosenkilde > wrote: >> >> Dima Pasechnik writes: >> > Please note that that "completely unrelated" ticket was fixing the work >> of >> > your and David (?) GSoC mentee. >> > (and part of it was David's himself, IIRC). >> > Saying that you have nothing to do with it is, hmm, strange to me, >> sorry. >> > And you guys just fell totally silent there. >> > It's nothing to do with offending or anything, it's just matter of >> > responsibility of all the Sage developers >> > that has to be taken seriously, otherwise we will end up with a lot of >> > broken code. >> >> The ticket was opened by our GSoC student in the warmup but he left it >> unfinished (and unmerged) since he began his proper GSoC project. I was >> not really involved with that. David decided to finish the ticket, which >> it seems he did too hastily. When ACTIS was over, David mostly stopped >> contributing to Sage (he got a new job); this is normal. Daniel Augot, >> who had never himself before contributed to Sage, attempted to finish >> the ticket during Review Days 3, with a lot of help from you. New >> developers needing help with debugging is normal. No obviously broken >> code was ever introduced into Sage. >> > > Well, it was an old doctest that made sure this error was caught. A close > call. > > >> > this is the usual error of open-source projects: "let's not fix our old >> > bugs, but just rewrite it is all from scratch". >> >> Generalisation. Sometimes that judgement is an error, sometimes it's >> not. >> > > Unless there is a majority, or even better, a consensus, for doing this, > I'd much prefer improving the existing code. It's much more incremental, > and thus less error-prone (although more boring, of course). > > >> >> > This is a very hard undertaking, and the example of that "completely >> > unrelated" ticket >> > shows it all too well; few copies and pastes without thinking it all >> over, >> > and, oops, >> > a hard to find bug: >> > https://trac.sagemath.org/ticket/20787#comment:24 >> >> The bug came from one of the ways that #20787 *improved* Sage's >> capabilities wrt. Golay codes, by hard-coding some of the >> expensive-to-compute properties. It did not come from cut-and-pasting of >> old code. >> > > Did I say "old code" here? No. It was copying and pasting high degree > polynomials from somewhere > I have no idea about, see the removed function weight_enumerator() in > > https://git.sagemath.org/sage.git/commit/?id=6bf9d4b11523aaf7fcf69dc73d87352eefb29a8b > > >> >> > Instead, I would say, adding more doctests and docs, auditing the old >> code >> > and fixing >> > it if needed (some of it is more or less literal translation into Python >> of >> > old GAP Guava package, >> > and reads quite non-Pythonic), is much more sensible. >> > I did a bit of this on https://trac.sagemath.org/ticket/22961 (ready >> for >> > review now) >> >> I'm still not arguing that wouldn't be good things to do, and you're >> welcome to do them. I was merely suggesting something I found would add >> more functionality to Sage. >> >> > As long as no new code constructions have to be added, this is more of >> > database-thing problem, easier than >> > https://doi.org/10.1007/s10623-016-0264-x >> > where we did add lots of tricky constructions. >> >> AFAIK we are missing numerous code constructions and code manipulations. >> To properly supersede codetables.de, we would also need the search >> algorithm for finding good derived codes from base constructions. >> > > Well, yes, we need something like "best_code_sage_knows(*,linear=True)" > function > for a given set of parameters. > IMHO much more urgent project than redoing from scratch what already is > there. > > Cheers, > Dima > >> >> >> Best, >> Johan >> >> >> Dima Pasechnik writes: >> >> > On Wednesday, May 10, 2017 at 8:47:21 AM UTC+1, Johan S. H. Rosenkilde >> > wrote: >> >> >> >> > Not that more recent additions to sage/coding are perfect, I recall >> >> > spending time untangling the mess on >> >> > https://trac.sagemath.org/ticket/20787 >> >> < >> https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F20787&sa=D&sntz=1&usg=AFQjCNExN2h8OYzl3Fgqcq_SzWWgz8_PZg> >> >> >> >> > 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. >> > >> > >> > Please note that that "completely unrelated" ticket was fixing the work >> of >> > your and David (?) GSoC mentee. >> > (and part of it was David's himself, IIRC). >> > Saying that you have nothing to do with it is, hmm, strange to me, >> sorry. >> > And you guys just fell totally silent there. >> > It's nothing to do with offending or anything, it's just matter of >> > responsibility of all the Sage developers >> > that has to be taken seriously, otherwise we will end up with a lot of >> > broken code. >> > >> > >> >> IMHO it is quite evident that the code quality, doc quality >> >> and functionality of sage/coding went up a lot during ACTIS. >> >> >> > >> > I have no doubt about this, sure it was overall a great addition. >> > >> >> >> >> > 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. >> >> >> >> this is the usual error of open-source projects: "let's not fix our old >> > bugs, but just >> > rewrite it is all from scratch". >> > This is a very hard undertaking, and the example of that "completely >> > unrelated" ticket >> > shows it all too well; few copies and pastes without thinking it all >> over, >> > and, oops, >> > a hard to find bug: >> > https://trac.sagemath.org/ticket/20787#comment:24 >> > >> > Instead, I would say, adding more doctests and docs, auditing the old >> code >> > and fixing >> > it if needed (some of it is more or less literal translation into Python >> of >> > old GAP Guava package, >> > and reads quite non-Pythonic), is much more sensible. >> > I did a bit of this on https://trac.sagemath.org/ticket/22961 (ready >> for >> > review now) >> > >> > >> > >> >> > 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. >> >> >> > >> > I suppose I misunderstood; sorry. >> > Yes, sure, this would be a great addition; by the way, we have ready to >> be >> > used bounds functionality for additive codes as well. >> > >> > >> >> >> >> > 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). >> >> >> > >> > As long as no new code constructions have to be added, this is more of >> > database-thing problem, easier than >> > https://doi.org/10.1007/s10623-016-0264-x >> > where we did add lots of tricky constructions. >> > >> > >> > >> >> >> >> 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 [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.
