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.
